Claude Code’s “don’t ask again” left secrets in 1,122 public GitHub files. What to check

What Apiiro found

On November 5, 2026, the security company Apiiro published a count of the secrets in .claude/settings.local.json, the settings file Claude Code saves your standing approvals to. Searching public GitHub from November 1 to 3, it found 104,185 copies of the file in 103,617 repositories. 1,122 of them, about 1.1%, held what Apiiro calls a real secret: “a key in a known provider format, or a password or token next to a public host.”

Those 1,122 files hold 1,379 distinct secrets: 636 provider keys and 743 passwords or tokens. More than a third open a database directly, with 379 database passwords and 122 Supabase service-role keys. The rest include 103 Supabase account tokens, 43 SSH logins, 42 GitHub, GitLab and npm tokens, 23 AWS keys and 6 private keys.

Adding the file’s git history, the shared .claude/settings.json that teams commit on purpose, and agent chat transcripts saved in repositories, Apiiro’s total is 2,539 distinct secrets in 1,994 repositories. Among the owners are 63 organizations, “mostly software companies of all sizes,” including a database vendor whose own cloud key had manage access. Apiiro reported each organization’s case to its owner on November 2 and 3, and one “confirmed its key had been live.”

On November 7 the report reached the front page of Hacker News, where a member of the Claude Code team answered it.

How a password gets into the file

Claude Code asks before it runs most shell commands, and one of the answers is “Yes, and don’t ask again.” Anthropic’s permissions docs say that for a Bash command the approval lasts “permanently per repository and command,” and that Claude Code saves “the rule to .claude/settings.local.json at the root of the git repository.”

The rule is made from the command itself, or from its first words followed by *. Ask Claude why sign-in fails on staging, and the command it proposes may carry the database password from your config file, because the command can’t work without it. Approve it for good, and the password is saved in the file’s allow list, in plain JSON. Apiiro’s examples are passwords typed after PGPASSWORD=, sshpass -p or mysql -p, and bearer headers in curl calls. It calls this “Claude Code’s own behavior, not the model’s,” and reproduced it with Opus 5.5 and Fable 5.1.

Of the 16 coding agents whose approval storage Apiiro compared from their documentation, “Claude Code is the only one confirmed to write the full approved command to a project file by default.”

Why the file ends up on GitHub

Claude Code does try to keep the file out of git. Its settings docs say that the first time it writes the file in a repository that doesn’t already ignore it, “it adds **/.claude/settings.local.json to your global git excludes file.” That file belongs to your computer, not to the project. Apiiro lists what it doesn’t cover: “a folder that becomes a repo later, a clone on another machine, or a file someone already committed.”

Often, Apiiro found, Claude commits the file itself. In 539 of the 1,105 repositories with a real secret that it traced, “a commit co-authored by Claude changed the file,” naming models from Sonnet 4.5 to Opus 5.5.

Once committed, the secrets stay and spread. Apiiro’s counts:

What Apiiro found	Count
Public copies of .claude/settings.local.json	104,185
Copies with a real secret	1,122
Of those, flagged by gitleaks / TruffleHog / neither	564 / 643 / 215
Median days since the file was first committed	217
Repositories where it was committed over a year ago	118
Forks carrying the same secrets	211, of 74 repositories
Secrets only in the file’s history, in no current copy	734, in 509 repositories
Shared .claude/settings.json files with a secret	298, of 76,011

gitleaks and TruffleHog miss passwords inside commands, Apiiro says, because they look for key formats. GitHub’s secret scanning “runs automatically for free” on public repositories, and push protection for users is “enabled by default” and “stops you from pushing secrets to public repositories on GitHub.” Push protection for passwords and other unstructured secrets, which GitHub finds “using AI based on surrounding code context,” is a separate, billed feature that has to be turned on.

What Anthropic has said

