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

Google's latest Gemini CLI release, version 0.61.0, released on Wednesday, introduces safeguards that ask for explicit confirmation before the autonomous coding agent edits build configuration files, runs build or test commands after such edits, or executes shell commands with arguments potentially sourced from untrusted external content.

Simultaneously, the release strengthens Gemini CLI's optional sandbox, ensuring host credentials and configurations remain inaccessible to any process running within it. The autonomous agent's expanded authority to modify and execute code also provides attackers with additional avenues to exploit the developer's system. To mitigate this, the update reintroduces human oversight at certain decision points.

Security improvements were announced at Google's I/O conference in May, with the open-source tool primarily serving enterprise customers and developers with paid API keys since June 18. The company maintains that Gemini CLI will continue receiving model updates, bug fixes, and security patches, all developed in public and visible through pull requests.

Build files can serve as attack vectors. Edits to package.json, Makefile, pyproject.toml, or Bazel BUILD files can introduce dependencies or trigger malicious scripts. Gemini CLI, through web searches and external tools, could make those edits and execute the injected malicious code without developer intervention. To counter this, the release requires confirmation before making changes to recognized build files, tracking modifications during a session to prompt explicit approval before subsequent build or test commands.

Additionally, the update introduces stricter checks on command arguments, treating content from web fetches, MCP server responses, Google Docs, and Buganizer as untrusted context. Before running shell commands with flags or arguments derived from such sources, Gemini CLI prompts for approval, preventing automatic execution. These safeguards operate within restricted workspace mode, applicable to folders not marked as trusted, without providing permanent approval options.

The sandbox configuration change, detailed in pull request #29214, removes the host's ~/.gemini directory from the sandbox when running through Docker, Podman, LXC, or macOS Seatbelt, preventing potential poisoning of the sandboxed environment. This update also blocks the sandbox from accessing sensitive locations such as the home directory, OAuth credentials, trusted-folder decisions, and .env files, adding another layer of security.

While the sandbox limits the actions a process can perform once executed, confirmation requirements determine whether the agent initiates sensitive actions in the first place.

These layered security measures aim to protect developers from both external attacks and internal vulnerabilities, ensuring the agent operates within safe boundaries while maintaining its efficiency in automating coding tasks.