Claude Code's 'Don't Ask Again' Leak: How 2,539 Secrets Ended Up on Public GitHub, and How to Check Your Repos

Claude Code secrets leak - laptop with code, glowing folder, and a magnifying glass over a document with a key

AI-generated illustration of a developer's desk at night, with a laptop showing code, a glowing folder, and a magnifying glass over a document with a key symbol.

Security firm Apiiro reported on 5 November 2026 that thousands of real passwords, API keys and cloud credentials are sitting in public GitHub repositories — not because of a breach, and not because anyone hacked GitHub, but because of a convenience feature in Anthropic's AI coding assistant, Claude Code. When a developer clicks "Yes, and don't ask again" on a command that contains a secret, Claude Code saves that exact command, secret included, into a settings file inside the project folder. If that file is later committed to a public repository, the secret is public too, readable by anyone who opens the repo. Apiiro counted 2,539 real secrets across 1,994 public repositories. This guide explains how it happens, what the researchers actually found, what Anthropic has said so far, and — most importantly — how to check your own repositories and fix it before someone else finds your keys first

Two cautions before the detail, because the numbers in this story are easy to overstate. First, this is a story about exposure, not confirmed theft: Apiiro did not test whether the credentials still work, and it says it does not know whether anyone has used them — although one company it notified confirmed its key was still live. Second, Apiiro sells security tools for AI-assisted development, so this research also serves its business; the figures below come from its published research and from The Hacker News' report of it, and the limits of that research are stated where they matter. Neither caution makes the risk go away. A password that is public is a password you should treat as compromised, whether or not anyone has used it yet.

As an Amazon Associate, we earn from qualifying purchases.

AMAZON'S CHOICEASUS Prime GeForce RTX 5060 8GB GDDR7 OC EditionVRAM: 8GB GDDR7, Amazon's Choice, 50+ bought in past monthView deal at Amazon >32GB DDR5CORSAIR Vengeance DDR5 32GB (2x16GB) 6000MHz32GB (2x16GB) DDR5-6000, CL38, AMD EXPO + Intel XMP 3.0View deal at Amazon >850WCORSAIR RM850e (2025) Fully Modular ATX Power Supply850W, fully modular, ATX 3.1, PCIe 5.1, native 12V-2x6, Cybenetics GoldView deal at Amazon >

Prices and savings can change. Check the retailer for the current price.

How one click saves your password

Claude Code asks permission before it runs most shell commands, and one of the answers on offer is "Yes, and don't ask again". That option exists so the assistant stops interrupting you with the same approval for a command you run often. The trade-off is in what it records: the tool saves the approved command, word for word, as an allow rule in a file called .claude/settings.local.json at the root of the project, so it can approve the same command automatically in future sessions. If the command you approved contained a password, a token or a connection string typed into it — a database query with PGPASSWORD=, a curl call with an API key, an SSH login with sshpass — that secret is saved verbatim too, in plain text, in a file inside your project folder.

Apiiro says this is Claude Code's own behaviour, not a quirk of one model: its researchers reproduced it with two recent Anthropic models, Opus 5.5 and Fable 5.1. The file is meant to stay local, and Claude Code does try to keep it that way — when it creates the file inside a git repository, it adds it to the developer's global git excludes. But that protection is weaker than it sounds. A global exclude is machine-local: it does not travel with the repository, so it disappears on forks, clones and copies of the project on other machines, and it does not apply to files that were already tracked by Git, or to files a developer created manually. Nothing inside the repository itself marks the file as private. And in many cases the agent is the one doing the committing: in 539 of the 1,105 repositories Apiiro traced, a commit co-authored by Claude itself had touched the file.

What Apiiro found: the numbers

Between 1 and 3 November 2026, Apiiro ran read-only GitHub code and commit searches over public copies of the file. It found 104,185 public copies of .claude/settings.local.json in 103,617 repositories, and 1,122 of those copies — about 1.1% — held at least one real secret, 1,379 distinct secrets in total. When the researchers widened the net to older copies in git history, shared settings files and saved agent chat transcripts, the total reached 2,539 real secrets across 1,994 repositories. A "real secret", in Apiiro's method, means a value that matched a known provider's key format, or a password or token sitting next to a public server address and confirmed by an AI reviewer — not proof that every key still works, but far more than a placeholder or an expired test value.

