MeanCEO: Tech Startups and Startup Ideas

Claude Code's "Don't Ask Again" Leaked 2,539 Secrets to Public GitHub Repos: What Anthropic Says, How to Check Your Repos and Which Keys to Rotate

Claude Code's don't ask again option leaked 2,539 secrets to GitHub
TL;DR: What is the Claude Code "don't ask again" leak?

When you approve a terminal command in Claude Code with "Yes, and don't ask again", it saves that exact command as a permission rule in .claude/settings.local.json. If the command had a password or API key in it, the secret goes into the file too. On 5 November 2026, security firm Apiiro said it had found 104,185 of these files in public GitHub repos, and 2,539 distinct secrets once git history and transcripts were counted, including 379 database passwords and 122 Supabase service-role keys. Anthropic says it is "looking into what we can do to prevent this", but no fix has shipped yet. Check your repos today, rotate anything you find, and keep secrets out of the commands you approve.
If you build with Claude Code, you have clicked this button. An agent asks to run a command, you're busy, and "Yes, and don't ask again" saves you the next ten prompts. It feels like the safe, boring choice.
It turns out that button has been quietly writing some founders' database passwords into a file that ends up on GitHub. Here's what Apiiro found, what Anthropic says, how to check your own repos in a few minutes, and what this means if you run a business in Europe and store customer data.
The Claude Code secrets leak in numbers: 104,185 settings.local.json files found in public GitHub repos; 1,122 of those files held a real secret; 2,539 distinct secrets counting git history and transcripts; 215 files that neither gitleaks nor TruffleHog flagged
One convenience button, thousands of exposed secrets.

What happened

On 5 November 2026, Apiiro researchers Shmulik Cohen and Matan Giladi published "Coding Agents Are Leaking Your Secrets to GitHub". The mechanism is simple. When you pick "Yes, and don't ask again" for a command, Claude Code "saves that exact command, secret included, to .claude/settings.local.json inside the project folder." So if you approved something like a database connection command with the password typed in, that password is now stored in plain text in your project.
That's by design. Claude Code's permissions documentation says this kind of approval lasts "permanently per repository and command". The file is meant to stay on your machine. The trouble starts when it gets committed and pushed.
Apiiro searched public GitHub code between 1 and 3 November. It reproduced the behaviour with Opus 5.5 and Fable 5.1 and calls it "Claude Code's own behavior, not the model's". Of 16 coding agents it compared, Claude Code was "the only one confirmed to write the full approved command to a project file by default".
What it found:
  • 104,185 copies of the file in 103,617 public repos.
  • 1,122 files (1.1%) held a real secret, with 1,379 distinct secrets between them.
  • 2,539 distinct secrets across 1,994 repos and 63 organisations once Apiiro added older versions of the file, the shared settings.json and transcripts.
  • 734 secrets in 509 repos exist only in older versions of the file. Deleting the file today doesn't remove them.
  • 211 forks of 74 repos carry the same secrets, out of the original owner's control.
  • In the median repo, the file was first committed 217 days before 2 November. These leaks are old, not new.
Bar chart of what leaked from the current settings.local.json files, by number of distinct secrets: 379 database passwords, 122 Supabase service-role keys, 103 Supabase account tokens, 43 SSH logins, 42 GitHub, GitLab and npm tokens, 23 AWS keys and 6 private keys
Database passwords lead, and Supabase keys are close behind.
Apiiro didn't test any credential, so "real secret" doesn't mean every one still works. But one organisation confirmed its key had been live. Apiiro says it warned the affected organisations on 2 and 3 November and told Anthropic before publishing.

Why secret scanners missed so many

Most leaks of API keys get caught by scanners that know what a key looks like. Passwords typed inside a command are harder. Apiiro ran two popular open-source scanners over the 1,122 files that held a secret:
Scanner (run without its verification step)Files flagged, of 1,122
gitleaks564
TruffleHog643
Flagged by neither215
Source: Apiiro, 5 November 2026.
This fits a wider trend. GitGuardian's State of Secrets Sprawl 2026 counted 28,649,024 new secrets in public GitHub commits in 2025, up 34% in a year, and found that Claude Code-assisted commits leaked secrets at a 3.2% rate against a 1.5% baseline for all public commits. AI agents write a lot of code fast, and secrets come along for the ride.

