1,379个密钥躺在公开仓库,元凶是那句「别再问我」

10 月里，安全公司 Apiiro 的研究团队把 GitHub 上的 .claude/settings.local.json 扫了一遍，翻出 104,185 份，散落在 103,617 个公开仓库里。

这个文件名，用过 Claude Code 的人都不陌生，它本该只待在自己电脑上。而其中 1,122 份至少藏着一个真实密钥，加起来 1,379 个，数据库密码、云平台 key、SSH 登录凭据都有。

泄露的起点不是黑客，是一个为了少点几十次确认而设的按钮。

按钮写着「别再问我」，存下来的却是整条命令

Claude Code 每跑一条 shell 命令，都会先问一句能不能执行。点得多了谁都会烦，于是很多人会选那个「Yes, and don't ask again」。这一下点击会把命令变成一条常驻的放行规则，写进项目目录下的 .claude/settings.local.json。

规则如果记的是命令模式，问题不大。麻烦在于它有时记的是完整命令，原文照抄，包括你当时敲进去的密码、token，以及带 Authorization 头的 curl。Apiiro 用当时在售的 Opus 5.5 和 Fable 5.1 都复现了这个行为，结论是它属于 Claude Code 这个工具，跟背后跑哪个模型没关系。

云安全联盟在同期一份研究笔记里补了个细节：他们比对了 16 个编程 agent 的文档，确认默认把完整命令原文写进项目文件的，只有 Claude Code 一个。

104,185 份文件里，1,122 份带着真钥匙

数字摊开更扎眼。1,379 个密钥里，379 个是数据库密码，122 个是 Supabase 的 service-role key，43 个是公网服务器的 SSH 登录，有些直接是 root，另有 42 个 GitHub、GitLab、npm 令牌和 23 个 AWS key。

把旧版本、团队主动提交的共享配置、以及 agent 留下的对话记录都算进去，总数是 2,539 个密钥、1,994 个仓库，牵涉 63 家组织。

名单里有几个不好笑的例子：一家数据库厂商把自己的云 API key 写了进去，那把 key 带管理权限；一家软件代理机构漏的是生产环境的支付令牌；还有一份是某医疗记录应用的云数据库 owner 密码。

Apiiro 没有逐把去试这些钥匙还能不能开门，但被它通知过的机构里，有一家回话说自己的 key 仍然有效。

两种最常见的误判

删掉文件就没事，这是流传最广的一种安心法。它有一半道理，文件没了就不会再被新提交带出去，却解释不了 git 历史、fork 和别人电脑里的克隆——那些副本不会因为你删文件而消失。所以顺序要反过来：先轮换所有进过这个文件的凭据，再谈清理仓库。

还有一种侥幸是觉得扫描器会兜住。实测并不乐观，1,122 份带密钥的文件里，gitleaks 报了 564 份，TruffleHog 报了 643 份，有 215 份两个工具都没作声。何况这个文件在开发者机器上是明文 JSON，盯着它的不只是爬 GitHub 的人，2025 年 9 月的 Shai-Hulud npm 蠕虫就带着 TruffleHog 翻过受害者的本地目录。

先换锁，再扫地

Anthropic 负责 Claude Code 的工程师在 Hacker News 上回应了这件事，说团队此前没做密钥擦除，现在在研究方案，包括让 auto 模式拦下这类命令、内置基础的密钥扫描，同时他也承认这些未必能根治。他补充说，这个文件首次创建时会被自动写进 gitignore，那些公开的副本是被人手动创建或主动提交上去的。

这话没错，可它改变不了另一件事：只要规则记的是字面命令，密钥就已经落在磁盘上了，后面每一步都靠人记得住。

真要处理，动作并不复杂。先轮换所有可能进过这个文件的凭据，尤其是数据库密码和云平台 key；再把它从 git 索引里移除、补进 .gitignore；以后需要密钥就引用环境变量，别直接敲进命令；批准时尽量用模式匹配，而不是整条原文。已经在用密钥扫描的托管平台，值得把仓库历史也跑一遍。

边界也要说清：如果你从没点过「别再问我」，或者根本不用这类 agent 工具，眼下的风险确实不大；但团队仓库值得花五分钟搜一次这个文件名。

自查这件事，最好赶在别人扫到你仓库之前。

你可以在自己的仓库里搜一下这个文件名，搜到了就回来说一声，我挺想知道有多少人踩过。

作者提示含AI生成内容。作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～