Google's Gemini CLI 0.61.0, released Wednesday, now forces autonomous coding agents to pause and wait for explicit human confirmation before editing build configuration files, running build or test commands after such edits, or executing shell commands with arguments that appear to originate from untrusted external sources. The update, detailed in public pull requests on the open-source project, targets a specific attack vector: malicious instructions hidden in external documentation or web search results that trick the agent into modifying package.json, Makefile, pyproject.toml, or Bazel BUILD files, then executing the poisoned code without the developer's knowledge. The same release separately strengthens the CLI's optional sandbox by blocking host credentials and configuration from reaching anything running inside it.
The tool now tracks which build files change during a session and holds any subsequent build or test command—such as npm run, make, or cargo—for explicit approval, according to pull request #29250, titled "prevent indirect prompt injection via build file modifications and untrusted flags." Confirmation dialogs display full build-file diffs rather than truncating them. A second check treats content from web fetches, MCP server responses, Google Docs, and Buganizer (Google's internal issue tracker) as untrusted context, and the CLI now asks before running any shell command whose flags or arguments match tokens from that content. In both cases, the prompt removes persistent approval options, so developers can't grant standing "always allow" permission for these actions. The argument check matches tokens rather than tracing the provenance of every value, and Google's automated reviewer flagged several workarounds in earlier versions—including quoted arguments, environment-variable prefixes, shell redirection targets, and Windows path handling—all of which were addressed before the change merged on September 11.
The report notes that when the sandbox runs through Docker, Podman, LXC, or macOS Seatbelt, the host's ~/.gemini directory is no longer mounted inside it. Instead, the CLI passes in a sanitized copy of the user's settings with API keys, hooks, and custom tool commands stripped out. It also blocks the sandbox from launching in sensitive locations such as the home directory, while new Seatbelt rules deny access to OAuth credentials, trusted-folder decisions, and .env files. Google's sandboxing documentation calls the feature a security barrier between AI operations and the host system, while cautioning that it reduces risk without eliminating it.
The changes address why both layers are needed: the sandbox limits what a process can reach once it runs, while the confirmation requirements decide whether the agent gets to take a sensitive action in the first place. Build files make the gap concrete—the sandbox mounts the project directory so the agent can edit it, meaning a poisoned package.json written inside the sandbox still sits in the repository when a developer or a CI job later runs the build outside it. The report also warns that trust granted once can age badly, as tool-poisoning and rug-pull attacks on MCP servers have shown when a tool approved on one day starts returning attacker-controlled content later. Gemini CLI already gives developers ways to decide how much the agent does on its own, from hooks that run deterministic checks at fixed points in the agent's workflow to an MCP server trust setting that, according to Google's documentation, bypasses all tool call confirmations for that server. The confirmation model now inserts human judgment at the exact moments when an autonomous agent's authority could be weaponized against the developer who granted it. For organizations weighing how much autonomy to delegate to AI tooling, the technical specifics here map directly onto policy decisions about whether speed or control takes precedence when the two conflict.