Claude Code 把密钥送进了公开仓库：一份自查清单

2026 年 11 月 9 日，Ars Technica 报道了一个和 Claude Code 有关的问题：一些项目的配置文件被提交进了公开的 GitHub 仓库，里面带着密码、API key 之类的凭据。报道的摘要把起因指向一句熟悉的提示——“不要再问”，用户点了它，密钥就被写进了会进版本库的文件。

先把边界说清楚：我们没有读过这篇报道的正文，也没有复现这次泄露。下面的信息只来自报道的标题与摘要，其余是我们给出的通用自查方法，不包含任何“已经泄露了多少仓库、多少密钥”的数字。

这篇讲的到底是什么

• 出问题的不是模型输出，而是开发者的本地配置：Claude Code 的配置文件里可以写环境变量、权限允许列表、钩子命令
• 这些文件默认放在项目目录下的 .claude 里，一旦执行 git add .，就会跟着代码一起进仓库
• 仓库如果是公开的，提交历史里的密钥就等于公开了；删掉文件不等于删掉历史
• 报道的标题用了“意外”（accidentally），这不是有人在攻击，而是日常操作里的疏忽

和“邮箱外泄”那件事不是一回事

• 我们此前写过另一篇：Claude Code 把账号邮箱写进请求头，发给第三方网站；那是“请求时带出去”
• 这篇讲的是“存下来”：配置文件里的密钥被提交进公开仓库，任何能浏览仓库的人都能看到
• 两者的触发点、影响面和补救方式都不同：前者要改请求头的生成逻辑，后者要清理版本库并轮换凭据
• 不要把两件事的结论互相套用。看到“Claude Code 泄露”这类标题，先分清是哪一种

为什么这类文件容易进仓库

• 配置文件通常就在项目根目录，和代码混在一起，提交时很难被注意到
• 有些团队把 .claude 当成项目的一部分共享给同事，于是它天然被 git 跟踪
• 本地覆盖文件与共享文件名字相近，一个该忽略、一个该提交，很容易搞反
• 一旦密钥进过一次历史，后续即使删掉，旧的提交仍然可以被检出

自查清单

• 先看工作区：列出项目里所有 .claude 相关的文件，逐个确认是共享配置还是本地覆盖
• 再看跟踪状态：用 git status 与 git ls-files 确认哪些配置文件已经被 git 管理
• 然后查历史：git log 按文件路径过滤，看看这些文件是否曾经被提交过，包括后来删掉的那些
• 查内容：在历史里搜索常见的密钥形状，比如长串随机字符、以 sk- 开头的 token、私钥头
• 查远端：仓库如果公开过，即使后来转为私有，fork 与缓存也可能仍然存在
• 查周边：dotfiles 仓库、备份目录、CI 日志、粘贴板历史，都可能是同一条密钥的另一个出口

发现泄露之后怎么办

• 先轮换，再清理。密钥一旦进过公开仓库，就应当视为已泄露，直接作废并换新
• 清理历史要用专门工具重写提交；普通删除只会新增一个“删除文件”的提交，旧内容仍在
• 重写历史需要强制推送，会影响所有协作者；已经存在的 fork 不会被你的重写覆盖
• 如果仓库托管在公开平台，可以考虑联系平台处理缓存与搜索结果，但不要把它当成主要补救手段
• 轮换完再检查一遍：新密钥有没有又以同样的方式被写进文件

怎么防止下一次

• 把本地覆盖文件写进 .gitignore，共享配置里只放不含密钥的默认值
• 密钥走环境变量或密钥管理服务，不要在配置文件里写明文
• 提交前用钩子或扫描工具过一遍暂存区，拦截疑似密钥
• 给团队定一条规则：任何要提交的配置，先假设它会被公开
• 定期跑一次历史扫描，而不是等出事再查

我们核实了什么

• 核对了报道的标题、链接与发布时间；报道指向的是 Ars Technica 的 AI 版块
• 在 Hacker News 上换了几个关键词检索，没有找到对应的讨论条目；这不代表报道有误，只说明它没有在那里被讨论
• 我们没有读报道正文，也没有复现泄露，更没有统计受影响的仓库或密钥数量
• 上面的清单是通用的密钥卫生做法，不依赖这次事件的具体细节

本文基于以下公开报道整理。

参考来源

• Ars Technica：Claude Code is accidentally exposing secrets all over GitHub{: rel=“nofollow noopener” target="_blank"}（2026-11-09）
• GitHub 代码搜索：.claude/settings.json{: rel=“nofollow noopener” target="_blank"}（检索入口，未抓取结果）

本文由 AI 辅助整理，事实来自上方公开报道的标题与摘要；我们未读正文、未复现泄露，自查清单为通用建议。