Claude Code's "Don't Ask Again" Leaked Developers' Secrets to Public GitHub — Explained Honestly

Here is a security story with no villain, no hack, and no prompt injection — just an ordinary click. You ask Claude Code to check a database or call an API. It proposes a shell command carrying the password or token, and asks before running it. You pick "Yes, and don't ask again" so it stops bothering you. That approval is saved, word for word, secret included, in a file inside your project. And if that file gets committed and pushed, your credential is now sitting in a public GitHub repository for anyone to read. Security firm Apiiro scanned GitHub between 1 and 3 November 2026 and found 2,539 real secrets that got out exactly this way, across 1,994 public repositories.

Let us be precise about dates, because this is not a launch that happened an hour ago. The research was published on 5 November 2026, and it is the lead story in today's AI digests because the numbers are stark and the cause is something thousands of developers do every day without thinking. It is a warning worth acting on today, not a panic — and the difference matters, because the fix is boring, quick, and entirely in your hands.

Verdict: This is real, it is your problem to fix, and it is fixable in an afternoon. The leak is not a flaw in the Claude model — Apiiro reproduced it with the latest models, Opus 5.5 and Fable 5.1, because it is a behaviour of the tool, not the model. If you use Claude Code, spend twenty minutes today searching your public repos for the settings file, rotating anything that looks live, and making sure the file can never be committed again. Then stop worrying: the tool is still fine to use, as long as secrets never travel inside a shell command you approve.

What Apiiro found

Apiiro collected public GitHub data from 1 to 3 November 2026 using GitHub's code search. The headline numbers:

• 104,185 public copies of .claude/settings.local.json across 103,617 repositories.
• 1,122 of them (about 1.1%) contained a real secret — a key in a known provider format, or a password or token sitting next to a publicly reachable host. Those files held 1,379 distinct secrets.
• 2,539 distinct secrets across 1,994 repositories once Apiiro widened the net to git history (734 more secrets in 509 repos, mostly in files that had since been deleted), the shared settings.json teams commit on purpose, and saved agent transcripts stored in repos.
• 63 organisations affected, mostly software companies of all sizes.

The secrets themselves are the uncomfortable part. The largest categories were database access: 379 database passwords and 122 Supabase service-role keys. Then 43 SSH login credentials (some containing server root passwords), 42 GitHub, GitLab and npm tokens, and 23 AWS keys, alongside cloud platform credentials and private keys. And the named examples Apiiro chose to highlight are the kind that make you sit up: a database vendor's own admin-level cloud key, a production Azure PostgreSQL password, a Square production token, and the owner password of a medical-records database.

Apiiro notified the affected organisations on 2 and 3 November. One company confirmed its exposed key was still live. That is the only live-key confirmation in the research — which brings us to the caveat that matters most.

The caveat, stated plainly

Apiiro did not test the credentials. It tested no key and contacted no host. So the research proves exposure, not compromise: we know the secrets were public, we do not know how many were still valid, or whether anyone used them. One confirmed live key is one data point, not a rate. The honest reading is that 2,539 secrets were left in public for anyone to try, and at least one was live — which is more than enough reason to rotate, and not enough to claim a mass breach happened.

There is a second caveat about the total. The 2,539 figure rests in part on an LLM reviewer's judgement rather than a manual check of every secret, and no third party has independently repeated the counts. The 1,122-files figure is the solid core; treat the wider total as Apiiro's best count, not gospel.

Why it happens — the mechanism, step by step

Claude Code is Anthropic's terminal coding agent: it reads your project and proposes commands to run on your machine, asking permission first. The permission dialogue offers "Yes, and don't ask again" — the option every busy developer reaches for, because re-approving the same database check fifty times a day is maddening. Here is what that click actually does:

1. Claude Code saves an allow rule in .claude/settings.local.json inside the project folder.
2. The saved rule is the complete approved command, not a redacted pattern — the password, token or connection string inside it is stored in plain text, exactly as typed.
3. The file is meant to stay on your machine. Claude Code's own documentation describes a safeguard: the first time it writes the file in a git repository that does not already ignore it, it adds **/.claude/settings.local.json to your global git excludes file. But safeguards fail — a repo with its own ignore setup, a file committed before the safeguard ran, a developer who force-adds it, a shared settings file committed deliberately. Apiiro found that in 539 of 1,105 affected repositories it examined, Claude-coauthored commits had changed the settings file.
4. Once the file is in a public repository, the secret is public. Every copy Apiiro found was sitting on its repo's default branch on 2 November 2026, and most had been there a long time.

Note what this is not. It is not the model misbehaving, and it is not prompt injection — Apiiro reproduced the behaviour with the latest models, and it is the tool's own design doing exactly what it was told. It is also not new as a complaint: a GitHub issue reporting plaintext credential storage in approved commands dates back to August 2025, reportedly without a response from Anthropic. As of 8 November 2026, three days after the research was published, Anthropic has not publicly responded to it.

The part that should worry you most

