不安全——删除泄露文件只是往仓库里多提交了一条"我删过"的记录，密钥本身并不会随之消失。围绕 Claude Code"不再询问"授权把密码写进 `.claude/settings.local.json` 并随代码推上 GitHub 的这次泄露事件，GitHub 官方文档给出过明确答案：泄露的如果是凭据，第一步是撤销或轮换密钥，再考虑清理历史，因为即便改写历史、强制推送，克隆、fork 和缓存视图里的旧提交仍可能被访问。两家安全公司的独立测量说明了残留的规模，其中 GitGuardian 对公开 GitHub 的持续监测显示，仅 `settings.local.json` 一个文件就出现过 31,088 个不同密钥，其中 5,343 个在检出时仍然有效。GitHub DocsGitGuardian
一点"不再询问"，密码就进了命令前缀
这次事件的入口是一个很常见的操作：Claude Code 要执行 Shell 命令时会弹出确认框，选择"是，且不再询问"后，被批准的整条命令前缀会原样写进仓库根目录的 `.claude/settings.local.json`，成为永久生效的 allow 规则。如果命令里内嵌了密码——例如 `PGPASSWORD=xxx psql …` 这种写法——授权规则保存的那一刻，明文密码也一起落了盘。Apiiro 报告中的示例提示框显示，这串密码同时出现在命令行和"不再询问"的选项文本里。Claude Code 文档
GitGuardian 研究人员抽查了 3,000 个实例，发现每一条泄露密钥都处在与权限提示写入格式完全一致的 allow 规则里，不是开发者手打的——机制本身就在记录凭据。而文件防外泄的靠子是"自动加进 git 忽略"，这层保护写在机器上而不是仓库里：Claude Code 创建文件时才会把它加进全局 git excludes，手工创建的文件需要开发者自己处理。据 IT之家援引 Ars Technica 报道，当项目被克隆到另一台电脑、或普通文件夹后来才初始化成 Git 仓库，密码就可能随 `git add` 一起误传进版本库。研究还称，Claude Code 有时会在未经确认的情况下自行提交设置文件变更。GitGuardianClaude Code 文档IT之家
删掉文件之后，密钥住在哪里
删除文件并不等于从历史里抹掉内容：即使改写历史并强制推送，旧提交仍可能通过 GitHub 缓存视图按提交 SHA-1 直接访问，也存在于任何克隆与 fork 之中，而其他用户已经拉走的副本更是无从触及。GitHub 支持只会在判定"轮换无法消除风险"的情形下协助清除缓存，官方口径本身就把轮换凭据排在清理动作之前。GitHub Docs
监控器让"已删除"更难自证：GitGuardian 持续扫描每一个公开推送，之后被删除、改写或强制推送掉的版本同样留有记录。Apiiro 除快照统计外还对 43,120 个仓库与 211 个 fork 做了历史扫描，只在 `settings.local.json` 的当前副本中就数出 1,379 个密钥，历史版本里另有 734 个。换句话说，删了并不等于没了——这也是同一事件两份统计相差一个量级的原因：一个数的是 11 月初默认分支上还活着的文件，一个数的是 17 个月里被推送过的每一个版本。GitGuardian
自动撤销也兜不住大多数残留：GitGuardian 统计的检出密钥中 63% 是不带服务商格式的自定义密码与令牌，GitHub 密钥扫描的合作方撤销机制无法覆盖；同一批凭据还随镜像外流，在 Docker Hub 公开镜像中出现 613 个、检出时 99 个仍然有效——GitHub 撤销掉的，Docker Hub 还留着。
风险有多大：两份测量对上了同一个结论
泄露并非新近才发生。据 Ars Technica 11 月 9 日对 Apiiro 11 月 5 日报告的报道，公开仓库上能找到超过 10 万份这份本地设置文件，其中约 1,100 份含有数据库密码、API Token、私钥或 root 登录信息等机密数据；结合 Git 历史、共享设置文件与智能体聊天记录，共识别出 1,994 个代码库中的 2,539 个真实凭据，受影响对象包括 63 个组织，从学生团队、初创公司到成熟供应商都有。泄露内容涉及 Azure 数据库密码、Square 生产令牌、SSH root 登录信息，甚至医疗记录数据库的拥有者密码。文件越大越危险：每十个超过 8 KB 的设置文件中就有一个包含真正的秘密，小于 500 字节的文件这一比例不到五百分之一，点"不再询问"用得越久，文件攒下的密钥越多。IT之家
GitGuardian 把统计口径拉到 2025 年 1 月至 2026 年 11 月 7 日的 17 个月：`settings.local.json` 里共出现 31,088 个不同密钥，分布在 23,276 个仓库、出自 11,336 名作者，连团队共享、本就该提交的 `settings.json` 也查出 8,271 个不同密钥。GitGuardian 特别说明了口径分歧：一方数的是"曾经推送过什么"，另一方数的是"检出时仍有效的每一个凭据"，并强调后者才是应当被轮换的凭据数量。GitGuardian
趋势上确有缓和迹象：月度检出量从 8 月的 1,916 个降到 10 月的 959 个，较峰值下降约九成，但 GitGuardian 明确表示无法确定原因，候选解释包括 Claude Code 权限提示或忽略处理的变化、GitHub 推送保护等，剩下的疑问交给了 Anthropic。GitGuardian
官方怎么回应，你现在该做什么
Claude Code 负责人 Boris Cherny 11 月 7 日在 Hacker News 回应：Claude Code 历史上没有做过密钥清洗，团队正在研究预防措施。他表示 `.claude/settings.local.json` 本应保持本地、不该提交进版本控制，Claude 创建该文件时会自动 gitignore，这次暴露的文件多为手动创建并提交所致；他同时建议改用默认启用的 auto mode 替代逐条允许规则，并在代码托管平台开启密钥扫描。据 Ars Technica 报道，Anthropic 还考虑把密钥扫描功能内置进 Claude Code——截至 11 月 10 日，带密钥脱敏的版本尚未发布。Hacker NewsIT之家
对用户来说，补救顺序比清理动作更重要。第一步永远是撤销或轮换可能暴露的凭据——密钥只要还有效，存在哪个角落都一样危险；等轮换完成，删文件、改写历史反而常常不再必要。随后自查 `.claude` 目录是否被 Git 跟踪（`git ls-files .claude`），检查设置文件旧版本是否留在提交历史里，并记得 fork、他人克隆、第三方扫描存档这些自己够不到的角落。日常使用上，含内嵌密码的命令不要点"不再询问"，把凭据交给环境变量或密钥管理器而不是命令行明文；条件允许时开启密钥扫描与推送保护，换机、新建克隆后确认 `.claude` 目录仍处于忽略状态。这次事件给所有具备文件读写和命令执行能力的 AI 编程工具提了同一个醒：被授权"永久记住"的从来不只是命令，还有命令里的钥匙。GitHub DocsClaude Code 文档
