Newshot Claude Code 的“Don't Ask Again”文件在 GitHub 上 1,122 个公开副本中暴露密码和密钥
开发者在 Claude Code 中批准的命令里输入的密码和 API 密钥，正存放在公开的 GitHub 仓库中，任何人都能读到。
当用户选择“Yes, and don't ask again”时，Anthropic 的 AI 编程助手可以把该命令逐字保存到项目设置文件中，包括其中的机密。
软件安全公司 Apiiro 昨天表示，该文件的 1,122 个公开副本中至少包含一个机密，不过它没有测试是否还有效。研究人员本周早些时候通知的一家公司确认其密钥曾处于有效状态。
该文件是 .claude/settings.local.json。从项目中删除它并不能撤销泄露，因为旧版本仍留在 git 历史和仓库的 fork 中。研究人员的建议是先轮换：更换该文件曾经包含的每一个密码、令牌和密钥，然后再清理。
机密如何落入该文件
默认情况下，Claude Code 在运行大多数 shell 命令前会询问。根据其权限文档，如果用户选择“Yes, and don't ask again”，它会在项目内的 .claude/settings.local.json 中保存一条允许规则。之后匹配的命令在后续会话中无需询问即可运行。
该规则只覆盖提示中所提供的内容。有时是一个模式，例如 npm test *，有时是一条精确命令。当它是精确命令时，输入其中的任何密码或令牌也会以明文保存。
在公开文件中，研究人员发现了保存的命令中仍然包含机密，并且他们用最新模型 Opus 5.5 和 Fable 5.1 复现了该行为。
Claude Code 试图让该文件不被 git 跟踪。其设置文档称，第一次在 git 仓库中写入该文件时，它会将该文件添加到用户的全局 git 排除项中。那台计算机上的 git 随后会在每个仓库中忽略该文件。
这种保护只停留在某台计算机上某个用户的 git 设置中。研究人员说，对于已经提交的文件，它不起作用。Claude Code 从不将该文件添加到项目自己的 .gitignore 中，因此这种保护不会随项目一起移动。
在研究人员追踪的 1,105 个仓库中，有 539 个仓库里，一次将 Claude 列为共同作者的提交更改了该文件。他们认为这意味着 Claude 经常自己提交该文件。
Apiiro 发现了什么
Apiiro 的研究报告显示，其对公开 GitHub 的搜索在 103,617 个仓库中发现了 104,185 个该文件副本。其中约 1.1%，即 1,122 个副本，至少包含一个机密。它们总共有 1,379 个不同的机密。
当一个值匹配已知密钥格式，或者密码或令牌紧邻公共服务器地址时，它就被计为机密。还需要一名 AI 审查员同意。研究人员没有说明是否有人使用过这些机密。
超过三分之一的机密可以直接打开数据库，包括 379 个数据库密码。其他包括 43 个用于公共服务器的 SSH 登录凭据、42 个用于 GitHub、GitLab 和 npm 的令牌，以及 23 个 AWS 密钥。
这些文件的所有者中有 63 个组织，大多是大大小小的软件公司。研究人员说，最严重的案例包括一家数据库供应商自己的管理员级云密钥，以及一个医疗记录数据库的所有者密码。
截至周一，每个包含机密的文件仍在其仓库的默认分支上，其中一半的仓库里，它已经存在至少 217 天。
Claude Code 的“不再询问”文件在 GitHub 上的 1,122 个公开副本中暴露了密码和密钥
该文件的旧版本在 509 个仓库中还包含另外 734 个密钥，这些密钥不出现在任何当前副本中，通常是因为文件已被删除。分叉让这些文件传播得更远：74 个仓库的 211 个分叉带有与原始仓库相同的密钥。
在 76,011 个共享的 .claude/settings.json 文件副本中，有 298 个也含有密钥，这类文件是团队有意提交的，密钥大多位于 allow 规则内。算上这些、旧版本以及保存的 agent 聊天记录，总计 1,994 个仓库中有 2,539 个密钥。
研究人员比较了 16 种编码 agent 的文档，Claude Code 是唯一被确认默认会将完整获批命令保存到项目文件中的。
该怎么做
对于开发者，研究人员建议采取以下步骤：
- 在你的 GitHub 组织中搜索 .claude/settings.local.json 和 .claude/settings.json，并在每个仓库的 git 历史中检查它们，即使这些文件已不存在。
- 在清理之前，轮换这些文件曾经保存过的每一个密码、令牌和密钥。
- 停止跟踪本地文件：git rm --cached .claude/settings.local.json，并将其加入仓库自己的 .gitignore。
- 在你自己的电脑上打开该文件，即使它从未被提交过，删除每一条包含密钥的规则。
- 让密钥远离命令。以 secrets manager 中的变量形式引用它们，例如 $DB_URL，这样保存的规则里是变量名而不是密钥。
- 批准模式，例如 Bash(npm run:*)，而不是单条命令。
研究人员表示，从未到达 GitHub 的副本同样重要。该文件是项目文件夹中的纯 JSON，也可能留在 npm 包、Docker 镜像、zip 压缩包或同步文件夹中。
恶意软件此前就曾在开发者机器上寻找密钥。2025 年 9 月，Shai-Hulud 蠕虫在受感染的计算机上运行了 TruffleHog 密钥扫描器，该扫描器将超过一半的文件标记为含密钥。
常见的密钥扫描器会漏掉许多此类文件。研究人员在每一个副本上运行了 gitleaks 和 TruffleHog，未启用这些工具的验证步骤。在 1,122 个含密钥的文件中，gitleaks 标记了 564 个，TruffleHog 标记了 643 个，两者都未标记的有 215 个。
大多数漏检是命令中输入的密码。扫描器寻找已知的密钥格式，而 PGPASSWORD=、sshpass -p 或 mysql -p 后面的密码，在普通命令行中看起来就是一个普通的词。
对于安全团队，研究人员建议：
- 将 .claude/、.cursor/、.gemini/ 和 .specstory/ 等 agent 文件夹以及 agent 记忆文件，视为像 .env 文件一样可能存放密钥，无论是在笔记本电脑上还是在仓库中。
- 将它们加入 pre-commit 和 CI 的密钥扫描，包括 git 历史，并确保扫描器能捕获命令内部的密码，而不仅是已知的密钥格式。
- 将 .claude/settings.local.json 加入组织的 .gitignore 模板。
- 优先检查与公网服务器配对的凭据，因为正是这些凭据能提供访问权限。
早前的报告
Claude Code 用户此前就报告过这一行为。一份更早的 bug 报告于 2025 年 8 月 11 日提交，称带有 API 密钥和令牌的获批命令被逐字存储在 settings.local.json 中。
1 月 3 日，一个自动化 bot 在 60 天无活动后以“not planned”为由关闭了该报告。
截至今天，研究人员引用的四份相关报告都已被同一个 bot 关闭，最近的一份是昨天。他们说，没有一份得到 Anthropic 的回复。