Claude Code不再询问功能致2539个密钥流入GitHub公开仓库

2026年11月5日，软件安全公司Apiiro发布研究报告，确认Anthropic旗下AI编程助手Claude Code存在一条系统性密钥泄露路径：开发者在工具弹出的权限提示框中选择"Yes, and don't ask again"（是，且不再询问），该批准操作会把完整的shell命令——包括命令中嵌入的数据库密码、API密钥或认证令牌——以明文写入项目目录下的.claude/settings.local.json文件。一旦该文件随代码推送至公开GitHub仓库，任何人均可读取其中的凭证。Apiiro研究员扫描GitHub上104185个此类文件副本后，在1122个副本中发现了至少一条真实密钥，共计1379条独立凭证；进一步合并Git历史提交、共享配置文件及Agent对话记录后，总泄露量升至2539条，涉及1994个仓库和63家机构。

泄露的凭证覆盖范围相当宽：据Apiiro统计，379条数据库密码和122条Supabase服务角色密钥构成数量最大的一类；此外还有43条SSH登录凭证（部分包含服务器root密码）、42条GitHub/GitLab/npm令牌、23条AWS密钥，以及云平台凭证和私钥。Apiiro列举的典型案例包括：某数据库厂商自身的管理员级云密钥、一套生产环境Azure PostgreSQL密码、一个Square生产令牌，以及一套医疗记录数据库的所有者密码。研究人员在通知相关机构时，已有至少一家公司确认其密钥在被发现时处于有效状态。

一次正常操作，如何变成公开泄露

理解这次泄露，必须先理解Claude Code的权限设计初衷。作为终端驱动的AI编程代理，Claude Code在执行可能修改系统或涉及敏感资源的命令前，会向开发者请求确认——这层确认本是安全护栏。但为减少重复弹窗对工作流的干扰，工具提供了"不再询问"选项：一旦勾选，该命令的完整字符串被记录为一条"允许规则"，日后无需再次确认即可直接执行。

问题出在"完整字符串"这四个字上。如果一名开发者让Claude Code去测试数据库连接、调试API认证或排查登录失败，Claude生成的命令往往直接包含配置文件中读取的凭证——例如带有密码的JDBC连接串、携带Bearer令牌的curl请求、或含有API密钥的环境变量赋值语句。当开发者点击"不再询问"时，这条包含密钥的命令原封不动地落入settings.local.json。此后，一次普通的git add和git push，就足以把它发布到全世界。

Apiiro使用Claude模型Opus 5.5和Fable 5.1复现了上述行为，确认其具有可重复性。这一路径并不涉及任何攻击技巧或账号劫持——它完全发生在正常的开发审批流中，是工具的设计行为与开发者习惯之间交互的产物。

内置防护为何失效

Claude Code按照Anthropic的设计，当工具在Git仓库内首次写入settings.local.json时，会将该文件路径添加到用户全局的Git排除列表（global git excludes），使该台电脑上的所有仓库均忽略此文件。这是一个确实存在的防护措施，但其覆盖范围有三处关键空白。

其一，全局排除规则只存在于写入时的那台电脑，不会随项目目录传递给其他协作者或CI/CD系统。其二，Claude Code不会在项目自身的.gitignore文件中添加排除条目，意味着换一台机器clone项目后，该文件就不再受保护。其三，对于已经被Git追踪的文件，全局排除规则不产生任何效果——文件一旦入库，后续修改仍会被提交。Apiiro在追踪的1105个受影响仓库中，发现有539个仓库存在署名"Claude”为共同作者的提交修改了此文件，暗示在相当多的情况下，是Claude代理自己将文件提交进了版本历史。

泄露的持久性同样超出直觉。Apiiro发现74个仓库的211个派生（fork）副本中，携带了与原仓库完全相同的密钥；另有509个仓库的历史提交中存在734条额外密钥，其中大多数情况是有人删除了当前文件，却没有清理Git历史。这意味着从仓库中移除文件并不能消除风险，历史快照和衍生副本会持续保留那条凭证。

标准扫描工具对这类泄露的检测并不完整。在1122个含密钥的文件中，主流密钥检测工具Gitleaks仅标记出564个，检出率约为50%。另一款工具TruffleHog的覆盖率有所不同，但两者都未能全量识别。部分原因在于，存储于"允许规则"中的命令字符串格式多样，密钥未必以通用的正则模式出现，而是藏在完整的shell命令上下文中。

这一发现揭示了哪些更深层的问题

对于普通开发者而言，核心风险在于认知盲区。"不再询问"作为一个减少摩擦的可用性功能，其使用场景恰恰是开发者最专注、最不倾向于审查副作用的时候——流状态中的一次点击，可能在事后数周都不会被发现。许多开发者不会主动检查配置文件究竟写入了什么内容。

对于企业安全团队而言，这份报告提出了一个新的攻击面类别：AI编程代理的配置文件泄露。传统的密钥扫描工具针对代码文件中硬编码凭证设计，对JSON格式的"允许规则"命令串覆盖不全。企业现有的开发规范——比如强制要求.gitignore包含特定路径——需要更新以覆盖AI工具生成的本地配置文件。

对于Anthropic而言，早在2025年8月，就有用户在Claude Code的GitHub问题追踪器中报告了明文凭证存储的问题，据报道没有收到Anthropic的回复。这意味着从社区首次反映到安全公司大规模扫描确认，中间间隔了约15个月。

对于整个AI编程工具赛道而言，Apiiro对比了16款编程代理工具的文档，发现这类凭证持久化问题并非Claude Code独有——但Claude Code的用户体量和市场知名度，使这次曝光的波及范围和舆论冲击都更为显著。这一发现实际上对整个行业构成了测试：在自主性越来越强的AI代理能够读写文件系统、执行命令的背景下，凭证如何流动、在哪里落地、由谁负责监管，是每个工具都必须给出明确答案的问题。

历史参照：GitHub密钥泄露的结构性顽疾

代码仓库中意外提交密钥是个延续十余年的老问题。GitHub从2020年代起持续强化密钥扫描和推送保护（push protection）功能，合作伙伴覆盖范围也不断扩大。然而这些机制建立在一个前提之上：密钥以可辨识的格式出现在代码文件中。

Claude Code的案例代表了一种新型变体：密钥不是由开发者手动粘贴进代码，而是由AI助手的权限记录机制以shell命令字符串的形式落入配置文件。泄露的来源从"人类的操作失误"移动到了"工具的设计决策"。这一变化要求安全扫描工具、企业审计规则，乃至开发者的认知模型，都需要做出相应调整——因为负责任的主体从单一的人变成了人与工具的交互链条。

接下来可能发生什么

Anthropic有较大可能在短期内对settings.local.json的写入机制作出调整，最直接的方案包括：在存储允许规则时剥离命令中的参数值（只保留命令模式而非完整命令串），或在写入含高熵字符串时触发主动警告，或强制在项目.gitignore中同步添加排除条目而不仅仅依赖全局配置。

GitHub等代码托管平台可能扩大密钥扫描的文件范围，将AI工具的配置文件纳入检测集。Apiiro的报告已明确指出Gitleaks等工具的覆盖缺口，这类报告通常会促使工具链跟进更新。

这次事件可能加速企业安全团队对AI编程工具实施准入审查的节奏。在医疗、金融等强监管行业，一套生产数据库密码出现在公开仓库所触发的合规后果，远超技术层面的修复代价。对于63家受影响机构中尚未轮换密钥的企业，每多延误一天，潜在的暴露窗口就持续扩大——其中至少已有一家机构确认密钥在被发现时处于有效状态。