Claude Code Security Leak: Secrets Exposed

Claude Code’s “Don’t Ask Again” Button Wrote Secrets Into 1,122 Public Files

Apiiro scanned 104,185 public copies of a single Claude Code configuration file on GitHub and found that 1,122 of them contained at least one real credential. The mechanism is mundane: Claude Code asks for approval before running a shell command, the user picks “Yes, and don’t ask again,” and the agent saves that exact command, secret included, into .claude/settings.local.json inside the project. If the project is public, the file goes with it.

The wider sweep put 2,539 distinct secrets across 1,994 public repositories, a set that includes database passwords, AWS keys, API tokens, and SSH logins, according to Cybernews. The story moved fast across security press in the second week of November 2026, but the underlying defect is a design default that every team running a coding agent now has to reason about. No CVE has been assigned at time of writing, and none is likely: this is a persistence behavior.

Key Takeaways:

• Apiiro examined 104,185 public copies of .claude/settings.local.json and found 1,122 containing at least one real secret, per The Hacker News.
• 2,539 distinct secrets were found across 1,994 public repositories, including live DeepSeek, OpenRouter, and MiniMax gateway keys.
• Gitleaks and TruffleHog both missed 215 of the 1,122 files containing secrets, which means default scanning configuration is not sufficient coverage.
• The failure maps to CWE-312 (cleartext storage of sensitive information) and CWE-798 (use of hard-coded credentials), not to a classic exploitable vulnerability.
• Deleting the file or rewriting history does not revoke anything. Rotation is the only remediation that matters.

What “Don’t Ask Again” Writes to Disk

Claude Code runs shell commands on the developer’s machine and asks for approval first. One of the approval options persists the command so the agent will not ask again. Dark Reading describes the behavior precisely: if the choice is “Yes, and don’t ask again,” the tool saves that exact command, secret included, to .claude/settings.local.json.

The commands that matter are the ones developers run most often. A database migration against a production replica with the password inlined. A cloud CLI call with a session token exported in the same line. A curl against an internal API carrying a bearer token in a header. Each is a normal thing to ask an agent to do once. Each becomes a durable plaintext record the moment persistence is granted.

The filename is the tell. The .local suffix signals that the file is intended to be machine-specific and never shared, which is exactly the kind of path most teams assume is covered by .gitignore. Apiiro’s finding is that assumption fails at scale. Whether through a fresh clone where the ignore rule was never added, a template repository, a monorepo with a nested config directory, or a developer running git add -A, the file reaches public GitHub often enough to produce four figures of exposure.

Anthropic is considering changes to prevent further leaks, according to Notebookcheck, but existing leaks remain in place. That distinction matters for incident response: a vendor-side fix changes future writes, not the credentials already sitting in public commit history.

The Apiiro Numbers

The figures are worth laying out in full because they describe two different populations. The 1,122 number counts files. The 1,994 number counts repositories. The secret total, 2,539, exceeds both, since a single settings file can hold dozens of credentials in its saved approval entries.

The composition of the leaked material is the part most security teams get wrong when they estimate their own risk. GitGuardian’s analysis found the leaked credentials are overwhelmingly third-party gateway keys rather than Anthropic’s own: 205 valid DeepSeek keys, 62 valid OpenRouter keys, and 50 valid MiniMax keys sitting in settings.json. Anthropic API keys are comparatively rare in the dataset. That matters because gateway keys often carry billing exposure and access to multiple upstream models, and because they are frequently issued with generous rate limits and no per-key scoping.

Apiiro did not test whether the discovered secrets still worked. One company the researchers notified earlier in the week confirmed its key had been live, per The Hacker News. Assume validity until rotation proves otherwise; a credential that sat in a public repository for weeks does not become safe because nobody has visibly used it yet.

Why Standard Secret Scanning Missed 215 of the Files

Gitleaks and TruffleHog both missed 215 of the 1,122 files, according to The Hacker News. Those are the two tools most teams rely on, and their failure here is structural rather than sloppy engineering.

Saved approval entries are shell commands embedded as string values in a JSON document. The credential frequently arrives mid-line, wrapped in quotes, after a flag, adjacent to escaped characters. Detectors tuned for .env assignments and source-code string literals see a configuration file full of command text, not an assignment. Several of the affected values are also database connection strings with the password in the URI authority section, a shape that generic high-entropy rules score inconsistently.

The second failure is path coverage. Tooling that excludes configuration directories, or that allowlists files under a dot-directory because they are assumed to be local-only, will never inspect the file. Third, the high-entropy heuristic produces enough noise on command strings that teams tune thresholds upward, and the tuning that quiets false positives also suppresses true ones. None of this is a reason to drop scanning. It is a reason to write custom rules for the specific paths your engineers’ agents write to.

The pattern falls into two well-known weakness categories. CWE-312 covers cleartext storage of sensitive information; CWE-798 covers use of hard-coded credentials. The persistence step converts a transient in-memory secret into a stored one, which is precisely the transition those categories describe. The mitigation guidance in the OWASP Secrets Management Cheat Sheet applies without modification.

Audit Checklist for Repositories Using Coding Agents

Run these checks against every repository your organization owns, including forks, mirrors, and archived projects. The audit is cheap relative to a credential incident.

