Gemini CLI now asks before editing your build files
On September 23, 2026, Google shipped Gemini CLI 0.61.0, which requires human confirmation before the agent edits a build file or runs a command shaped by untrusted content. Developers using a coding agent should update and leave those confirmations on: for now, they are the best defense against indirect prompt injection.
September 23, 2026. Google ships Gemini CLI 0.61.0, which requires confirmation before the agent edits a build file. September 11, 2026. The main pull request merges after the automated reviewer forced fixes to several workarounds. May 2026. Google announces at I/O that most users will move to the proprietary Antigravity CLI. Why it matters: coding agents are a new attack surface, and the defense Google is deploying is not clever detection — it is a human confirmation prompt.
The attack this release is trying to stop
The scenario is precise. An agent fixes a bug and, to understand the problem, reads documentation from the web. That documentation contains a hidden instruction: add a postinstall script to package.json. The agent complies, edits the file, runs the project’s test suite — and executes the malicious code, without the developer ever typing a command.
That is indirect prompt injection: the attacker is not talking to the developer, but to the content the agent ingests. A build file is the ideal vector, because a change to package.json, Makefile, pyproject.toml or a Bazel BUILD file can pull a dependency or trigger a script — and because the agent, having edited the file, has every reason to run the build or test command that follows.
Gemini CLI 0.61.0 cuts that scenario in three places. Editing a recognized build file now requires confirmation. The agent remembers which build files changed during the session and holds any later build or test command (npm run, make, cargo) for explicit approval. And any shell command whose arguments match tokens from untrusted content — web search results, MCP server responses, Google Docs, Buganizer tickets — triggers a prompt before execution.
The telling detail: confirmation replaces trust
The most revealing change is not technical, it is editorial. For these three categories of action, Gemini CLI drops the persistent approval option. There is no “always allow” to grant: every sensitive action goes back through the human.
That is a confession. Coding agents used to offer two philosophies — trust (the agent decides, the human watches) or authorization (the human approves). Google now decides: for build files, no trust is good enough. And the confirmation dialog shows the full diff of the file rather than truncating it — because a truncated diff is exactly what lets a malicious line slip through.
Pull request #29250, titled “prevent indirect prompt injection via build file modifications and untrusted flags,” also shows how hard the check is to get right. The automated reviewer flagged several workarounds in early versions — quoted arguments, environment-variable prefixes, shell redirection targets, Windows path handling — all fixed before the September 11 merge. The check compares tokens rather than tracing the provenance of every value, an accepted limitation: simpler is easier to audit.
A parallel sandbox hardening
The same release hardens the optional sandbox. When it runs through Docker, Podman, LXC or Seatbelt on macOS, the host’s ~/.gemini directory is no longer mounted inside. Instead, the CLI passes a sanitized copy of the user’s settings, with API keys, hooks and custom tool commands stripped out. The sandbox also refuses to launch in sensitive locations such as the home directory, and new Seatbelt rules deny access to OAuth credentials, trusted-folder decisions and .env files.
The two layers complement each other. The sandbox limits what a process can reach once it runs; the confirmations decide whether the agent gets to take the sensitive action in the first place. But a concrete gap remains: the sandbox mounts the project directory so the agent can edit it, so a poisoned package.json written inside the sandbox still sits in the repository when a developer — or a CI job — runs the build outside it. Confirmation only protects the agent’s session, not everything that happens afterward.
Why build files are the weak link
It is not an accident that Google chose to put a confirmation on build files rather than on any other action.
A build file has three properties that make it the ideal target for indirect injection. It runs everywhere: on the developer’s machine, in CI, on production servers — a single malicious line propagates to every layer. It pulls dependencies: adding a package means introducing third-party code that will run with the project’s privileges. And it is edited by the agent itself: unlike a one-off command, a change to package.json persists in the repository, ready to be re-run long after the session ends.
The comparison with other agents is instructive. Anthropic’s Claude Code, OpenAI’s Codex and Cursor’s CLI all ship comparable safeguards — allowlists, sandbox modes, command confirmation — but Google is the first to treat the build file explicitly as a category of its own, showing the user a full diff. That is defensible: most documented indirect injection incidents in recent months run through a file that the agent edits and the system then executes.
The same release’s sandbox hardening closes a related gap. If the agent can edit package.json inside the sandbox, the sandbox is not enough on its own; the poisoned file still sits in the repository when a developer or a CI job runs the build outside it. So the two mechanisms must work together: the sandbox limits what a process can reach, and the confirmation decides whether the agent gets to take the sensitive action at all. Removing the “always allow” option is the key move, because a standing approval is exactly what turns a one-time lapse into a permanent backdoor.
There is still an accepted limit. The check compares tokens — fragments of arguments — rather than tracing the provenance of every value. Simpler is easier to audit, but it is also bypassable: an attacker who understands the mechanism can disguise an argument so it no longer resembles the untrusted content that inspired it. The real long-term defense is provenance tracking, and no one has industrialized it yet. Until then, the confirmation dialog is the honest, imperfect stopgap.
One more detail matters for who actually gets this fix. At I/O in May, Google said it would move Gemini CLI’s Pro, Ultra and free users to the closed-source Antigravity CLI; since June 18, the open-source tool mainly serves enterprises and paid API keys. The security work is still done in the open, but the safeguard now protects a shrinking, mostly paying population — a reminder that the safest defaults in AI tooling are not necessarily the ones most people are running.
Verdict
The change looks modest, but it draws a line for the whole ecosystem. If you use Gemini CLI or a similar coding agent, update to 0.61.0, keep the confirmations on, and refuse any persistent approval for build files — the convenience you gain is exactly the surface an attacker exploits. If you build agent tooling, copy the build-file confirmation gate, but invest first in provenance tracking over token matching: that is the only path that survives workarounds. If you run agents in a sandbox, remember the sandbox protects the host, not the repository — a poisoned build file survives the session and waits for the next build outside the sandbox.