先说结论：如果你在用 Claude Code 并且把代码推到 GitHub（或任何共享远端），花五分钟检查 .claude/settings.local.json 是否被跟踪、是否出现在仓库历史里、里面有没有密钥。2026-11-09，Ars Technica 报道了 Apiiro 的研究：该文件被上传到公开仓库超过 10 万次，其中约 1,100 个文件、涉及 63 个组织包含 API 令牌、数据库密码、私钥等密钥。正确的处置顺序是：检查 → 先轮换密钥 → 删除并防再犯 →（确有必要时）再考虑改写历史。本页是有来源的事件解释，不是产品评测：我们没有对任何厂商产品做测试；每条论断都指向原始报道或官方文档。
到底泄漏了什么，怎么泄漏的
| 事实 | 细节（报道/文档口径） | 来源 |
|---|---|---|
| 涉事文件 | .claude/settings.local.json —— Claude Code 的本地配置文件，设计上不进版本库 | Anthropic 官方文档（2026-11-11 核查） |
| 泄漏机制 | 对 shell 命令点「Yes, and don't ask again」后会存一条允许规则——命令本身常常被原样写进该文件，包括其中嵌着的凭据 | Ars Technica，2026-11-09 |
| 规模 | 该文件被传到公开仓库 10 万+ 次；约 1,100 个文件、63 个组织含密钥（公开 API 令牌、数据库密码、私钥、root 登录信息） | Apiiro，经 Ars Technica 报道 |
| 忽略为何失效 | Claude Code 配置的是开发者全局 git ignore（core.excludesFile）。它确实作用于同一台机器上的每个仓库——真正的弱点在别处：它不随克隆传播（新机器上没有这条规则），它从不自动取消已进入索引文件的跟踪（规则出现之前已提交的文件会一直被跟踪），在没有这条规则的机器上它什么也保护不了；不少报道案例里是 Claude Code 自己提交了这个文件 | Ars Technica + Anthropic 文档 + git-scm.com/gitignore（2026-11-12 核查） |
| fork 保留 | 从原仓库删除后，密钥仍可能留在各 fork 中 | Ars Technica |
| 早有报告 | 相关 bug 报告最早可追溯到 2025 年 8 月；相关报告因 60 天无动作被关闭 | Ars Technica |
| 厂商回应 | Anthropic 的 Boris Cherny（Hacker News 评论区）：团队正在「研究如何防止」；这类文件基本不该进版本库；他推荐 auto 模式和密钥扫描器，并表示未来可能把密钥扫描内置进 Claude Code | Ars Technica |
| 扫描器盲区 | 约 1,100 个公开密钥中，有 215 个未被两款常用扫描器（gitleaks、TruffleHog）发现 | Apiiro，经 Ars Technica 报道 |
Bash(mysql -u admin -pSecret123 ...) 里的密码会被永久保留；自动配置的防护是全局 ignore——它覆盖那一台机器上的所有仓库，但在其他机器的克隆上毫无作用，也从不取消已被跟踪文件的跟踪。截至我们当日核查（2026-11-11），没有已上线的产品修复或内置密钥扫描的公告——Cherny 也承认 auto 模式仍可能把敏感命令写进该文件。五分钟自检（只读操作，随处可安全执行）
- 文件现在被跟踪吗？. 在仓库根目录运行
git ls-files .claude/。输出里出现settings.local.json就是进了版本库——这对你意味着什么，取决于文件内容与谁能访问远端：先做第 3 步（查内容）再看下方决策表。被跟踪本身并不等于真实密钥已经泄漏。 - 历史上提交过吗？. 运行
git log --all --oneline -- .claude/settings.local.json。只要列出任何提交，即使今天已删除，内容也在历史里。 - 看文件里有没有敏感内容. 打开文件扫
permissions.allow条目里嵌着凭据的命令：URL 里的密码（postgres://user:pass@host）、-p密码、API key（sk-...、AKIA...）、Bearer 令牌、带登录信息的上传命令。allow 规则本该是命令前缀（如Bash(git diff:*)）——任何更长的、内嵌真实密钥的条目就是报道所说的风险。 - 共享文件也要查. 不带
.local的.claude/settings.json是设计上要提交给团队的——它从一开始就不该含密钥。用同样的方式检查它。 - 不用 git？也要查目录. 如果目录被压缩、共享或复制进过别的仓库，文件已经跟着走了。可以在 GitHub 代码搜索里搜你组织的
settings.local.json，找回被遗忘的副本。
第 3 步可用的 grep（按自己的技术栈调整）：grep -nEi "(password|passwd|token|secret|api[_-]?key|bearer |sk-ant-|sk-|AKIA|BEGIN .*PRIVATE KEY|://[^/]+:[^@]+@)" .claude/settings.local.json。想先交互式调好正则再大范围执行，可以用正则测试器——完全在本地浏览器运行，粘几行样例调好模式再去 grep 真实仓库。配置文件是 JSON，改坏了可以用JSON 报错排查。
决策表：每种情况怎么处置
| 你发现了什么 | 按这个顺序做 | 为什么是这个顺序 |
|---|---|---|
| 文件正被跟踪且含密钥 | 1) 轮换已暴露的凭据。2) git rm --cached .claude/settings.local.json，把 .claude/settings.local.json 加进仓库级 .gitignore，提交。3) 用 git log 查历史副本（下一行） | 吊销是追溯生效的；删文件不是——任何克隆过的人手里都有 |
| 现在没被跟踪，但历史里有 | 轮换凭据。只有当仓库被广泛克隆、且某些凭据确实无法轮换时，才考虑改写历史（如 git filter-repo） | 改写历史协调成本高，而且管不到 fork 和别人的克隆——轮换才是触达所有副本的办法 |
| 有 fork 或你控制外的副本 | 按已暴露处理：轮换。fork 里的内容无法可靠清除 | 报道明确指出密钥会留在 fork 中 |
| 文件只在本地、没有密钥 | 仍然在仓库级 .gitignore 加一行（它会随每个克隆走），并把凭据从命令里挪到环境变量或凭据助手 | 仓库级 .gitignore 跟着仓库走到任何地方；全局 ignore 只保护这一台机器，也不会取消已提交文件的跟踪——而且未来的你迟早会把密钥粘进某条命令 |
共享的 .claude/settings.json 里有密钥 | 轮换，然后把值挪进环境变量或凭据助手——共享文件天生会被提交，本地配置文件离「误提交」也只有一步之遥 | 文档明确说它是团队共享文件；必须保持无密钥 |
如何避免下一次
- allow 规则保持为命令前缀（
Bash(git status:*)、Bash(npm test:*)）——永远不要粘贴含密码或连接串的完整命令。 - 凭据放环境变量或凭据助手，不放在命令里，也不要挪进其他可能被提交或分享的配置文件（官方文档提供了
apiKeyHelper和env配置）。 - 用文档里的
permissions.deny让 Claude Code 远离.env和密钥目录。 - 每个仓库的
.gitignore都加上.claude/settings.local.json——仓库级文件随每个克隆走；全局忽略只存在于一台机器，也从不取消已跟踪文件的跟踪。 - 习惯性跑密钥扫描器，但要读它的边界：报道发现约 1,100 个公开密钥里 215 个逃过了两款常用扫描器。扫描干净是证据，不是证明。
- auto 模式减少权限弹窗，但按 Anthropic 自己人的说法它仍可能把敏感命令写进配置文件——上面的检查照样要做。
现状，以及我们没有做什么
截至 2026-11-11（当日核查来源）：Anthropic 已公开承认问题并正在「研究」预防措施；没有已上线的 Claude Code 内置密钥扫描公告。本页没有任何 YYSI 产品测试——我们没用任何账号、仓库，也没扫描任何厂商产品；上面的检查步骤就是普通 git 命令，作用于你自己的仓库。我们刻意不猜测地区可用性、产品版本或企业套餐差异。如果 Anthropic 在 2026-11-11 之后发布变更，请以其发布说明为准——本指南的检查步骤无论如何仍有用，因为它审计的是你的仓库，不是工具。
来源与背景：YYSI 快讯（中文版）、其依据的 Ars Technica 原始报道、以及 Anthropic 官方配置文档。
来源与核查
- Ars Technica: Claude Code is accidentally exposing secrets all over GitHub (2026-11-09) — original media report — 来源核查日期 2026-11-11
- Anthropic official documentation: Claude Code settings files (settings.local.json behavior, git ignore, permissions.deny) — 来源核查日期 2026-11-11
- Official Git gitignore documentation — core.excludesFile applies to repositories on the same machine; patterns from the global file do not travel with clones and never untrack already-tracked files (DESCRIPTION, core.excludesFile, NOTES); basis for the 2026-11-12 ignore-mechanics correction — 来源核查日期 2026-11-12
- YYSI brief covering this event (2026-11-09, both languages) — 来源核查日期 2026-11-11
来源核查日期 All event facts below were re-verified against the original Ars Technica report and Anthropic's official settings documentation on 2026-11-11 (same day as publication). YYSI performed NO product or account testing for this guide: there are no 'we tested' claims, and every check/remediation step is derived from the sourced facts and official documentation. Quote counts, organization counts and scanner-miss figures are attributed to the report; product behavior statements are attributed to Anthropic's documentation or its staff's public comments as reported. Correction of 2026-11-12: the first version described the global git ignore as "not applying at repo level", which conflated two separate Git behaviors — per the official gitignore documentation, the global ignore (core.excludesFile) does apply to every repository on the same machine; what it does not do is travel with clones to other machines, and it never untracks files already in the index. The ignore rows, decision table and prevention list were rewritten to separate those behaviors, and being tracked is no longer phrased as automatic proof of a real leaked credential. Whether a fix has shipped since 2026-11-11 should be checked against Anthropic's release notes before acting on the status section.
阅读编辑标准（EN），或发送纠错到 [email protected]。