ClaudeCode配置文件泄露事件，一次「不再询问」导致数千密钥公开

2026年11月上旬，安全研究社区密集披露一起涉及开发工具链的系统性风险：由 Anthropic 推出的编程助手 Claude Code 所生成的本地配置文件 .claude/settings.local.json，正大规模流入公共代码仓库。这一看似微小的配置行为，已导致超过1,300个真实密钥在 GitHub 上处于可访问状态。

事件的核心触发点，是一个常被开发者忽略的交互选项——「Yes, and don’t ask again」（中文界面为“是，且不再询问”）。当用户授权 Claude Code 执行某条 Shell 命令并勾选该选项时，工具会将整条命令以明文形式持久化至项目根目录下的 .claude/settings.local.json 文件中。若该命令包含环境变量中的密码（如 PGPASSWORD=xxx）、curl 请求头中的 Token 或 SSH 登录凭证，这些敏感信息便随之被记录。

根据 Apiiro 团队10月发布的扫描结果，GitHub 公共仓库中共检出 104,185 份 .claude/settings.local.json 文件，分布于 103,617 个独立仓库。其中 1,122 份 含有至少一个真实密钥，总计 1,379 个 可识别的敏感凭据。这些密钥类型多样：379 个为数据库密码，122 个是 Supabase 的 service-role key，43 个为公网服务器 SSH 登录凭证（部分为 root 权限），另有 42 个 GitHub/GitLab/npm 令牌与 23 个 AWS 密钥。

值得注意的是，云安全联盟同期比对了16款主流编程智能体的权限管理机制，确认默认将完整命令原文写入项目文件的，仅 Claude Code 一家。其他工具多采用命令模板或参数脱敏方式存储放行规则，避免直接保存敏感字段。

问题的扩散并非源于恶意攻击，而是典型的“效率陷阱”：开发者为减少重复授权弹窗，频繁使用“不再询问”功能；而 .claude/settings.local.json 作为本地配置文件，默认不应提交至版本控制系统。Anthropic 官方文档虽指出，首次由 Claude Code 创建该文件时，会自动将其加入全局 Git 忽略列表（通过 core.excludesFile 或 ~/.config/git/ignore），但该机制存在关键盲区：

若用户手动创建该文件（例如调试时提前生成），或文件已在 Git 索引中被跟踪，则后续添加的 .gitignore 规则对其无效；
git check-ignore 对已跟踪文件一律返回“未忽略”，即便 .gitignore 中明确写了 .claude/*；
全局忽略规则无法跨设备同步——当项目被克隆至新机器，或在无历史配置的环境中初始化 Git 仓库时，该文件极易被意外提交。

一位开发者在本地测试中验证了上述机制：在其 Windows 机器的 27 个顶层 Git 仓库中，2 个磁盘存在 .claude/settings.local.json；其中 1 个（576 字节）已被 git ls-files 跟踪，且 git check-ignore 明确显示未被忽略；另 1 个虽被仓库级 .gitignore 覆盖，但其内容仍含 16 条 allow 规则。

更严峻的是，这些泄露并非一次性事件。GitGuardian 统计了2025年1月至2026年11月7日间推送的版本，发现 .claude/settings.local.json 中共出现 31,088 条不同密钥，涉及 23,276 个仓库，其中 5,343 条 在检出时仍有效。若计入团队主动提交的共享配置（.claude/settings.json）及历史对话缓存，总泄露凭据达 2,539 个，影响 1,994 个代码库，关联 63 家组织。

实际案例中不乏高危场景：一家数据库厂商将带管理权限的云 API Key 写入配置；某软件代理机构泄露了生产环境支付令牌；一份医疗记录应用的云数据库 owner 密码亦赫然在列。Apiiro 表示，虽未批量验证所有密钥有效性，但已有被通知机构反馈其密钥“仍可正常使用”。

现有防护工具对此类泄露的检出率有限。在1,122份含密钥的文件中，gitleaks 仅捕获564份，TruffleHog 捕获643份，两者均未报警的达215份。更需警惕的是，该文件在开发者本地为明文 JSON，不仅暴露于公共仓库，也可能被本地恶意程序读取——2025年9月爆发的 Shai-Hulud npm 蠕虫即携带 TruffleHog 模块，专门扫描用户本地目录中的敏感配置。

针对此次事件，Anthropic 工程师已在 Hacker News 上作出回应，承认此前未对配置文件中的敏感字段进行擦除处理，并表示正在评估技术方案，包括：

在 auto 模式下拦截含明文凭据的命令；
内置基础的敏感信息检测与脱敏逻辑；
优化首次文件生成时的 Git 忽略策略，确保跨环境一致性。

然而，技术补救无法替代用户侧的紧急响应。安全专家强调：清理顺序必须是“先轮换凭据，再删除文件”。因 Git 历史记录、Fork 分支及他人克隆副本不会随本地文件删除而消失，若不第一时间轮换所有曾出现在该文件中的密钥，风险将持续存在。

此次事件再次揭示了一个长期被忽视的现实：开发效率工具的自动化设计，若缺乏对“最小权限”与“默认安全”的深度考量，极易将便利转化为系统性漏洞。当一行配置能同时承载功能逻辑与安全边界时，任何省略确认步骤的快捷键，都可能成为打开潘多拉魔盒的钥匙。