What Anthropic says

The story hit Hacker News on 7 November. That evening, Boris Cherny, who leads Claude Code, replied in the thread: "Historically Claude Code has not done secret scrubbing (there are many good tools for that), but we are looking into what we can do to prevent this."
He also said: "We automatically gitignore it when Claude creates the file, so in this case the files were manually created and checked in." And he added: "Permission rules are old hat. Everyone should be using auto mode instead," and "you should have secret scanning enabled." In a later comment he listed what the team is looking at: "making sure auto mode catches this, building in basic secret scanning, a few other ideas." When another reader said auto mode has the same problem, he answered: "Yeah good catch. Thinking through what we can do to improve this (ideas welcome)."
The "we gitignore it" point needs a footnote. Claude Code's documentation says that the first time it writes the file in a git repo, it "adds **/.claude/settings.local.json to your global git excludes file". That's a setting on your own computer. It doesn't go into the repo's .gitignore, so it doesn't protect a teammate, a second laptop, a CI job or a file you created yourself. Apiiro also points to four GitHub issues about the file going back to August 2025, including one from November 2025 titled "Claude Code no longer adds local settings file to .gitignore when it is created". All four are now closed. And Apiiro found that in 539 of 1,105 repos it traced, a commit co-authored by Claude had changed the file.
As of 9 November, no fix has shipped. The latest release, Claude Code 2.1.319 from 6 November, doesn't change how approved commands are stored, iTnews and the release notes confirm.
Timeline of the Claude Code secrets leak in November 2026: Apiiro scans public GitHub from 1 to 3 November; affected organisations are warned on 2 and 3 November; Apiiro publishes its report on 5 November; Claude Code 2.1.319 ships on 6 November with no fix for this; Claude Code's Boris Cherny replies on Hacker News on 7 November; Apiiro adds Anthropic's response on 8 November
One week from scan to Anthropic's first reply, and no fix yet.

Why Supabase founders should check first

Supabase is the database behind a big share of AI-built and no-code apps, so 122 service-role keys is the number that worries me most. Supabase's own documentation says the service_role key has the BYPASSRLS attribute, "so it skips every Row Level Security policy", and that "a leaked secret key exposes all of your project's data". With that key, someone can read and change every row in your database: users, emails, orders.
It's the second Supabase warning in a week. On 4 November, Cybernews reported research by the German firm Crissy Field: of 159,041 Lovable projects scanned, 34,545 ran on Supabase, and 24,664 of those returned database records with no login at all. Different cause, same lesson: if you build fast with AI tools, your database security is probably the weakest part of your stack. We follow both stories in our Supabase news for November 2026.
Supabase also says it is deprecating the old anon and service_role keys by the end of 2026, in favour of new publishable (sb_publishable_) and secret (sb_secret_) keys. If you have to rotate anyway, this is a good moment to move.

Which Claude Code settings file does what

FileApplies toShould it be in git?
~/.claude/settings.jsonYou, in every projectNo, it lives in your home folder
.claude/settings.jsonEveryone working on this projectYes, it is meant to be shared
.claude/settings.local.jsonYou, in this one project onlyNo, keep it out of the repo
Managed settingsEveryone in an organisation, set by an adminNo, deployed by IT
Source: Claude Code settings documentation, checked 9 November 2026. "Yes, and don't ask again" for a terminal command writes to the third file.

What this means for you

  1. Check your repos today. Search every repo you've pushed, public ones first, for .claude/settings.local.json, and look inside for passwords, connection strings and keys. Check older commits too, since 734 of the secrets Apiiro found only exist in the file's history.
  2. Rotate before you clean up. GitHub's guide to removing sensitive data from a repository says the first step is to revoke or rotate the secret. Deleting the file doesn't help if someone already copied it, and forks keep the old commits. For Supabase, follow its guide to rotating leaked API keys.
  3. Untrack the file and add it to the repo's own .gitignore. Then rewrite history with git-filter-repo as GitHub describes. Don't rely on the global excludes setting on one laptop.
  4. Keep secrets out of the commands you approve. Use environment variables, and add deny rules such as Read(./.env) so the agent can't read your secrets files. Run /permissions to see every rule Claude Code has saved and where it came from, and delete the ones that hold a secret.
  5. Turn on secret scanning. GitHub runs it for free on public repos, but as the table above shows, scanners miss passwords typed into commands, so they're a safety net, not a fix.
  6. If customer data was exposed, the GDPR clock may be running. Article 33 of the GDPR (Adopted) says you must tell your data protection authority "not later than 72 hours after having become aware of it", unless the breach is unlikely to put people at risk. Our GDPR compliance checklist for early-stage startups covers what to have ready.
