Claude Code's "Don't Ask Again" exposes passwords in 1,122 public GitHub files
626 points
• 5 days ago
• Article
Link
Apiiro 的研究发现了一个与 AI 代码代理（尤其是 Claude Code）相关的广泛安全漏洞。当开发人员使用这些工具执行诸如检查数据库或调用 API 等任务时，这些代理通常需要密码或云密钥等敏感凭据（secrets）。如果开发人员在系统建议的命令中选择了"don't ask again"，代理会将整段命令（包括敏感凭据）保存到本地设置文件中。随后，这个文件经常会被提交到代码仓库，导致敏感信息被任何有权访问该项目的人意外看到。
这次泄露的影响范围很大：在 1,994 个公开 GitHub 仓库中共发现了 2,539 个真实存在的 secrets 。这些泄露的凭据从数据库密码和云 API 密钥，扩展到 SSH root 登录名以及各类服务的生产 token 。至少有 63 个组织受到影响，其中包括软件公司、 B2B 初创企业和 IT 服务机构。部分有记录的案例中，暴露的 secrets 还包含生产数据库的管理员级访问密钥与密码，凸显了对组织安全的重大威胁。
该问题之所以长期存在，主要原因在于 Gitleaks 和 TruffleHog 等常见的 secret 扫描工具往往无法识别这些泄露。此类扫描器通常只会查找可识别的密钥格式，例如特定前缀或较长的随机字符串。但许多泄露的 secrets 被以纯文本密码形式嵌入到 shell 命令中。由于它们在常见命令行结构里看起来就是普通单词，自动化安全扫描器经常会漏检。更严重的是，这并不局限于单个配置文件：代理还会把 secrets 记录到聊天记录、 memory 文件以及 handoff notes 中，而这些内容有时同样会被提交到版本控制系统。
建议开发人员和安全团队立即采取措施来降低风险。开发人员应检查仓库中是否存在与代理相关的配置文件夹，对敏感文件执行 git 取消跟踪操作，并将其加入忽略列表。任何可能已经被提交到历史记录中的凭据都必须进行轮换，因为如果 secret 仍然保留在仓库的过去提交或分支、以及衍生的 fork 中，仅删除文件并不能解决问题。后续开发中，开发人员应避免直接在命令中输入 secrets，改用环境变量或成熟的 secrets 管理工具。
对安全团队而言，建议将诸如 .claude/ 和 .cursor/ 等与 AI 相关的目录，按与敏感环境文件同等的标准进行审查。应更新安全策略，把这些路径纳入 pre-commit 与 CI 扫描流程，并确保检测逻辑足够健壮，能够发现嵌入在命令行参数中的密码。通过主动管理 AI 工具与项目环境的交互方式，并对 secret 处理执行更严格的规范，组织可以避免这些无意泄露对基础设施造成破坏。
Research conducted by Apiiro has uncovered a widespread security vulnerability linked to AI coding agents, specifically Claude Code. When developers use these tools to perform tasks like checking databases or calling APIs, the agents often require secrets such as passwords or cloud keys. If a developer chooses the "don't ask again" option for a proposed command, the agent saves the entire command string, including the sensitive credentials, into a local settings file. This file is then frequently committed to code repositories, inadvertently exposing secrets to anyone with access to the project.
The scope of this exposure is significant, with 2,539 real secrets identified across 1,994 public GitHub repositories. These leaked credentials range from database passwords and cloud API keys to SSH root logins and production tokens for various services. At least 63 organizations, including software companies, B2B startups, and IT services firms, have been affected. In several documented instances, the exposed secrets included administrative-level access keys and passwords for production databases, highlighting a major risk to organizational security.
A primary reason this issue persists is that standard secret scanning tools like Gitleaks and TruffleHog often fail to detect these leaks. These scanners typically look for recognizable key formats, such as specific prefixes or long random strings. However, many of the leaked secrets are embedded as plain-text passwords within shell commands. Because these appear as ordinary words in common command-line structures, automated security scanners frequently overlook them. Furthermore, the problem extends beyond a single configuration file, as agents also record secrets in chat transcripts, memory files, and handoff notes, all of which are sometimes committed to version control.
Developers and security teams are advised to take immediate action to mitigate these risks. Developers should check their repositories for agent-related configuration folders, untrack sensitive files using git, and add them to their ignore lists. It is essential to rotate any credentials that may have been committed to history, as simply deleting the file is insufficient if the secret remains in the repository's past commits or forks. Moving forward, developers should avoid typing secrets directly into commands, opting instead for environment variables or established secrets managers.
For security teams, the recommendation is to treat AI-related folders like .claude/ and .cursor/ with the same scrutiny as sensitive environment files. Security protocols should be updated to include these paths in pre-commit and CI scanning, ensuring that the detection logic is robust enough to catch passwords embedded in command-line arguments. By proactively managing how AI tools interact with project environments and enforcing stricter practices regarding secret handling, organizations can prevent these inadvertent exposures from compromising their infrastructure.
429 comments • Comments Link
- Claude Code 的发展历程中一直缺少原生的 secret scrubbing 功能，因此用户有时会不小心把包含敏感凭据的本地配置文件（例如 `.claude/settings.local.json`）提交到版本控制系统。
- 尽管 Claude Code 会自动添加 `.gitignore` 条目，但不少用户会手动创建或错误处理这些文件，导致它们仍被纳入跟踪；一旦仓库是公开的，就可能直接暴露。
- 关于"Auto Mode"存在很大争议。支持者认为它是手动审批的更安全替代方案，因为它能避免"approval fatigue"（人类在面对危险命令时会产生条件反射式的批准）。
- 批评者则指出，"Auto Mode"并不能提供可验证的安全保障：它缺乏清晰的威胁模型，依赖主观且非确定性的判断，而这种判断无法像沙盒或容器化环境那样进行逻辑推理。
- 人工审批经常被工具生成命令的复杂度卡住，例如冗长、晦涩的 bash 管道命令，使得真正有意义的审查变得困难，从而更容易滑向危险的"盲目批准"。
- 许多开发人员主张使用更强且确定性的沙盒技术，例如在配置严格的临时容器或 VM 中运行代理，并通过严格限制网络与文件系统来降低风险，这被认为是降低风险的唯一可行路径。
- 也有强烈观点认为：让 AI 模型进行自我调节、甚至"自我批准"本身就是有缺陷的设计，把本应由工具开发者承担的安全责任转移到了最终用户身上。
- 部分开发人员建议引入更先进的技术，比如"Threat Image Projection"（通过故意插入虚假的恶意命令来测试用户警觉性），以及代理出口代理（agent egress proxies），以把 AI 交互与真实的 secret 处理过程分离开。
- 这种讨论反映出人们对主要 AI 供应商在问责与专业严谨性方面不足的更广泛沮丧：他们被认为在没有足够护栏的情况下，把潜在危险的工具推向了生产环境。
- 改进建议包括强制 secret scanning 、提供更细粒度的控制"hooks"、使用需要人工验证的专业凭据管理器（例如 1Password CLI），以及避免进行全局的 git 提交。
- 这场讨论凸显了"零摩擦"的 AI 辅助开发理想与现实中的现代安全风险之间的根本矛盾。各方在一个关键问题上分歧很大：AI 代理是否能通过自动化的"Auto Modes"实现真正安全，还是必须依靠沙盒与人工验证来实现完全隔离。尽管如此，参与者形成了强烈共识：当前的工作流程——尤其是允许工具管理可能无意中包含 secret 的项目文件——从根本上是不可靠的。最终，这场辩论强调的，是整个行业在权衡"vibe coding"的巨大效用与安全软件工程传统的不可妥协要求之间所进行的长期拉扯。 • Claude Code historically lacks native secret scrubbing, leading to instances where users accidentally commit local configuration files (like `.claude/settings.local.json`) containing sensitive credentials to version control.
• While Claude Code automatically generates `.gitignore` entries for its settings, many users manually create or incorrectly handle these files, leading to them being tracked and subsequently exposed if the repository is public.
• A significant point of contention exists regarding "Auto Mode," which proponents describe as a safer alternative to manual approval because it avoids "approval fatigue," where humans reflexively approve dangerous commands.
• Critics argue that Auto Mode provides no verifiable security guarantees, lacks a defined threat model, and relies on subjective, non-deterministic judgments that cannot be reasoned about like sandboxed or containerized environments.
• Human approval is often hampered by the complexity of tool-generated commands, such as long, obfuscated bash pipelines, which make meaningful review difficult and lead to dangerous patterns of blind approval.
• Many developers advocate for robust, deterministic sandboxing, such as running agents in ephemeral containers or VMs with strict network and filesystem restrictions, as the only viable way to mitigate risk.
• There is a strong sentiment that relying on AI models to self-moderate or "self-approve" is a flawed design, shifting the responsibility of security from the tool developer to the end-user.
• Some developers suggest advanced techniques like "Threat Image Projection" (intentionally introducing fake malicious commands to test user alertness) or agent egress proxies to separate AI interaction from actual secret handling.
• The discourse reflects a broader frustration with the perceived lack of accountability and professional rigor from major AI vendors, who are seen as pushing potentially dangerous tools into production environments without sufficient guardrails.
• Technical suggestions for improvement include mandatory secret scanning, implementing better "hooks" for granular control, using specialized credential managers (e.g., 1Password CLI) that require human verification, and avoiding global git commits.
The discussion highlights a fundamental tension between the desire for frictionless AI-assisted development and the reality of modern security risks. Participants are deeply divided on whether AI agents can be made safe through automated "Auto Modes" or if they require total isolation through sandboxing and manual verification. There is a strong consensus that current workflows—specifically the practice of allowing tools to manage project files that can inadvertently contain secrets—are fundamentally broken. Ultimately, the debate underscores an industry-wide struggle to balance the immense utility of "vibe coding" with the traditional, non-negotiable requirements of secure software engineering.