谷歌 Gemini CLI 现在在编辑你的构建文件前会先征求确认
内容提要
谷歌发布 Gemini CLI 0.61.0，为自主编码代理增加安全限制：修改构建配置文件、执行相关构建或测试命令，以及运行参数来自不可信外部内容的 shell 命令前，均需用户明确确认；同时加固沙箱，隔离主机凭证与配置，防止间接提示注入攻击。
延伸解读
安全机制的实际覆盖范围
Gemini CLI 0.61.0 的确认机制主要针对构建配置文件修改、相关构建或测试命令执行，以及参数来自不可信外部内容的 shell 命令。但文章指出，这些检查与受限工作区模式绑定，并未说明在受信任文件夹或自动批准模式下的行为。这意味着安全限制的实际效果取决于用户的工作区信任设置，开发者需留意不同模式下的差异。
间接提示注入的攻击路径
文章通过具体场景说明风险：如果代理在修复 bug 时获取的文档包含隐藏指令，例如向 package.json 添加 postinstall 脚本，代理可能自动编辑构建文件、运行测试套件，从而执行恶意代码。这揭示了自主编码代理在整合外部信息时面临的间接提示注入威胁，而新版本正是针对这一序列增加了人工确认环节。
沙箱加固与残留风险
0.61.0 通过 Docker、Podman、LXC 或 macOS Seatbelt 运行沙箱时，不再挂载主机的 ~/.gemini 目录，而是传入剥离了 API 密钥、钩子和自定义工具命令的净化设置副本，并阻止在敏感位置启动。但文章强调，沙箱内写入的恶意构建文件仍会留在仓库中，当开发者在沙箱外运行构建时可能触发风险，因此沙箱降低风险但未消除风险。
信任决策的长期隐患
文章提到，Gemini CLI 允许通过钩子或 MCP 服务器信任设置来绕过工具调用确认，但信任一旦授予可能随时间失效。工具投毒和 rug-pull 攻击表明，先前批准的工具可能后来返回攻击者控制的内容。因此，开发者需定期审查信任设置，避免长期授权带来新的安全缺口。
Q&A
Gemini CLI 0.61.0 在哪些情况下会要求用户确认？
Gemini CLI 0.61.0 在三种情况下要求用户明确确认：1) 编辑构建配置文件（如 package.json、Makefile、pyproject.toml 或 Bazel BUILD 文件）；2) 在编辑构建文件后运行构建或测试命令（如 npm run、make、cargo）；3) 执行参数来自不可信外部内容（如网页抓取、MCP 服务器响应、Google Docs、Buganizer）的 shell 命令。
为什么修改构建文件需要特别确认？
因为构建文件（如 package.json、Makefile 等）的修改可能引入依赖或触发脚本。如果代理从外部获取的文档中包含隐藏指令（例如在 package.json 中添加 postinstall 脚本），代理可能自动编辑并运行测试套件，从而执行恶意代码，而开发者从未输入命令。因此需要人工确认以防止间接提示注入攻击。
Gemini CLI 如何加固沙箱以保护主机凭证？
Gemini CLI 通过以下方式加固沙箱：当沙箱通过 Docker、Podman、LXC 或 macOS Seatbelt 运行时，不再将主机的 ~/.gemini 目录挂载到沙箱内；改为传入经过清理的设置副本，移除 API 密钥、钩子和自定义工具命令；阻止沙箱在敏感位置（如主目录）启动；新的 Seatbelt 规则拒绝访问 OAuth 凭证、受信任文件夹决策和 .env 文件。
Gemini CLI 如何判断 shell 命令的参数是否来自不可信内容？
Gemini CLI 将来自网页抓取、MCP 服务器响应、Google Docs 和 Buganizer 的内容视为不可信上下文。当 shell 命令的标志或参数与这些内容中的令牌匹配时，代理会要求用户确认。但该检查基于令牌匹配，而非追踪每个值的来源，因此可能存在绕过方式（如引号参数、环境变量前缀等），这些已在合并前修复。
Gemini CLI 0.61.0 的确认提示是否支持“始终允许”选项？
不支持。对于编辑构建文件、运行相关构建/测试命令以及执行来自不可信内容的 shell 命令，确认提示中移除了持久批准选项，因此开发者无法为这些操作授予“始终允许”的权限。
Gemini CLI 的沙箱和确认机制分别起什么作用？
沙箱限制进程运行后可以访问的资源，例如隔离主机凭证和配置；确认机制则决定代理是否能够执行敏感操作。两者互补：沙箱减少风险，确认机制在敏感操作前引入人工检查。例如，沙箱内修改的构建文件仍会留在仓库中，当开发者在沙箱外运行构建时可能触发恶意代码，因此需要确认机制来防止此类情况。