Fix the Claude Code secrets leak in five steps: 1, search your repos for .claude/settings.local.json; 2, rotate first and treat any password or key in the file as stolen; 3, untrack the file and add it to the repo's own .gitignore; 4, clean the git history with git-filter-repo; 5, stop the next one with environment variables, deny rules for .env files and secret scanning
Rotate first. Cleaning git history without rotating keys doesn't make you safe.
This is the third time in a few weeks that a coding tool's own plumbing became the risk. In October, attackers took saved API keys in the OpenCode breach, and on 29 October a tampered Claude Code extension on Cursor's marketplace planted an attacker's SSH key on developer machines. Before that, the Railway and LiteLLM incidents hit the platforms founders use to deploy AI apps. We collect these in our cybersecurity news for November 2026 and our Claude Code news for November 2026.
My take: I love tools that let one founder do the work of a team, and Claude Code is one of them. But every click that saves you a prompt is a decision about your security, whether you notice it or not. "Don't ask again" sounds harmless. Here it meant "remember my database password and keep it in my project". Anthropic will probably fix this, and Boris Cherny's quick reply is a good sign. Don't wait for it. Spend ten minutes today checking your repos, rotate what you find, and get into the habit of keeping secrets in environment variables, never in a command you approve. The founders who get hurt by this won't be the ones who were hacked by a genius. They'll be the ones whose password sat in a public file for 217 days.
Are you getting customers from AI search yet?

More and more traffic is coming from Perplexity, ChatGPT, Grok and other AI tools.

👉 Rank on ChatGPT

FAQ: the Claude Code "don't ask again" secrets leak

What does "Yes, and don't ask again" do in Claude Code?

It saves the command you approved as a permanent allow rule for that repository, in .claude/settings.local.json. The rule stores the full command, so any password or API key typed into it is saved too, in plain text.

How many secrets leaked to GitHub?

Apiiro found 104,185 copies of the file in public GitHub repos. 1,122 held a real secret, with 1,379 distinct secrets, and the total rises to 2,539 distinct secrets across 1,994 repos once git history and transcripts are counted. Apiiro didn't test whether they still work.

Has Anthropic fixed the Claude Code leak?

Not yet. Boris Cherny of the Claude Code team said on Hacker News on 7 November that the team is "looking into what we can do to prevent this", including basic secret scanning. The latest release as of 9 November, 2.1.319, doesn't change how approved commands are stored.

Isn't settings.local.json gitignored automatically?

Partly. Claude Code adds the file to your global git excludes the first time it writes it in a git repo. That setting lives on your computer, not in the repo, so a file you created yourself, a new laptop or a teammate's machine isn't covered. Add it to the repo's own .gitignore.

What should I do if my Supabase key was in the file?

Treat it as stolen. Create a new secret key, replace the old one everywhere, then delete or deactivate the old key, as Supabase's rotation guide describes. A service_role key bypasses Row Level Security, so it gives full access to your project's data.

Do I have to report a leaked database password under the GDPR?

Only if personal data was breached. If someone may have accessed customer data, Article 33 of the GDPR requires you to notify your data protection authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people. Document what happened either way. Our news on the tampered Claude Code extension has more on handling an incident.

About the Author

Violetta Bonenkamp, also known as MeanCEO, is an experienced startup founder with an impressive educational background including an MBA and four other higher education degrees. She has over 20 years of work experience across multiple countries, including 5 years as a solopreneur and serial entrepreneur. Throughout her startup experience she has applied for multiple startup grants at the EU level, in the Netherlands and Malta, and her startups received quite a few of those. She’s been living, studying and working in many countries around the globe and her extensive multicultural experience has influenced her immensely.
News and Trends
Made on
Tilda