11 月 9 日，AI 安全公司 Apiiro 发布报告：Claude Code 的本地设置文件正在被批量上传到公开 GitHub 仓库，里面躺着数据库密码、API 令牌和 root 登录信息。Apiiro 一共发现了超过 10 万份被上传的此类设置文件，其中约 1100 份、来自 63 个组织的文件含有真实密钥，更刺眼的是，这批密钥中有 215 个连 gitleaks 和 TruffleHog 两款主流密钥扫描工具都没能识别出来。
「Yes, and don’t ask again」的代价
泄露的源头是一个再日常不过的操作。用户在审批 shell 命令时选择「Yes, and don’t ask again」，这条授权会作为规则写入本地的 .claude/settings.local.json 文件。问题在于规则怎么写：有时以抽象模式记录，但很多时候是原样照录命令本身，而命令里往往嵌着连接字符串、令牌和登录凭据。也就是说，用户同意的每一条「放行」，都可能把一段敏感信息原封不动地存进一个文本文件。
按 Anthropic 文档的说法，这个文件会被加入开发者的全局 .gitignore，但这一设置只对已有仓库生效，不会体现在仓库层面。仓库被克隆到其他机器，或者一个原本不是仓库的文件夹后来才初始化成仓库时，settings.local.json 就可能跟着被误传上去。Apiiro 还指出了一个更被动的风险：Claude Code 在很多情况下会在用户不介入时自行提交对该文件的修改。换句话说，即使用户没打算上传，工具也可能替他们提交。
报告被关掉了
时间线同样值得记录。该问题最早在 2025 年 8 月就有人写进 Claude Code 的错误报告，相关报告均在 60 天无活动后被自动关闭。一年多之后，同一个问题以 10 万份泄露文件的规模出现在安全公司的报告里。这不是没人发现，而是发现之后没有走到修复。
事后补救的窗口也有限。文件被删除后，密钥仍可能留在原项目的分叉（fork）里，而 fork 是任何人都可以在删除前一刻创建的。对已经泄露的 215 个「扫描器盲区」密钥来说，轮换几乎是唯一可靠的处置方式。
Anthropic 的回应
Claude Code 的 Boris Cherny 在 Hacker News 上回应称，团队正在研究如何防止这一问题，同时表示这类设置文件基本不应提交到 Git 仓库，相关情况似乎只出现在「文件被手动创建并提交」时。他给用户的建议是使用 auto 模式并配合密钥扫描工具，团队也在考虑未来在 Claude Code 中内置密钥扫描。
这份回应把责任切成了两半：工具侧承认风险、承诺研究方案；用户侧则需要立刻自检。对个人开发者来说，等待产品内置防护之前，有效的动作只有两件：检查自己的 .claude 目录是否进过任何仓库的历史提交，把密钥扫描放进 CI 流程，并对历史密钥做一轮轮换。
写在最后
AI 编程工具把「自动执行」和「最小披露」放在了天平两端，这次的教训在于：授权记录本身也成了敏感数据。当一行「别再问我」被原样写进文件，再被原样写进仓库，安全边界就从命令行延伸到了版本控制系统。工具方要尽快把防护做进默认值，因为靠每个用户记住「这个文件不能提交」，在 10 万份文件面前已经被证明行不通。
配图说明：本文封面为 AI 生成图像。
参考：Ars Technica《Claude Code settings files expose thousands of secrets on GitHub》报道与少数派派早报，本文为基于公开信息的独立评述。