Google's Gemini CLI now asks before editing your build files

Gemini CLI 0.61.0, released on Wednesday, now asks for explicit confirmation before the coding agent edits build configuration files, runs build or test commands after such an edit, or executes shell commands whose arguments appear to come from untrusted content. The release also hardens the optional sandbox, keeping host credentials and configuration out of reach of anything running inside it.

Build files become attack vectors

A change to package.json, Makefile, pyproject.toml or a Bazel BUILD file can pull in a dependency or trigger a script, and Gemini CLI can make such edits using information from web searches, then run shell commands. If documentation fetched while fixing a bug carries hidden instructions to add a postinstall script, the agent could execute the malicious code without the developer typing a command.

Pull request #29250 targets that sequence. Edits to recognized build files now require confirmation, and the CLI tracks which build files change during a session, holding any later npm run, make or cargo command for explicit approval. The dialog shows full build-file diffs, not truncated ones.

Untrusted arguments need approval

The second check covers command arguments: content from web fetches, MCP server responses, Google Docs and Buganizer, Google's internal issue tracker, now counts as untrusted context, and the CLI asks before running a shell command whose flags or arguments match tokens from it. The prompt drops the persistent approval options, so no standing "always allow" can be granted.

The checks are tied to restricted workspace mode, the safe mode Gemini CLI applies to folders a user has not marked as trusted, and the pull request does not say how they behave in a trusted folder or under auto-approval. The token match is not full provenance tracking: earlier workarounds — quoted arguments, environment-variable prefixes, shell redirection, Windows paths — were fixed before the change merged on September 11.

Sandbox keeps credentials out

A second pull request, #29214, tightens the sandbox. When it runs through Docker, Podman, LXC or macOS Seatbelt, the host's ~/.gemini directory is no longer mounted inside it; the CLI passes in a sanitized copy of the user's settings with API keys, hooks and custom tool commands stripped. The sandbox cannot launch in sensitive locations such as the home directory, and new Seatbelt rules deny access to OAuth credentials and .env files.

Google's documentation calls sandboxing a security barrier between AI operations and the host system, while cautioning that it reduces risk without eliminating it. The gap is concrete: the sandbox mounts the project directory, so a poisoned package.json written inside it stays in the repository when a CI job later runs the build outside.

Since June 18 the open-source tool has mainly served enterprise customers and developers with paid API keys, after Google said in May that Pro, Ultra and free-tier users would move to its closed-source Antigravity CLI, but the security work is still developed in public.