Gemini CLI safety has been upgraded in version 0.61.0. The release forces explicit user confirmation before the agent modifies build configuration files, runs any build or test command that follows such a change, or executes shell commands whose arguments appear to originate from untrusted external sources. It also tightens the optional sandbox so that host credentials and configuration files are no longer visible to processes running inside the container.
What Gemini CLI 0.61.0 changed
The update introduces three user‑prompt checkpoints:
- Any edit to recognized build files –
package.json,Makefile,pyproject.toml, orBUILD– now requires a confirmation dialog that displays the full diff before the change is applied. - After a build‑file edit, the CLI tracks the modified files for the remainder of the session and will pause before executing commands such as
npm run,make, orcargountil the developer approves. - Shell commands whose flags or arguments match tokens extracted from web fetches, MCP server responses, Google Docs, or Buganizer are treated as untrusted and trigger a separate approval step. Persistent “always allow” options are removed for these cases.
In parallel, the sandbox hardening (pull request #29214) removes the host ~/.gemini directory from the mount list, replaces it with a sanitized copy that strips API keys, hooks, and custom tool commands, and blocks sandbox launch from sensitive locations such as the user’s home directory. New Seatbelt rules on macOS deny access to OAuth credentials, trusted‑folder decisions, and .env files.
Why the changes matter to AI, cloud, DevOps, and security engineers
Build files are a common vector for supply‑chain attacks. An autonomous coding agent that can silently edit package.json and then run the project’s test suite could introduce a malicious post‑install script without any human seeing it. By inserting a confirmation step, the CLI restores a manual review point that can catch such injected code before it is executed.
The sandbox adjustments reduce the risk that a compromised agent gains direct access to host credentials. However, the sandbox still mounts the project directory, meaning a poisoned file written inside the sandbox persists in the repository and can be executed later by CI pipelines or developers outside the sandbox. Practitioners must therefore treat the sandbox as a containment layer, not a complete barrier.
Operational and security implications
Teams that rely on fully automated Gemini CLI runs will need to adjust pipelines to handle the new prompts. Options include:
- Marking workspaces as trusted where the organization accepts the risk of automatic edits, while recognizing that the pull request does not detail behavior in trusted folders.
- Embedding deterministic hooks that perform additional checks before the CLI proceeds, leveraging the existing hook mechanism.
- Reviewing MCP server trust settings, because a server that was safe yesterday may return malicious content tomorrow.
Credential management policies should be revisited: the removal of ~/.gemini from the sandbox means that any scripts expecting those files inside the container will fail, requiring configuration updates. The new Seatbelt restrictions also mean that OAuth tokens and .env files must be stored outside the sandboxed execution path.
What to watch next
Google announced that Pro, Ultra, and free‑tier users will be migrated to a closed‑source Antigravity CLI, while the open‑source Gemini CLI now targets enterprise customers with paid API keys. Practitioners should monitor:
- Future pull requests that may tighten the untrusted‑argument checks or expand the list of protected file types.
- Changes to the sandbox’s default mount points or credential sanitization logic.
- Updates to the MCP server trust model, especially any new mechanisms for revoking or rotating trust.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
- Expect interactive prompts in local development; plan CI adjustments to either pre‑approve actions or redesign workflows to avoid the gated steps.
- Audit existing build files for hidden post‑install scripts or other executable hooks that could be altered by the agent.
- Validate that credential stores are not inadvertently exposed through the sandbox; move sensitive files out of the project directory if necessary.
- Track the trust status of any MCP servers or external tools used by Gemini CLI, and consider rotating keys or adding deterministic validation layers.
