It starts with the most ordinary click in AI-assisted coding. Claude Code wants to run a command — say, a database query carrying a password — and asks permission. You pick "Yes, and don't ask again." The command runs. What you are not told, in that moment, is that the command has just been written down, word for word, secret included, in a file inside your project folder: .claude/settings.local.json. If that file ever gets committed and pushed, your credential is public — readable by anyone, and by every bot that scans GitHub for exactly this kind of mistake.
That is not a hypothetical. In research published on 5 November 2026, the software security company Apiiro reported finding 1,122 public copies of that file containing at least one real secret, holding 1,379 distinct credentials. Counting older versions in git history, the shared team settings file, and saved agent transcripts, the total rises to 2,539 distinct secrets across 1,994 public repositories, affecting 63 organisations — mostly software companies. Apiiro notified the organisations on 2–3 November; one confirmed to the researchers that its exposed key was live.
How a convenience feature becomes a leak
The mechanism is documented behaviour, not a hack and not a prompt injection. Anthropic's own Claude Code settings documentation confirms that standing approvals are saved as "allow" rules in the local settings file. The rule is the command string itself. If the command you approved contains psql --password=…, a token in a header, or a connection string, the secret is now sitting in plain text in your project directory, for as long as the file exists — and in git history, effectively forever.
Claude Code does try to keep the file out of version control, and the way it fails is the most instructive part of the story. According to Anthropic's documentation, the first time Claude Code writes the file inside a git repository, it adds **/.claude/settings.local.json to your global git excludes file — the ignore list that lives on your machine. It never adds the rule to the project's own .gitignore. So the protection does not travel with the project. Clone the repo on another machine, start the repo after the file exists, work on a machine where the global excludes are different, or force-add the file once — and nothing stands between the file and a push. Apiiro's data shows how often the agent itself closes the loop: in 539 of the 1,105 leaking repositories it traced, a commit co-authored by Claude had changed the settings file.
The result is not a fresh problem. Every file holding a secret was still sitting on its repository's default branch when Apiiro checked on 2 November, and in the median leaking repository the file had first been committed 217 days earlier. In 118 repositories, more than a year ago.
What is actually out there
The breakdown of the 1,379 secrets in current files is a tour of everything a developer's command line touches. Databases take the largest share: 379 database passwords, including 122 Supabase service-role keys — the kind that bypass row-level security entirely. There are 636 provider keys in recognisable formats (AWS, GitHub, npm, Stripe, Slack, OpenAI and others), 43 SSH credentials for public servers — some of them root logins — 42 GitHub, GitLab and npm tokens, and 23 AWS keys. The cases Apiiro highlights are the ones that should make any team lead sit up: a database vendor's own admin-level cloud key, a production Azure PostgreSQL password, a Square production payment token, and the owner password for a medical-records application's database.
Deleting the file does not fix any of this. Older versions in git history hold 734 additional secrets across 509 repositories — typically where someone removed the file but not its past — and forks keep their own copies. The shared team file, .claude/settings.json, which teams commit deliberately, held secrets in 298 of the 76,011 public copies Apiiro checked.
One more finding matters if you rely on scanners to catch this: standard tooling misses much of it. Running gitleaks and TruffleHog over every public copy, Apiiro found gitleaks flagged 564 of the 1,122 leaking files and TruffleHog flagged 643 — and 215 were flagged by neither. The gap is precisely the passwords typed inside commands (PGPASSWORD=…, sshpass -p, mysql -p…): scanners are built to recognise key formats, and a password in a command line is just a common word in a common command.
What the research does not prove
Precision matters here, because this story will be exaggerated in both directions. Apiiro did not test any of the credentials, so the research proves exposure, not compromise — we know one notified company's key was live, and we do not know how many others are. The classification of "real secret" was done with format and context filters plus an LLM reviewer working on masked candidates, and no third party has replicated the counts yet. Apiiro also sells security tooling for coding agents, which is worth knowing when weighing its framing — though the underlying mechanism is confirmed by Anthropic's own documentation, and Apiiro is careful to note the behaviour belongs to Claude Code the product, not the model: it reproduced it with Opus 5.5 and Fable 5.1, and of 16 coding agents whose documentation it compared, Claude Code was the only one confirmed to write the full approved command into a project file by default.
Two more facts keep the story honest. First, nobody broke into anything: every one of these secrets was committed by the repository's own workflow. Second, this was not a surprise sprung on Anthropic this week — users have reported plaintext credential storage in approved commands on Claude Code's public issue tracker since August 2025; Apiiro cites four such reports and says none received an Anthropic reply, with some closed automatically as inactive or duplicates. As of 8 November, three days after the research was published, there is no public Anthropic response and no change to the documentation on this point.
Check your own repositories today
If you use Claude Code — or anyone on your team does — treat this as a checklist, in this order:
- Search. Look across your GitHub organisation (and your own account) for
.claude/settings.local.jsonand.claude/settings.json— in current files and in git history. Every hit is a file anyone can read right now. - Rotate first. For every secret that has ever sat in one of those files, change it: passwords, tokens, keys, connection strings. Removing the file does not un-leak a credential that was public for months; rotation is the only step that actually ends the exposure.
- Then clean up. Untrack the local settings file and purge it from history, knowing forks may retain copies — another reason rotation comes first.
- Put the protection in the project. Add
.claude/settings.local.jsonto each repository's own.gitignore, so the rule travels with the code instead of living only in one developer's global config. - Keep secrets out of command lines. Approve commands that read credentials from environment variables or a secrets manager — not commands with the password typed into them. If a secret is never in the command, "don't ask again" has nothing dangerous to save.
- Turn on the nets. Enable GitHub secret scanning and push protection on your repositories. They will not catch everything — remember the 215 files both scanners missed — but they catch the recognisable keys before the push lands.
AI coding agents are changing where a project's sensitive data lives. The permission click feels like a conversation between you and your tools; in Claude Code's case, it has also been a quiet act of record-keeping, in a file one ordinary git add . away from the public internet. The fix is not to stop approving commands — it is to know what the approval writes down, and to make sure your passwords are never part of the sentence it saves.
Sources and classification
Classification: Confirmed News. The mechanism is confirmed by Anthropic's own Claude Code settings documentation; the exposure figures are Apiiro's published research findings (5 November 2026), attributed to Apiiro throughout, with the firm's methodology caveats stated in the article. Anthropic had not publicly responded as of the check date. Checked 8 November 2026.
- Apiiro research as reported by The Hacker News — "Claude Code's 'Don't Ask Again' File Exposes Passwords and Keys in 1,122 Public Copies on GitHub" (mechanism, scale, persistence, scanner results): https://thehackernews.com/2026/11/claude-codes-dont-ask-again-file.html
- Cybersecurity News — "'Yes, and Don't Ask Again' Option Can Leak Passwords and API Keys to GitHub" (secret categories, August 2025 tracker reports, affected organisations): https://cybersecuritynews.com/claude-codes-yes-and-dont-ask-again/
- AgentBeam analysis of the Apiiro research and Claude Code settings documentation (global-excludes safeguard, notification dates, untested-credentials caveat): https://agentbeam.com/blog/claude-code-dont-ask-again-settings-local-json-secrets-public-github
- iMasters — "Claude Code leaks passwords: how to fix it" (file-size risk pattern, remediation steps, shared settings.json figures): https://imasters.com/news/claude-code-leaks-passwords-in-1122-github-files