Google Gemini CLI新增文件修改确认机制

自主编码 Agent 的魅力在于：你把任务交给它，给它仓库和工具的访问权限，然后在它工作时袖手旁观。Google 最新的 Gemini CLI 版本在特定时刻让 Agent 停下来等待你确认。

9 月 17 日发布的 Gemini CLI 0.61.0，在 Agent 编辑构建配置文件、在该编辑之后运行构建或测试命令、或执行参数疑似来自不可信外部内容的 shell 命令时，都需要显式确认。同一版本还单独强化了 Gemini CLI 的可选沙箱，使得宿主的凭证和配置不被沙箱内运行的任何内容触及。

赋予编码 Agent 更多修改和执行代码的权限，同时也为攻击者提供了更多将这种权限反噬开发者的途径。Gemini CLI 0.61.0 在其中一些关键节点重新引入了人工确认环节。

安全修复，公开展示

Google 在 5 月的 I/O 大会上宣布，将把 Gemini CLI 的 Pro、Ultra 和免费版用户迁移到闭源的 Antigravity CLI。自 6 月 18 日起，开源工具主要服务于企业客户和持有付费 API 密钥的开发者。公司表示 Gemini CLI 将继续获得模型更新、错误修复和安全补丁。这些安全变更仍然以公开方式开发，0.61.0 版本背后的 pull request 清楚地展示了 Google 究竟在担心什么。

构建文件成为攻击向量

对 package.json、Makefile、pyproject.toml 或 Bazel BUILD 文件的修改，可以引入依赖项或触发脚本。Gemini CLI 可以利用网络搜索和外部工具的信息进行这些编辑，然后运行 shell 命令。如果在修复 bug 时获取的文档中包含隐藏指令，让 Agent 在 package.json 中添加 postinstall 脚本，Agent 就可以完成编辑、运行项目的测试套件，并在开发者从未输入命令的情况下执行恶意代码。

赋予编码 Agent 更多修改和执行代码的权限，同时也为攻击者提供了更多将这种权限反噬开发者的途径。

编号 #29250 的 pull request，标题为"prevent indirect prompt injection via build file modifications and untrusted flags"，直接针对上述攻击链条。现在对已识别的构建文件的编辑需要确认，Gemini CLI 会追踪会话期间哪些构建文件发生了变化，以便对后续任何构建或测试命令（如 npm run、make 或 cargo）持有显式批准。确认对话框也会展示完整的构建文件 diff，而不是截断它们。

不可信参数需要批准

第二层检查覆盖命令参数。Gemini CLI 现在将网络获取内容、MCP 服务器响应、Google Docs 和 Buganizer（Google 内部 issue 追踪器）的内容视为不可信上下文，并在运行任何标志或参数匹配这些来源内容的 shell 命令前请求确认。在这两种情况下，提示都会移除持久批准选项，因此开发者无法为这些操作授予"始终允许"的 standing 权限。

该 pull request 将这些变更与 restricted workspace mode 关联——这是 Gemini CLI 对用户未标记为可信的文件夹应用的安全模式——但没有详细说明这些检查在可信文件夹或 auto-approval 下的行为。

参数检查匹配的是 token，而不是追踪每个值的来源，pull request 的 review 历史显示了这条路有多难走对。Google 的自动化 reviewer 在早期版本中标记了多种绕过方式，包括带引号的参数、环境变量前缀、shell 重定向目标以及 Windows 路径处理，这些在 9 月 11 日合并之前都已得到处理。

沙箱隔离凭证

编号 #29214 的 pull request 收紧了 Gemini CLI 的沙箱。当沙箱通过 Docker、Podman、LXC 或 macOS Seatbelt 运行时，宿主的 ~/.gemini 目录不再挂载到沙箱内部。取而代之的是，CLI 传入一份经过清理的用户设置副本，其中 API keys、hooks 和自定义工具命令都已剥离。它还阻止沙箱在敏感位置（如主目录）启动，同时新的 Seatbelt 规则拒绝访问 OAuth 凭证、trusted-folder 决策和 .env 文件。

Google 的沙箱文档将该功能描述为 AI 操作与宿主机系统之间的安全屏障，同时提醒它降低风险但无法消除风险。这两个 pull request 展示了为什么两层都需要。沙箱限制了一个进程运行后能触及什么，而确认要求则决定了 Agent 是否被允许首先采取敏感行动。构建文件让这个缺口变得具体：沙箱挂载项目目录以便 Agent 可以编辑它，这意味着在沙箱内写入的中毒 package.json，在开发者或 CI 任务稍后在沙箱外运行构建时，仍然存在于仓库中。

……在沙箱内写入的中毒 package.json，在开发者或 CI 任务稍后在沙箱外运行构建时，仍然存在于仓库中。

Gemini CLI 已经为开发者提供了多种方式来决定 Agent 在多大程度上自主行动：从在 Agent 工作流固定节点运行确定性检查的 hooks，到 MCP server trust 设置——根据 Google 文档，该设置可绕过该服务器的所有工具调用确认。然而，一次授予的信任可能逐渐变质。正如工具投毒和 rug-pull 攻击所展示的：当某天批准的一个工具开始返回攻击者控制的内容时。

一次授予的信任可能逐渐变质……当某天批准的一个工具开始返回攻击者控制的内容时。