Google Tightens Gemini CLI with Human Checkpoints for Build File Edits and Untrusted Input

Autonomous coding agents promise efficiency by taking on tasks with minimal human intervention, but that same autonomy creates security risks. Google's Gemini CLI 0.61.0, released Wednesday, introduces mandatory confirmation steps at critical junctures where the agent would otherwise modify build configurations, execute build commands following those modifications, or run shell commands with arguments sourced from untrusted external data.

The tradeoff is deliberate: granting a coding agent broader permissions to alter and run code simultaneously expands the attack surface available to adversaries seeking to weaponize that authority against developers. By reintroducing human oversight at specific decision points, Gemini CLI 0.61.0 aims to mitigate that exposure.

Security improvements developed transparently

Since June 18, when Google transitioned Gemini CLI's Pro, Ultra, and free-tier users to its proprietary Antigravity CLI, the open-source version has primarily served enterprise customers and developers holding paid API keys. The company committed to continuing model updates, bug fixes, and security patches for the open-source tool. These security enhancements remain developed in the open, with pull requests for version 0.61.0 revealing the specific threat scenarios Google sought to address.

Build configuration files as attack entry points

Modifications to package.json, Makefile, pyproject.toml, or Bazel BUILD files can introduce new dependencies or activate scripts. Gemini CLI performs such edits using information gathered from web searches and external tools, then proceeds to execute shell commands. A scenario illustrates the risk: documentation retrieved during a bug fix could embed hidden instructions to inject a postinstall script into package.json. The agent might execute the modification, run the project's test suite, and trigger the malicious code—all without the developer explicitly issuing the command.

Pull request #29250, titled "prevent indirect prompt injection via build file modifications and untrusted flags," directly targets this attack chain. Changes to recognized build files now demand confirmation, and Gemini CLI maintains a record of which build files have been altered during a session, holding any subsequent build or test command—such as npm run, make, or cargo—pending explicit approval. The confirmation interface displays complete build-file diffs rather than abbreviated versions.

Approval required for arguments from external sources

A second safeguard addresses command arguments. Gemini CLI now classifies content originating from web fetches, MCP server responses, Google Docs, and Buganizer (Google's internal issue tracker) as untrusted context. Before executing any shell command whose flags or arguments contain tokens matching that untrusted content, the agent requests approval. In both scenarios, the confirmation dialog omits persistent approval options, preventing developers from granting standing "always allow" permissions for these actions.

The pull request anchors these checks to restricted workspace mode, the protective setting Gemini CLI applies to directories a user has not explicitly trusted. The documentation does not clarify how the checks function within trusted folders or under auto-approval configurations.

The argument check operates by matching tokens rather than tracking the complete origin of every value—a distinction that proved challenging to implement correctly. Google's automated reviewer identified multiple potential bypasses in earlier iterations, including quoted arguments, environment-variable prefixes, shell redirection targets, and Windows path handling. All were remedied before the change merged on September 11.

Sandbox isolation strengthened to exclude credentials

Pull request #29214 reinforces Gemini CLI's sandbox capabilities. When the sandbox operates through Docker, Podman, LXC, or macOS Seatbelt, the host's ~/.gemini directory is no longer mounted inside the sandbox environment. Instead, the CLI injects a filtered version of the user's configuration with API keys, hooks, and custom tool commands removed. The sandbox also prevents execution from sensitive directories such as the home folder, while new Seatbelt rules block access to OAuth credentials, trusted-folder settings, and .env files.

Google characterizes sandboxing as a security boundary separating AI operations from the host system, though it acknowledges the feature reduces rather than eliminates risk. The two pull requests illustrate why layered defenses matter. The sandbox constrains what a process can access once running, while confirmation requirements determine whether the agent gains permission to perform sensitive actions initially. Build files exemplify this gap concretely: the sandbox mounts the project directory to allow the agent to edit it, meaning a compromised package.json created inside the sandbox persists in the repository when a developer or CI pipeline executes the build outside the sandbox.

Gemini CLI already offers developers controls over agent autonomy, ranging from hooks that execute deterministic checks at defined workflow stages to an MCP server trust setting that, per Google's documentation, bypasses all tool call confirmations for that server. However, trust decisions made once can deteriorate over time. Tool-poisoning and rug-pull incidents affecting MCP servers have demonstrated that a tool approved on one day may begin returning attacker-controlled data on another.