• Search for the path, not the secret. Query GitHub code search for path:.claude/settings.local.json across your org and personal namespaces. Also search for settings.json under .claude, since GitGuardian found gateway keys in both files.
• Walk the history, not just HEAD. A deleted file remains readable in commit history and in forks. Use git log --all --diff-filter=A -- .claude/settings.local.json to find when it first appeared and who committed it.
• Read the saved approval entries. Every persisted command is a record of what the agent was authorized to run. Look for connection strings, bearer tokens, export statements, and any command that expands a credential inline.
• Rotate anything that ever appeared. Treat exposure as compromise. Revoke and reissue database passwords, cloud access keys, SSH keys, and third-party gateway tokens.
• Add the path to ignore rules and pre-commit guards. .claude/settings.local.json belongs in .gitignore alongside .env. A pre-commit hook that blocks the path catches the case where a developer’s global ignore file is missing.
• Write custom scanner rules. Add a rule keyed to the file path with a low entropy threshold, or a pattern match on connection-string shapes. Do not rely on default rulesets that missed 215 files in Apiiro’s sample.
• Check your scan logs for what was passed. Review historical scan results for these paths to determine the window during which a credential was public, which is the input to your access-log review.

Prevention: Keep Credentials Out of Saved Approvals

The durable fix is to make the persisted command contain a reference rather than a value. If the agent runs psql "$PROD_READ_URL" with the variable resolved from the developer’s environment or a secrets manager at runtime, the saved approval entry holds a variable name, which is harmless. The same applies to API calls: pass $TOKEN, not the token.

Short-lived credentials shrink the blast radius of any miss. Workload identity federation and one-hour session tokens mean a leaked string is worthless by the time a scanner picks it up. For third-party gateway keys, which GitGuardian found to be the dominant leak category, per-key budgets and per-key model scoping limit what an attacker can do with a valid key even while it remains valid.

Persistence itself is a trade-off worth naming. Revoking the “don’t ask again” option entirely restores the approval prompt for every repeated command, which drives developers to disable the guardrails or script around them. A middle path is to persist only read-only, side-effect-free commands and require fresh approval for anything that carries a credential or touches production. That keeps the friction where it buys security and removes it where it does not.

At the organizational level, agent configuration directories deserve the same classification as build secrets. That means inventory them, exclude them from published artifacts, and include them in whatever data-loss prevention or repository scanning pipeline already covers .env files. Enterprise deployments that centralize agent configuration through device management avoid the problem for the settings they control, though per-project local files still get written on developer machines.

Detection and Response After a Leak

Prevention covers the next commit. Detection covers the ones already pushed. Both need to be running.

Push protection that blocks a secret before it lands is the highest-value control, and it is the one that would have stopped most of these exposures. For repositories where it is enabled, verify that the agent config paths are inside its scope rather than excluded by a broad configuration-directory filter.

On the detection side, alert on any commit that touches .claude/ or a comparable agent config path, so a security engineer sees the write even when the content scanner does not flag it. Alert separately on new public repositories in the organization, since a freshly published repo with a stale local config is a common path to exposure.

For credentials that may have leaked, the useful signals live in the provider’s access logs. Cloud key usage from unfamiliar ASNs, a spike in model API spend on a gateway key, authentication attempts from geographies where you have no developers, and new resources created by a previously idle principal all indicate that a leaked secret was found and used. Pull those logs for the full exposure window, not just the days after disclosure.

Response sequencing matters more than tooling here. Revoke first, then investigate. A key that was public for a week has already had whatever use it was going to get; the investigation can proceed afterward, and rotating early denies an attacker the notice that a scan triggered.

Anthropic’s Response and Open Questions

Anthropic is reportedly considering changes to how approved commands are stored, per Notebookcheck, and has not published a timeline. Until a change ships, the behavior that produced 1,122 exposed files remains the default in current installs. Teams should plan for the fix without waiting for it.

The open question is whether the convenience feature can be made safe without breaking its purpose. Persisting an approval is only useful if the exact command can be reconstructed later, and the exact command is what carries the secret. The plausible resolution is storage-time redaction of high-confidence credential patterns combined with a warning at the moment of approval, which reduces but does not eliminate exposure. That is a mitigation rather than a guarantee, and it leaves the files already on GitHub untouched.

Broader agent products face the same design pressure. Any tool that records approved actions for replay will record whatever those actions contain. When you evaluate a coding agent, ask specifically where approval state is stored, whether it is per-user or per-project, and whether the stored form includes command arguments verbatim. The answer determines whether your next git push publishes a password.

Related Reading

More in-depth coverage from this blog on closely related topics:

• The October-November 2026 Hacking Playbook
• Inside Go’s 7.5-Hour eMudhra CA Response

Sources and References

Sources cited while researching and writing this article:

• Claude Code’s “Don’t Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub
• AI Coding Agents Leak Thousands of Secrets to GitHub
• Claude Code leaks thousands of secrets on GitHub – Notebookcheck News
• Did Claude Code’s ‘don’t ask again’ option accidentally expose your enterprise’s passwords and keys?
• Claude Code settings.local.json Secrets: GitHub, Docker Hub
• CWE-312
• CWE-798
• Secrets Management – OWASP Cheat Sheet Series