How 'Don't ask again' in Claude Code leaked secrets
Key takeaways
- Choosing 'Yes, and don't ask again' in Claude Code saves the approved command, including any password in it, as an allow rule in .claude/settings.local.json.
- Apiiro found 1,122 files with real secrets among 104,185 public copies of that file on GitHub, 1,379 distinct secrets in total, including 379 database passwords.
- The larger figure of 2,539 secrets also counts older file versions, a shared settings file and saved agent chat transcripts, so it covers a wider scope than the 1,379 distinct secrets in current files.
- Gitleaks and TruffleHog both missed 215 files with real secrets, so a clean scan doesn't prove the file is safe.
- We'd treat anything typed into an approved command as written to disk: read the file, and rotate any secret that was ever committed.
What does 'Yes, and don't ask again' do in Claude Code?
Claude Code asks before it runs most shell commands. One of the answers on that prompt reads 'Yes, and don't ask again'. Pick it, and Claude Code saves an allow rule to a file called .claude/settings.local.json in the project folder. From then on, the command runs without another prompt.
The allow rule stores the command as you approved it. According to the reporting on Apiiro's research, if that command contained a secret, the secret is saved along with it, in plain text. The file lives in a hidden .claude folder at the root of the repository.
Here is a hypothetical example to make the mechanics concrete. The command and password are invented for illustration and don't come from any real repository. Suppose you ask Claude Code to check a local Postgres database, and it proposes a psql command whose connection string ends in :hunter2@localhost. You click 'Yes, and don't ask again' so it stops asking. In this made-up case, the new allow rule would hold that connection string, password included, in a plain-text file inside your project.
We read this as a convenience setting doing what its label says. It remembers a command so it can skip the question next time, and what it remembers is the whole command text.
How does a Claude Code settings file end up on public GitHub?
The .claude folder sits inside the project, at the repository root, which is the same folder you commit and push. Once .claude/settings.local.json lands in a commit to a public repository, every allow rule in it, and any password inside those rules, can be read by anyone who opens the repo.
Plenty of copies have landed there. Apiiro's search of public GitHub found 104,185 copies of the settings file in 103,617 repositories. We haven't seen a source that settles whether the file is excluded from git by default, so we won't guess at why each copy was committed.
Apiiro did trace part of the route. In 539 of the 1,105 repositories it traced, a commit that listed Claude as co-author changed the file. That finding describes commit metadata. It doesn't show the agent deciding on its own to publish a secret: a person approved the original command, and a commit carrying Claude's co-author tag later touched the file. Our reading of the 539 repositories is that agent-written commits are one of the ways this file travels.
We'd argue location is what separates this file from a command sitting in your shell history. Shell history usually stays on your own machine. The Claude Code settings file lives in the repository, right next to the code you push.
How many secrets did Apiiro find in Claude Code settings files?
Apiiro examined 104,185 public copies of .claude/settings.local.json and found 1,122 files with real secrets, totalling 1,379 distinct secrets. Apiiro collected the data November 1–3, 2026.
Some coverage reports a bigger total of 2,539 secrets. That count covers more ground: older versions of the file, a shared settings file and saved agent chat transcripts. Counting those, the tally reached 2,539 secrets across 1,994 repositories. Both totals come from the same research. The 1,379 distinct secrets sit in current copies of the file, while the 2,539 secrets include everything in the wider sweep.
The secrets themselves were serious. Among them were 379 database passwords and 122 Supabase service-role keys. The research identified 63 affected organizations, mostly software companies.
Set against 104,185 copies, the 1,122 files with real secrets can look like a small share. We'd still weigh them by what each file held. In our view, a database password in a public file stays a live problem until its owner changes it.
Would Gitleaks or TruffleHog have caught the leaked secrets?
Some of them. Apiiro found 1,122 files with real secrets. Of those affected files, Gitleaks flagged 564 and TruffleHog flagged 643. Neither tool flagged 215 files.
That leaves 215 files missed by both Gitleaks and TruffleHog, each one a Claude Code settings file holding a real secret. A clean result from either scanner doesn't prove a settings file is free of passwords or keys.
We think of a secret scanner like a smoke detector: worth having, and no reason to stop checking the stove. Run Gitleaks or TruffleHog as one check among several, and still open the file yourself.
Was the Claude Code secrets problem known before Apiiro's research?
Yes. A GitHub issue reported plaintext credential storage in approved commands as early as August 2025. Apiiro collected the data for its own research November 1–3, 2026, well after that issue was filed.
Boris Cherny, head of Claude Code at Anthropic, said on Hacker News that Claude Code has historically not done secret scrubbing.
Malware has hunted for files like this before. The Shai-Hulud npm worm ran TruffleHog over victims' files in September 2025. TruffleHog also shows up in Apiiro's research, where it flagged 643 of the 1,122 affected files.
How to check your own repo for leaked Claude Code secrets
What follows is our opinion: general practice, with no guarantee that it catches everything. It starts from the mechanism in the reporting, where 'Yes, and don't ask again' stores the approved command, secrets included, in .claude/settings.local.json at the repository root.
We'd ask the same question of any tool that runs commands for you, including the automation a team builds for its own workflows: where does it remember what you approved, and who can read that place?
The short rule we take from Apiiro's 1,122 files with real secrets is that anything typed into an approved command should be treated as written to disk.
- Open .claude/settings.local.json in each project where you've used Claude Code and read every allow rule.
- Look for anything inside a command that resembles a password, API key, token or database connection string.
- If a secret in that file was ever committed, treat it as exposed and rotate it with the service that issued it. Deleting the file in a new commit leaves earlier versions in the history, and Apiiro's wider tally counted older file versions.
- Check the other places Apiiro's wider count covered: the shared settings file and saved agent chat transcripts.
- Pass secrets through environment variables so the command you approve only ever contains the variable's name.
- Run Gitleaks or TruffleHog as one check, and remember there were 215 files missed by both Gitleaks and TruffleHog.
Frequently asked questions
Does Claude Code save passwords in plain text?
It can. When you pick 'Yes, and don't ask again' for a shell command, Claude Code saves that command as an allow rule in .claude/settings.local.json in the project folder. The rule holds the command as approved, so a password typed into the command is stored in plain text, and the command then runs without another prompt. Reporting on Apiiro's research describes this behavior.
Where is the Claude Code settings.local.json file?
The file sits in a hidden folder named .claude at the root of the project or repository, at the path .claude/settings.local.json. Claude Code writes allow rules there when you choose 'Yes, and don't ask again'. Because the folder is inside the project, it can be committed and pushed along with your code, which is how Apiiro found 104,185 copies on public GitHub.
How many secrets were leaked through Claude Code settings files?
Apiiro found 1,122 files with real secrets among 104,185 public copies of .claude/settings.local.json, totalling 1,379 distinct secrets. Counting older file versions, a shared settings file and saved agent chat transcripts, the tally reached 2,539 secrets across 1,994 repositories. Among the exposed secrets were 379 database passwords and 122 Supabase service-role keys. Apiiro collected the data November 1–3, 2026.
Will a secret scanner catch a password in my Claude Code settings file?
Maybe, though Apiiro's numbers say not always. Among the 1,122 files with real secrets, Gitleaks flagged 564 and TruffleHog flagged 643, and there were 215 files missed by both Gitleaks and TruffleHog. We'd run a scanner as one check, then still open the file and read the allow rules yourself, because a clean scan result doesn't prove the file is free of secrets.
What should I do if my Claude Code settings file was committed?
In our view, treat any password, key or token in that file as exposed and rotate it with the service that issued it. Removing the file in a later commit leaves earlier versions in the history, and Apiiro's wider tally counted older file versions. Going forward, we'd pass secrets through environment variables so the approved command text never contains the value itself.