AI 安全與開發工具
Gemini CLI Nightly Adds Execution Confirmation for Untrusted Arguments and Build File Changes, Isolates Sandbox Credentials
The September 12 nightly of Gemini CLI 0.61.0 tracks command arguments derived from external content and requires renewed user approval after build configuration changes. A separate set of patches prevents sandboxes from mounting home directories, credentials, and `.env` files, but a stable release is not yet available.
Google has merged two sets of security hardening changes into Gemini CLI `v0.61.0-nightly.20260912`. The first labels content from sources such as Google Docs, web fetches, and MCP responses as `untrusted_context`, then checks whether shell, editing, and file-writing operations use arguments influenced by external content. If the agent modifies build files such as `package.json`, `Makefile`, `pyproject.toml`, or `BUILD.bazel`, users must approve again before subsequent build or test commands such as `npm run`, `make`, or `cargo` can execute. Permanent approval is also no longer offered in sensitive cases, while non-interactive environments should fall back to prompting or denial.
The second set addresses the execution boundary rather than model judgment. Docker, Podman, runsc, LXC, and macOS Seatbelt now reject attempts to mount the home directory, `~/.gemini`, credentials, `.env` files, or their parent directories into the sandbox. Path validation resolves symbolic links and traces parent directories even when the target does not yet exist. Configuration copies passed into containers have hooks, `callCommand`, `discoveryCommand`, and API keys removed, while chat history, tokens, and temporary state are placed in an isolated runtime directory.
These changes move the defensive boundary beyond telling the model not to follow malicious text, extending it into tool policy and the file-system layer. This is especially important for agents that inspect unfamiliar repositories or process issues automatically. However, this remains a prerelease nightly build, with no corresponding CVE or standalone exploit reproduction, and the official documentation notes that sandboxing is not always enabled by default in standard mode. Engineering teams should wait for a stable release, verify that the deployed version includes both merged commits, and create regression tests covering malicious build files, symbolic links, and custom MCP file tools.