More than a third of the secrets would open a database directly, including 379 database passwords. The haul also included 398 service API tokens, 149 AI model API keys, 122 Supabase service-role keys, 110 Google API keys, 103 Supabase account tokens, 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. The worst individual cases Apiiro names are the kind that keep security teams awake: a database vendor's own admin-level cloud key, a production Azure Postgres password, a Square production token, and the owner password of a medical-records database. The researchers traced the files to 63 organisations, mostly software companies of all sizes, reported each case to its owner on 2 and 3 November, and say one company confirmed its key had been live.

The exposure is also old, not a one-day accident. In half of the affected repositories, the file had been sitting on the default branch for at least 217 days. Another 734 secrets existed only in git history, across 509 repositories — in most cases because the file had been deleted from the current version, while older commits still carried it. And 211 forks carried copies of their own, which the original owners cannot clean up. That is the detail that makes this leak different from an ordinary misconfigured file: deleting it today does not undo it.

Why deleting the file is not enough

The instinctive fix — delete the file, push, move on — is the wrong order of operations, and Apiiro's numbers explain why. Git keeps history: every old commit that ever contained the file still contains it, and anyone can check out that commit and read it. Forks are separate repositories that you do not control, so a copy you never knew existed can outlive your cleanup. Deleting the file from the current branch only stops new readers from finding it in the obvious place; the secret itself remains valid until you revoke it.

So the order matters, and it is the reverse of what feels natural. Rotate first: revoke or replace every credential the file ever held, starting with database passwords, cloud keys and production tokens, and only then clean up the repository. A rotated key is harmless wherever it still sits; a deleted file with a live key is still a live leak. If you are not sure which credentials the file held, assume all of them: check the file's full history, not just its current contents, and rotate anything that appears in any version.

Why secret scanners will not save you

Apiiro ran two popular open-source secret scanners, gitleaks and TruffleHog, over all 104,185 public copies of the file. Of the 1,122 files with a real secret, gitleaks flagged 564 and TruffleHog flagged 643 — and 215 files, almost one in five, were flagged by neither. Most of the misses were passwords typed inside commands, after variables like PGPASSWORD= or sshpass, which fall outside the standard patterns scanners look for. Scanners are built to recognise known key formats; a plain password sitting next to a hostname does not match a format, so it sails through.

That gap matters because it is exactly the kind of secret this leak produces. A database password typed into a command line is not a well-formed API key, and it is the most common secret in Apiiro's haul. The lesson is not that scanners are useless — they caught roughly half to two-thirds of the exposed files, and GitHub's own secret scanning covers the well-known formats too — but that a clean scan result is not a clean bill of health. If you use Claude Code, the file itself needs a human read: open .claude/settings.local.json and look at the allow rules. Any command in there that contains a password or a token is a leak, whether or not a scanner flagged it.

This was reported more than a year ago

One of the more uncomfortable details in Apiiro's report is that this is not a new discovery. A GitHub issue opened on 11 August 2025 described approved commands with API keys and tokens being stored word for word in settings.local.json. An automated bot closed it as "not planned" on 3 January 2026, after 60 days without activity. Apiiro cites four related reports in total, and says all four were closed by the same bot, the most recent on 6 November — the day after its own research was published. As of 8 November, Anthropic had made no public statement about the findings, and its documentation still described the global-excludes approach as the protection for the file.

What Anthropic has said

That changed, in part, over the weekend. Boris Cherny, Anthropic's head of Claude Code, responded in a public Hacker News discussion on 7 November and posted about ten comments through the weekend. According to coverage of that discussion, the team is exploring safeguards for Claude Code, and plans to prototype checks that catch sensitive commands in auto mode, along with basic secret scanning. That is a response, not yet a fix: at the time of writing, no shipped change to the behaviour has been announced, and the documented behaviour is unchanged. So the checks below are yours to do, not the tool's — and the next "don't ask again" you click on a command carrying a secret will save that secret too, unless you change the habit first.

