点一下"不要再问"，数据库密码就上了 GitHub：Claude Code 这次翻车，1122 个仓库中招

点一下“不要再问”，你的数据库密码可能就上了 GitHub。安全公司 Apiiro 11 月 5 日公布的研究显示，Claude Code 有个“贴心”功能会把用户批准过的命令原样存进项目配置文件，命令里带的密码、API 密钥也一字不落。研究人员在公开 GitHub 上扫了一圈：1122 个公开仓库的配置文件里躺着真密钥，总共 1379 个不同的密码和 token。更扎心的是，去年 8 月就有人报过这个 bug，4 份报告全被机器人关了，没等来一句回应。

一次点击，密码怎么就公开了

Claude Code 跑 shell 命令之前会先问你一句。嫌它烦，很多人会顺手点“Yes, and don't ask again”，图个清静。问题就出在这一点了：这个选项不是只记住了“下次别问”，它把整条命令原样存成一条放行规则，写进项目里的 .claude/settings.local.json。要是那条命令里带着数据库连接串、API token，密钥就跟着命令一起落了盘，还是明文。

文件本身按设计应该只留在你自己的电脑上。Claude Code 也做了防护：它会在你电脑的全局 Git 忽略文件里加一行，把这个文件排除在提交之外。可这道防线有个大洞——它只写进你这台电脑的全局配置，不写进项目的 .gitignore。文件夹后来才变成仓库、换台电脑 clone、文件早先已经被提交过，这三种情况全都防不住。Apiiro 统计，539 个泄漏仓库里，改动这个文件的提交就是 Claude 自己署名提交的。AI 帮你省事，顺手把你的密钥也“省”进了公开仓库。

数字比标题更吓人

Apiiro 在 11 月 1 日到 3 日之间扫了公开 GitHub，数字都摆在台面上：104185 份 .claude/settings.local.json，分布在 103617 个仓库里；其中 1122 份（约 1.1%）含至少一个密钥，共 1379 个不同的密码和 token。把 git 历史、团队共享的配置文件、保存下来的 agent 对话记录都算上，总数涨到 2539 个密钥，涉及 1994 个仓库。

泄漏的都是什么货色？超过三分之一能直接打开数据库，包括 379 个数据库密码、122 个 Supabase 服务端密钥；还有 43 个 SSH 登录凭证、42 个 GitHub、GitLab、npm 的 token、23 个 AWS 密钥。受影响的有 63 家机构，大多是软件公司，其中包括一家数据库厂商自己的管理员级云端密钥、一个生产环境 Azure PostgreSQL 的密码、一个 Square 生产 token，还有一个病历应用数据库的 owner 密码。研究人员没有逐个试这些密钥是否还能用，但至少有一家被通知的公司确认：泄露的密钥当时还活着。

时间维度更让人后背发凉：泄漏文件的中位数“公开时长”是 217 天。也就是说，一半的泄漏文件在公开仓库里躺了 7 个多月，人人都能翻。截至 Apiiro 快照那天，所有含密钥的文件都还在各自仓库的默认分支上，没人清理过。

去年 8 月就有人报过

这事最让人窝火的部分是时间线。2025 年 8 月 11 日，就有人在 Claude Code 的 GitHub 上报过 bug：批准过的带密钥命令会被原样存进 settings.local.json。此后又有 3 份相关报告，4 份全被同一个机器人关闭了，最近一份就在研究公布前一天。据报道，Anthropic 至今没有公开回应这项研究。

Apiiro 还做了个横向对比：它查了 16 个编程助手的文档，Claude Code 是唯一一个被证实会默认把完整批准命令写进项目文件的。研究人员用 Opus 5.5 和 Fable 5.1 两个模型都复现了这个行为。说白了，这不是模型抽风，是产品设计就这么写的。方便是真方便，代价也是真代价。

扫描工具也救不了你

很多人以为仓库里跑个密钥扫描就万事大吉，数据泼了冷水：gitleaks 只检出 1122 个泄漏文件里的 564 个，TruffleHog 检出 643 个，两个工具加起来都漏掉了 215 个。很多漏网之鱼是 PGPASSWORD= 这种形式的密码，扫描器的规则库认不出来。

还有个“共享版”的问题。团队主动提交的 .claude/settings.json 也不是净土，Apiiro 在 76011 份公开副本里发现 298 份含密钥。本地版和共享版，两个文件都要查。

现在就去查的三件事

如果你用 Claude Code，这三件事今天就做，别等“有空再说”。

一是查仓库：在 GitHub 上搜你自己的仓库和组织，看 .claude/settings.local.json 和 .claude/settings.json 有没有被跟踪提交。用 git log --all -- .claude/settings.local.json 看看历史记录里有没有它，有就说明曾经公开过。

二是轮换密钥：只要怀疑泄露过，删文件远远不够。git 历史和别人的 fork 里都还留着旧版本，密钥必须作废重发，数据库密码、API token、云端密钥一个都不能留。这一步没有捷径，也别心存侥幸。

三是堵住以后：项目 .gitignore 里补上 .claude/settings.local.json，团队仓库统一检查一遍；以后别把密钥直接写进命令行，改走环境变量或者密钥管理工具。命令一时爽，轮换火葬场。

这事到底怪谁

说白了，三方都有份。Claude Code 把“记住这条命令”做成了默认行为，存的还是带密钥的完整原文，这是产品设计的锅；用户图省事点了“不要再问”，又顺手把本地文件推上公开仓库，这是使用习惯的锅；Git 的全局忽略机制只管一台电脑，不管项目本身，换个环境就失效，这是工具链的锅。

但分量不一样。普通用户很难想到，点一个“不要再问”会把密码写进一个 JSON 文件，更想不到这个文件会被 AI 自己提交。16 个助手里只有 Claude Code 这么干，说明这不是行业通用做法，是可以改、也应该改的默认行为。Anthropic 现在最该做的，是把放行规则里的密钥脱敏，或者干脆别把完整命令写进项目文件。用户这边能做的，就是先把自查的三件事做了——你的密钥可能已经在 GitHub 上躺了 217 天，而你还不知道。

你检查过自己的仓库吗？评论区说说你都翻出了什么——别贴密钥本身，只说结果就行。

来源：Apiiro 研究报告（2026 年 11 月 5 日）、The Hacker News 报道（2026 年 11 月 7 日）。文中数字均引自上述公开报道，研究人员未逐个验证密钥是否仍有效；受影响机构的具体名称未公开，本文未点名任何一家。