把.env加入忽略列表，还不一定挡住另一条泄露路径：Agent把带密码的命令写进权限配置，你再把配置提交到GitHub。原文件没有上传，密码却随另一份文件出去了。
Apiiro在11月5日发布研究，并于11月8日补充Claude Code负责人回应。报告指出，选择"Yes, and don't ask again"时，完整命令可能被保存到项目里的.claude/settings.local.json。应该检查的不只是密钥原文件，还包括命令被记录到了哪里。
图：Apiiro报告原页节选。下文数量归属该团队的公开仓库研究，不是本文扫描用户仓库所得。
这次报告到底发现了什么
研究团队统计了104,185份公开的.claude/settings.local.json，其中1,122份被判定包含真实凭据。把历史版本、共享配置和部分对话记录等来源合起来，报告给出的总数是1,994个仓库、2,539个不同凭据。
这几个数不能混写："1,122"是命中条件的文件数量，不是全部受影响仓库数；"2,539"也不是已成功登录验证的账号数量。研究者明确表示没有使用这些凭据或连接对应主机，"真实"依据格式、上下文及人工规则与模型复核，不等于逐个确认仍然有效。
11月8日更新中，报告引述Claude Code负责人表示正在研究防止这类情况的做法，包括基本密钥扫描等原型。这个回应不能理解成修复已经发版，更不能据此断言升级后旧仓库无需处理。
从一次方便的授权，到一份会被提交的文件
泄露链路有四步：配置里有凭据 → Agent把凭据拼进命令 → 用户允许以后不再询问 → 完整命令进入权限文件。之后只要该文件被纳入版本控制，凭据就可能跟随提交传播。
文件名里的local只是用途说明，不是Git权限。研究报告也承认，Claude Code会尝试把文件加入开发者的全局Git忽略规则；但全局规则不会随仓库复制，已经被跟踪的文件也不会因为后来添加忽略项而退出索引。
我用只有DEMO_NOT_A_SECRET占位文本的独立临时仓库，检查了这一点：先把文件加入索引，再添加.gitignore，git ls-files仍能列出它。执行取消跟踪后，索引中才消失，本地文件仍保留。这个实验验证的是Git行为，没有使用真实密钥，也没有推送远程。
图：临时仓库实际运行结果。补忽略规则与取消跟踪是两步；两者都不会自动抹掉此前已经发布的历史。
按三个位置检查，先别把配置贴到聊天里
先看当前索引，只列文件名，不打印可能含凭据的正文：
bash
git ls-files -- .claude/settings.local.json .claude/settings.json 有输出说明文件已受版本控制。再在本地编辑器检查permissions.allow是否包含口令、连接串、Bearer令牌或完整带凭据的命令。共享的settings.json本来可能需要提交，不应把整个.claude目录一概删除。
其次检查历史路径：
bash
git log --all --oneline -- .claude/settings.local.json .claude/settings.json它能告诉你这些路径是否出现在本地可见历史中，但不能证明远程分支、改名前路径、fork或别人克隆的副本都已查完。工作区文件已经删掉，也不代表历史里没有。
最后检查交付物：对话导出、交接笔记、打包目录和镜像构建上下文是否把Agent记录一起带走。忽略Git提交，不会自动阻止ZIP或容器复制文件。
发现凭据后，处理顺序很重要
如果真实凭据曾进入公开仓库，先在签发平台吊销或轮换，再清理权限规则和仓库。只删当前文件，旧凭据仍可能存在于历史、fork和克隆中。
对于不该跟踪的本地权限文件，在仓库.gitignore中加入精确路径.claude/settings.local.json，并在确认该文件已被跟踪后执行：
bash
git rm --cached -- .claude/settings.local.json
git check-ignore -v -- .claude/settings.local.json第一条只从索引移除文件；第二条用于确认忽略规则确实命中。随后检查暂存区，按项目流程提交这项变更。历史清理需要单独处理，不能用这两条命令声称完成了全部泄露处置。
后续让命令引用环境变量或凭据服务，避免直接把密钥值写进命令。也要留意调试输出是否把变量展开后的值重新打印出来。一次性放行某条敏感操作，与长期允许一类命令是不同决定，不要把Bash(*)当成减少打扰的通用解法。