Claude Code's “Don't Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub
A credential leak at Claude is now a trust-relationship problem between its systems and connected services, not just a contained internal issue.
A credential leak at Claude is now a trust-relationship problem between its systems and connected services, not just a contained internal issue.
Passwords and API keys that developers typed into commands they approved in Claude Code are sitting in public GitHub repositories, where anyone can read them.
When a user selects Yes, and don't ask again , Anthropic's AI coding assistant can save the command, word-for-word, including the secret, in a project settings file.
One company the researchers notified earlier this week confirmed its key had been live.
In public files, the researchers found saved commands with the secret still inside, and they reproduced the behavior with the latest models, Opus 5.5 and Fable 5.1.
Apiiro's search of public GitHub found 104,185 copies of the file in 103,617 repositories, its research write-up shows.
Anyone connected to Claude through the compromised trust relationship is potentially affected, not just Claude itself.
The real exposure here isn't the organization that leaked the credential -- it's everyone downstream who trusted the resulting package or update without knowing where it actually came from.
Removing it from a project does not undo the leak, because older versions stay in git history and in forks of the repository.
There's no patch for a leaked credential the way there is for a code flaw; the only fix is making sure it's actually dead, not just flagged as risky.
If the user picks Yes, and don't ask again, it saves an allow rule in .claude/settings.local.json inside the project, according to its permissions documentation .
Secrets also sit in 298 of 76,011 copies of the shared .claude/settings.json file, which teams commit on purpose, mostly inside allow rules.
The trust mechanism involved here is an API or master key, which is what let access move between otherwise unrelated systems.
Software security company Apiiro said yesterday that 1,122 public copies of that file hold at least one secret, though it did not test whether any still work.
The researchers' advice is to rotate first: change every password, token, and key the file has ever held, then clean up.
Claude says the credential has been revoked, and no exploitation has been confirmed so far.
If you have any integration or dependency involving Claude, rotate any credentials shared with it as a precaution, even without confirmation you were directly affected.
Whether you installed any package, image, or update from the affected registry during the exposure window is worth checking, since the compromise travels through the artifact, not just the original leak.
Your own credential inventory is worth auditing for keys or tokens with broader access than they actually need -- the same blast-radius problem applies to anything your own organization leaks.
What happened
A credential leak at Claude is now a trust-relationship problem between its systems and connected services, not just a contained internal issue.
Passwords and API keys that developers typed into commands they approved in Claude Code are sitting in public GitHub repositories, where anyone can read them.
When a user selects Yes, and don't ask again , Anthropic's AI coding assistant can save the command, word-for-word, including the secret, in a project settings file.
What changed
One company the researchers notified earlier this week confirmed its key had been live.
In public files, the researchers found saved commands with the secret still inside, and they reproduced the behavior with the latest models, Opus 5.5 and Fable 5.1.
Apiiro's search of public GitHub found 104,185 copies of the file in 103,617 repositories, its research write-up shows.
Who is affected
Anyone connected to Claude through the compromised trust relationship is potentially affected, not just Claude itself.
The real exposure here isn't the organization that leaked the credential -- it's everyone downstream who trusted the resulting package or update without knowing where it actually came from.
Removing it from a project does not undo the leak, because older versions stay in git history and in forks of the repository.
Why it matters
There's no patch for a leaked credential the way there is for a code flaw; the only fix is making sure it's actually dead, not just flagged as risky.
If the user picks Yes, and don't ask again, it saves an allow rule in .claude/settings.local.json inside the project, according to its permissions documentation .
Secrets also sit in 298 of 76,011 copies of the shared .claude/settings.json file, which teams commit on purpose, mostly inside allow rules.
Technical details
The trust mechanism involved here is an API or master key, which is what let access move between otherwise unrelated systems.
Software security company Apiiro said yesterday that 1,122 public copies of that file hold at least one secret, though it did not test whether any still work.
The researchers' advice is to rotate first: change every password, token, and key the file has ever held, then clean up.
Response
Claude says the credential has been revoked, and no exploitation has been confirmed so far.
What security teams should do
If you have any integration or dependency involving Claude, rotate any credentials shared with it as a precaution, even without confirmation you were directly affected.
Whether you installed any package, image, or update from the affected registry during the exposure window is worth checking, since the compromise travels through the artifact, not just the original leak.
Your own credential inventory is worth auditing for keys or tokens with broader access than they actually need -- the same blast-radius problem applies to anything your own organization leaks.