Claude Code“不再询问”酿泄露：2539条凭证流入GitHub公开仓库

2026年11月5日，软件安全公司Apiiro发布了一份研究报告，指出Anthropic旗下AI编程助手Claude Code存在一条系统性的密钥泄露通道：当开发者在上弹的权限提示框里点下“Yes, and don't ask again”（是，且不再询问），这条批准动作就会把完整的shell命令以明文写进项目目录下的.claude/settings.local.json文件里，命令中夹带的数据库密码、API密钥或认证令牌也一并落盘。只要这个文件跟着代码被推送到公开的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去测数据库连接、调API认证或者排查登录失败，Claude生成的命令往往直接把配置文件里的凭证带了进去——带密码的JDBC连接串、揣着Bearer令牌的curl请求、含API密钥的环境变量赋值语句，都是常见情形。开发者一点“不再询问”，这条藏着密钥的命令就原封不动地进了settings.local.json。这之后，一次寻常的git add和git push，就够把它送到全世界面前。

Apiiro用Claude模型Opus 5.5和Fable 5.1把上述行为复现了一遍，确认它可以重复出现。整条路径不靠什么攻击手法，也没有账号被劫持——它发生在正常的开发审批流里，是工具的设计行为和开发者的使用习惯碰在一起的结果。

内置防护为何失效

按Anthropic的设计，Claude Code在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家受影响机构中还没轮换密钥的企业，每拖一天，暴露窗口就多开一天——至少已有一家确认，密钥被发现时仍然有效。