Date	What happened
August 11, 2025	A user reports that approved commands “containing credentials are stored as is with plain text credentials in settings.local.json” (#5544)
January 3, 2026	A bot closes #5544 as not planned, after a month marked for automatic closing
September 1, 2026	Another user reports the VS Code extension writing “always allow” grants to the tracked .claude/settings.json (#91270)
November 5	Apiiro publishes; a bot closes #91270 as not planned the same day
November 7	The Claude Code team replies on Hacker News

Apiiro counts four such issues since August 2025: “None got a reply from Anthropic.” On November 7, Boris from the Claude Code team wrote: “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 said the file “is meant to stay local. This is not a file you should check into source control,” and that “We automatically gitignore it when Claude creates the file, so in this case the files were manually created and checked in.” Apiiro’s findings on the global ignore file and on Claude’s own commits describe other ways in.

He added that “Permission rules are old hat. Everyone should be using auto mode instead,” and that “Regardless of what agent you use, you should have secret scanning enabled.” Anthropic hasn’t published a statement or a fix. Claude Code 2.1.319, released November 6, doesn’t mention one in its changelog.

How to check

1. On GitHub. Search your organization’s code for org:YOUR-ORG path:.claude/settings.local.json, then for org:YOUR-ORG path:.claude/settings.json; GitHub’s code search takes both qualifiers. Each hit in a public repository is a file anyone can read.
2. In each repository’s history. Run git log --all --oneline -- .claude/settings.local.json. Any output means the file was committed at some point, so every fork and clone made since has that version, even if it’s gone today. git ls-files .claude shows whether it’s tracked now.
3. Whether git ignores it. Run git check-ignore -v .claude/settings.local.json in the repository. It names the ignore file that covers it, and prints nothing if none does or the file is already tracked.
4. On your computer. List every copy with find ~ -path '*/.claude/settings.local.json' 2>/dev/null, open each, and read its allow list. Each entry is a command you approved, with whatever was typed into it: look for passwords, tokens, keys and connection strings. In Claude Code, /permissions lists every rule and the settings file it comes from.

A file that never left your computer isn’t safe either. Apiiro points out that the Shai-Hulud npm worm of 2025 ran TruffleHog over its victims’ files, and TruffleHog flags 643 of the 1,122.

If you find a secret

Apiiro’s order is “rotate first, clean up second.” Replace every credential the file has ever held, at the service that issued it, because deleting the file doesn’t reach git history, forks or clones. Then:

1. Remove each rule that contains a secret, in /permissions or in the file.
2. If the file is tracked, run git rm --cached .claude/settings.local.json, add .claude/settings.local.json to the repository’s own .gitignore, and commit both.
3. Check .claude/settings.json the same way, and anything else an agent writes that you commit. Apiiro also found secrets in saved agent chat transcripts, such as .specstory, aider and Cursor exports (120 files in 87 repositories), in agent memory files (9 repositories), in handoff and deploy notes (33 files), and in VS Code Copilot auto-approve settings (9 repositories).

How to keep secrets out of your approvals

• Don’t type secrets into commands. Keep them in environment variables or a secrets manager and refer to them by name, so a saved rule holds $DB_URL rather than the password. Apiiro’s advice: “Reference them as $VAR from whatever secrets manager you use.”
• Read the rule before you save it. The prompt names it, as in “Yes, and don’t ask again for: npm test *”, and Anthropic’s docs say “a rule you save from a prompt covers only what its option named.” If the rule has a secret in it, choose plain “Yes.” Prefer patterns such as Bash(npm run *) to one exact command.
• Ignore the file in every repository. Add .claude/settings.local.json to each project’s .gitignore, and to your organization’s templates, so the rule travels with every clone.
• Consider auto mode. It’s what Boris recommends: a classifier reviews actions instead of prompting you, so there’s no “don’t ask again” to choose for the commands it allows. Anthropic’s docs say it “reduces permission prompts but does not guarantee safety,” and it doesn’t take the secret out of the command.

Running Claude Code in Enjoy doesn’t change the file Claude Code keeps its approvals in. What Enjoy adds is project secrets, which keep the value out of the command: an agent asks Enjoy to run a command with a secret by its name, Enjoy sets the secret as an environment variable, and the agent sees the name, such as [GITHUB_TOKEN], in the output in place of the value. In modes that ask first, Enjoy’s card offers Allow once or Decline. Project secrets are in the desktop app only.

What hasn’t been said

• Whether Claude Code will change. Boris said the team is “looking into what we can do to prevent this,” without saying what or when.
• How many of the secrets still work. Apiiro didn’t use or test any. “Real secret” means a credential in a provider’s format or one next to a public host, “not one known to be valid.” One organization confirmed its key had been live.
• Whether anyone has used them. We found no report of one being abused.
• Independent review. The counts are Apiiro’s, a security company, and its final classification used “an independent LLM reviewer working from a written rubric.” We found no independent recount.