It is not the 1,122 files. It is the 215 that neither of the standard secret scanners caught. Apiiro ran gitleaks and TruffleHog over all 104,185 files: gitleaks flagged 564 of the 1,122 affected files, TruffleHog flagged 643, and 215 were flagged by neither — about one in five. The reason is simple and important: these secrets are often passwords typed inside a command, next to a hostname, not keys in a recognisable provider format. A scanner looking for the shape of an AWS key will not see psql "postgres://user:[e-mail]" as a secret. A clean scan is not proof of safety. If your check is "I ran a scanner and it found nothing," that check is not enough — you need to read the files.

Check your own repos — today

Do this now, not someday. It takes twenty minutes.

1. Search GitHub for the files. In every organisation you belong to, search public repositories for .claude/settings.local.json and .claude/settings.json. Each hit is a file anyone on the internet can read right now. Read them — actually read them, do not rely on a scanner.
2. Check git history too. Deleting the file does not delete the secret: 734 of the secrets Apiiro found lived only in old commits, in files that had since been deleted. Use git log --all -p -- .claude/settings.local.json and your history-rewriting tool of choice if you find anything.
3. Treat anything live-looking as compromised. If a password, token or key in that file could still work, revoke it and rotate it. Deleting the file is not a fix — the secret has been public, and public means assume someone copied it.
4. Make the file uncommittable. Add .claude/settings.local.json to your project's .gitignore and to your global git excludes, and check that git check-ignore agrees. If your team shares settings, use the shared settings.json only for rules that contain no secrets — never paste a credential into a shared file to "make it work for everyone."
5. Check your transcripts as well. Saved agent transcripts in repos were one of the leak paths. If you store Claude Code session logs in a repo, check what is inside them before they go public.

Using Claude Code safely from now on

• Never put a secret inside a shell command. This is the root rule, and it applies to every agent and every terminal, not just Claude Code. Use environment variables, a secrets manager, or a config file that lives outside the repo — then the command Claude Code saves is psql "$DATABASE_URL", and there is nothing to leak.
• Be stingy with "Don't Ask Again." It is fine for harmless, repeatable commands. For any command that touches a database, an API, or a server, prefer the one-time approval — the extra click is the price of not storing the credential in plain text.
• Review your allow rules occasionally. Open .claude/settings.local.json and read what is in it. If you would not paste its contents into a public chat, it should not be in a file that can reach a public repo.
• Keep secrets out of shared settings. The shared settings.json is committed on purpose — that is the whole point of it — so it must never contain a credential, even a "temporary" one.
• Rotate on a schedule, not on a scare. The secrets in this story sat public for a long time before anyone looked. Regular rotation limits the damage of the next leak you do not notice, whatever tool causes it.

Who this matters for

• Anyone who uses Claude Code on a public repo. Check today. The odds any one file leaks are low — 1.1% — but the cost when it does is a production database password in public.
• Teams, more than individuals. 63 organisations were affected, and shared settings files and transcripts are team habits. One person's "don't ask again" becomes the whole team's exposure when the file is committed.
• Anyone who trusts scanners alone. One in five affected files slipped past both gitleaks and TruffleHog. Read the files.
• People building with any AI coding agent. The pattern — an agent saving your exact words, secrets included, into a project file — is not unique to Claude Code. The habit that protects you (secrets in env vars, never in commands) protects you everywhere.

The limits — stated plainly

• No hands-on testing was performed for this article. Nothing here is a hands-on finding.
• All numbers are Apiiro's. The 1,122-files figure is a count of public files; the 2,539-secret total rests partly on an LLM reviewer's judgement and has not been independently repeated.
• Exposure is proven, compromise is not. Apiiro tested no credentials. Only one affected company confirmed a live key.
• Apiiro sells security products for coding agents and has a commercial stake in this topic — a fact worth knowing, even though the underlying files are public and checkable.
• Anthropic has not publicly responded as of 8 November 2026. Nothing in this article is Anthropic's position.

The sensible next step is not to stop using Claude Code — it is to spend twenty minutes checking whether your repos are among the public ones, rotating anything that looks live, and changing one habit: secrets go in environment variables, never in a command you approve. Do that, and the next "don't ask again" click is exactly as harmless as it feels.

Sources: Apiiro research, 5 November 2026, by Shmulik Cohen and Matan Giladi ("Claude Code's 'Don't Ask Again' Feature Leaks Secrets to Public GitHub"); independent reports of the research in Cyber Security News, iTWire and The Hacker News, 6–7 November 2026; Claude Code settings documentation. All figures are Apiiro's, checked 8 November 2026. Anthropic had not publicly responded as of 8 November 2026. No hands-on testing was performed for this article. This breaking article is not the daily buyer-intent post, and it contains no affiliate links.

Comments

[Vic Moreno]

The 215 files neither gitleaks nor TruffleHog caught is the number that matters here. A pre-commit hook that refuses the local settings file by path, plus a git check-ignore step in CI, catches it without guessing what a secret looks like. Did Apiiro say how many of the 539 repos already ignored it before the Claude-coauthored commit?