Gemini CLI 0.61 asks before editing build files or running flags that came from a Google Doc, a web page or an MCP server

The most reliable way to make a coding agent do something dangerous is to hand it text you did not write. Google shipped Gemini CLI 0.61 on 23 September, and it changes what the agent is allowed to do with text that arrived through a web fetch, a Google Doc, a Buganizer entry or an MCP server response.

Two of the release's eight merged pull requests are the story. Pull request 29250, by @villahernandez-coder, is titled "prevent indirect prompt injection via build file modifications and untrusted flags". The description on the PR page says it refactors the built-in shell, edit and write_file paths to check whether their commands or arguments came from an <untrusted_context> block in the conversation history, and to require an explicit user confirmation before running when they did. It also tightens the workspace-boundary check for edits to build configuration files. Pull request 29214, by @diegogodinezr, hardens the CLI's sandbox: the release notes describe it as harden filesystem boundaries and isolate runtime state.

What the agent will now stop and ask about

The pattern the fix defends against is why indirect prompt injection has been the hardest part of coding-agent security since the first agent shipped. A user asks Gemini CLI to summarise a page, or read a Google Doc, or ask an MCP server for context. The reply comes back with a hidden instruction: run this shell command, or edit this file, or pass this flag. Without the fix, the agent could act on that instruction while still inside the workspace and inside the user's approved tools, because it did not carry a marker back to where the argument came from.

The Gemini CLI team has now attached that marker. The release notes list "external context tags" for Google Docs, Buganizer, web_fetch and MCP server responses. Anything a tool call brings back is tokenised into <untrusted_context>, and the shell, edit and write_file paths check whether a proposed command or argument contains any of those tokens before running. If it does, the agent asks the user before proceeding.

The context, and what it does not fix

Gemini CLI has 107,000 stars and 14,600 forks on GitHub, per the repository's page on 24 September. That is enough people wiring the agent into their own workflows that a silent execution path with attacker-controlled arguments is a real problem for a real number of teams. Every patch on a coding agent narrows what it will do without asking, and this one narrows shell, edit and write_file for anything whose arguments came in through an external tool.

The fix does not remove indirect prompt injection from Gemini CLI. It moves the point at which the user is asked, from the moment the tool call is planned to the moment its arguments are run with attacker text in them. A user who clicks yes on every confirmation is still exposed. No configuration is required.

If your team has Gemini CLI running in a repository whose agent tools include web_fetch or an MCP server that reads someone else's content, the upgrade is the change worth making today. A hidden instruction cannot execute silently once a human has to click through it.

Source

• google-gemini/gemini-cli, Release v0.61.0, 23 September 2026.
• Pull request 29250, fix(core): prevent indirect prompt injection via build file modifications and untrusted flags, merged 11 September 2026.