2026 年 11 月，Ars Technica 记者 Kyle Orland 报道了一起令开发者社区不安的安全事件：Anthropic 旗下 AI 编码工具 Claude Code 正在 GitHub 上意外泄露大量敏感信息，包括密码、API 密钥、访问令牌等。问题的根源并非复杂的漏洞利用，而是一个看似无害的交互设计——“Do not ask again”（不再询问）提示。
一个提示框引发的泄密风暴
据 Ars Technica 报道，Claude Code 在运行过程中会请求访问文件、执行命令或读取环境变量。当工具检测到需要用户确认的操作时，会弹出权限请求。为了方便连续操作，界面提供了“Do not ask again”选项。问题在于，许多用户勾选该选项后，Claude Code 便不再对类似操作进行二次确认，直接将包含敏感信息的文件内容纳入上下文，并在后续代码生成或提交过程中将其写入 GitHub 仓库。
“Do not ask again” prompt leads to passwords, API keys, and more being shared.
报道指出，受影响的仓库中出现了数据库连接字符串、云服务访问密钥、OAuth 令牌等本不应公开的内容。部分泄露信息在被发现前已在公开仓库中存留数小时甚至数天，任何人均可访问。GitHub 的公开仓库搜索和第三方监控工具使得这些秘密一旦被推送便几乎无法完全撤回。
为什么 AI 编码助手更容易“闯祸”
传统开发流程中，开发者对 Git 提交内容有明确的审查意识，通常会在 .gitignore 中排除敏感文件，或使用密钥管理工具。但 AI 编码助手的介入改变了这一习惯。Claude Code 等工具以“自主代理”方式工作，能够读取项目文件、生成代码并执行 Git 命令。当用户为了效率选择“不再询问”时，实际上是将安全审查权部分让渡给了 AI。
更深层的问题在于上下文边界。AI 模型在生成代码时需要读取环境变量、配置文件甚至本地密钥库，这些内容一旦进入模型上下文，便可能在后续输出中被复现。如果模型判断需要将配置写入代码以便“让项目跑起来”，敏感信息就会顺势进入版本历史。安全专家指出，这并非 Claude Code 独有的缺陷，而是所有具备文件系统和命令执行权限的 AI 代理工具面临的共同挑战。
行业背景：AI 代理的权限困境
2025 年以来，AI 编码助手从“代码补全”快速演进为“自主代理”，Cursor、GitHub Copilot、Claude Code 等工具纷纷获得读取项目、运行测试、提交代码的能力。效率提升的同时，权限模型却相对滞后。多数工具采用“首次询问、后续信任”的交互模式，这与最小权限原则存在天然张力。
此次事件并非孤例。此前已有研究团队演示过通过提示注入诱导 AI 代理泄露环境变量，也有开发者在社交媒体上报告 Copilot 将本地配置写入提交记录。但 Claude Code 的案例特殊之处在于，泄露并非攻击者精心构造，而是正常使用流程中的设计缺陷所致。这意味着风险面更广，普通开发者在不经意间就可能成为受害者。
Anthropic 的回应与开发者自救
截至报道发稿，Anthropic 尚未发布完整的事故说明。Ars Technica 联系了该公司，但未获得即时置评。社区中已有开发者呼吁 Claude Code 增加提交前敏感信息扫描、限制“不再询问”的适用范围，并在检测到疑似密钥时强制二次确认。
对于已经使用 Claude Code 的开发者，安全建议包括：立即审查近期提交历史，使用 git secrets 或 GitHub secret scanning 工具排查泄露；轮换所有可能暴露的密钥；在项目层面配置预提交钩子，阻止包含高熵字符串的提交；谨慎使用“不再询问”选项，尤其是在涉及环境变量和配置文件的场景中。
自动化工具越强大，权限边界越需要被审慎定义。效率与安全之间的平衡，不能交给一个复选框。
编者按
Claude Code 的这次事件为整个 AI 编码工具行业敲响了警钟。当 AI 代理被赋予越来越多自主权时，产品设计中的每一个“便利性”决策都可能成为安全链条上的薄弱环节。“不再询问”背后是一种信任假设——假设用户清楚自己在授权什么，假设 AI 能正确判断哪些信息敏感。但现实是，这两项假设都不可靠。对于开发者而言，此次事件提醒我们：在享受 AI 带来的效率红利时，仍需保留对关键操作的最终审查权。对于工具厂商而言，安全不能是事后补丁，而应内嵌于交互设计的每一个细节之中。
本文编译自 Ars Technica
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接