Apiiro also compared 16 AI coding agents based on their documentation, and reported that Claude Code was the only one confirmed to write the full approved command into a project-level file by default. That does not mean other agents are safe by definition — documentation is not behaviour, and every agent that stores approvals somewhere deserves the same check — but it does mean this particular leak has a specific cause, in a specific file, that you can search for right now.

Checklist: check and fix your repos now

Search GitHub for the files. In your organisation or account, search for .claude/settings.local.json and .claude/settings.json across every repository, including forks and archived ones. Apiiro's own first recommendation is exactly this search.
Check your local machines too. Look for .claude/settings.local.json in every project folder and read the allow rules inside it. Any command containing a password, a token or a connection string is a leak waiting for a commit, even if it has never been pushed.
Rotate first, clean second. Revoke or replace every credential the file ever held, starting with database passwords, cloud keys and production tokens. Only then remove the file — deleting first leaves a live secret sitting in git history.
Purge the history. Remove the file from git history with a tool like git filter-repo or BFG Repo-Cleaner. This rewrites history, so coordinate with your team, force-push, and ask collaborators to re-clone. Remember that forks keep their own copies, which you cannot purge — rotation is the only fix that covers them.
Add the file to the project's .gitignore. A committed .gitignore entry travels with the repository, unlike the machine-local global exclude Claude Code adds. Add .claude/settings.local.json and review anything else under .claude/ that could hold secrets, including saved agent transcripts.
Check the shared settings file too. .claude/settings.json is the file teams commit on purpose to share settings — and 298 of its 76,011 public copies held a secret. Audit it with the same care, and never put a credential in a file that is meant to be shared.
Run a scanner, then read the file yourself. Gitleaks, TruffleHog or GitHub secret scanning will catch a good share of exposed secrets, but 215 of them evaded both scanners Apiiro ran. A manual read of the allow rules is the part no scanner replaces.
Change the habit that creates the leak. Never type a secret into a command you approve. Put credentials in environment variables or a secret manager and let the command reference the variable, not the value. For a command that must carry a secret, choose the one-time "Yes", never "don't ask again".
Check your other agents as well. Claude Code is the only agent Apiiro confirmed doing this by default, but check wherever your own coding agent stores approvals before assuming you are unaffected.

What to do instead, going forward

The durable fix is not a single file deletion but a small set of habits that make this class of leak impossible. Keep secrets out of shell history and approval files entirely: environment variables, a secret manager, or short-lived tokens issued for one task are all better than a password typed into a command line. Use separate credentials for development and production, with the least privilege each job needs, so a leaked development key cannot open a production database. Rotate credentials on a schedule rather than waiting for a scare, and treat any credential that has ever appeared in a command, a log or a chat transcript as already exposed.

Teams should make the safe path the default one. Add .claude/ to the organisation's .gitignore templates, turn on GitHub push protection so known secret formats are blocked before they land, and add a pre-commit secret scan to the repositories where developers work. None of this is new advice, and none of it is difficult — but it only helps if it is in place before the next convenient click, not after it. The whole point of "don't ask again" is that you stop thinking about the command. The fix is to make sure there is nothing in the command worth stealing.

Bottom line

Claude Code's "don't ask again" button does exactly what it says: it remembers the command, word for word, including any secret typed into it, and stores it in a file inside your project. Apiiro found 2,539 real secrets in 1,994 public GitHub repositories that way, including database passwords, cloud keys and production tokens — some of them sitting in public for more than seven months, some of them surviving in git history and forks long after the file was deleted. Anthropic's team has said it is exploring safeguards, but no fix has shipped, so the check is yours to run: search your repositories for .claude/settings.local.json, rotate every credential it ever held before you delete it, purge the history, add the file to your project's .gitignore, and stop typing secrets into commands you approve. A coding assistant that remembers everything is only as safe as what you let it remember.