Claude Code "Don't Ask Again" Secrets Leak: Check, Rotate, Prevent

If you've used Claude Code's "Yes, and don't ask again" on a shell command with a password or token in it, that secret is now saved in plain text in .claude/settings.local.json. If that file was ever committed, treat the secret as leaked. Research published on November 5, 2026 found more than a thousand such files on public GitHub. Check whether the file is tracked, rotate anything it ever held, then make the repo ignore it for good.

This guide covers what happened, why the default protection fails, and the commands to check, clean up and prevent it, for solo developers and for teams.

What Apiiro found

Apiiro researchers Shmulik Cohen and Matan Giladi published the original report on November 5, 2026. The figures below come from coverage of that report by DEV Community and Cyber Press, which agree on the main numbers.

The secrets were mostly live infrastructure credentials, not demo keys. Within the local settings files, Cyber Press lists 379 database passwords, 122 Supabase service-role keys, 103 Supabase account tokens and 43 SSH credentials. The DEV write-up adds 42 GitHub, GitLab or npm tokens and 23 AWS keys. Examples include a production Azure PostgreSQL password and a production Square token.

There are two caveats on the numbers:

• Apiiro counted a value as a secret if it matched a known key format, or if a password sat next to a public server address and an AI reviewer agreed. It did not test whether the credentials still worked. One company it notified confirmed its key had been live.
• The shared .claude/settings.json was also affected: 298 of its 76,011 public copies held a secret, according to the DEV summary.

Apiiro compared the documentation of 16 coding agents. Claude Code was the only one confirmed to save the full approved command into a project file by default.

Why it happens, and why the gitignore doesn't save you

The approval is saved word for word

Claude Code's permissions docs say a "Yes, and don't ask again" approval for a Bash command lasts "permanently per repository and command." The settings docs say Claude Code saves it as an allow rule in .claude/settings.local.json. Sometimes the prompt offers a wildcard pattern, such as npm test *. Otherwise the rule is the literal command. So approving

PGPASSWORD=hunter2 psql -h db.example.com -U app

saves hunter2 into a JSON file in your project, and it stays there.

This isn't new. GitHub issue #5544, opened on August 11, 2025, reported that approved commands with API keys and tokens were "stored as is with plain text credentials." A bot closed it as "not planned" on January 3, 2026, after 60 days of inactivity. No maintainer resolved it.

The default ignore rule only covers your machine

According to the settings docs, the first time Claude Code writes the file in a repo that doesn't already ignore it, it adds **/.claude/settings.local.json to your global git excludes file. That's core.excludesFile, or ~/.config/git/ignore by default. That protects you on that machine, but it leaves several gaps:

1. It isn't committed. Teammates, CI runners and your next laptop don't get the rule.
2. Files you create by hand aren't covered. The docs say: "if you create it by hand, add it to .gitignore yourself."
3. Ignore rules don't untrack files. If the file was committed before the rule existed, git keeps tracking it.
4. Agents and scripts commit too. In 539 of the 1,105 traced repos, a commit co-authored by Claude changed the file.

npm packages can leak it too

This isn't only a git problem. In April 2026, Check Point found .claude/settings.local.json inside 428 of about 46,500 npm packages it monitored. Thirty-three of those files, across 30 packages, contained credentials, IT Brief reported. If you publish packages, check your tarballs as well as your repos.

How to check your repositories

Run these from the root of each repo you've used Claude Code in. Also check private repos: they get forked, mirrored, shared with contractors and connected to third-party apps.

1. Is the file tracked now, or was it ever?

git ls-files | grep -E '(^|/)\.claude/settings(\.local)?\.json$'
git log --all --oneline -- '**/.claude/settings.local.json' .claude/settings.local.json
git check-ignore -v .claude/settings.local.json

The first command shows tracked copies, including ones in subdirectories. The second shows whether any commit ever touched the file. The third shows which ignore rule applies, if any. If the third command prints a path to your global excludes file and nothing from the repo's .gitignore, you're protected only on that machine.

2. Look at what's inside

Open the file, or run /permissions in Claude Code to see every rule and the file it came from. Look under permissions.allow for anything that looks like a credential: PGPASSWORD=, a password attached directly to -p (as in mysql -phunter2), Authorization: Bearer, sshpass -p, --token, connection strings like postgres://user:pass@, and provider prefixes such as ghp_, sk-, AKIA or eyJ (JWTs, including Supabase keys).

3. Scan history with a scanner and with grep

Use both, because the scanners missed 215 files in Apiiro's dataset. Most misses were passwords after PGPASSWORD=, sshpass -p or mysql -p, which have no provider prefix to match.

gitleaks git -v                      # gitleaks 8.19+
trufflehog git file://.
git log --all -p -- .claude/ | grep -nE 'PGPASSWORD=|sshpass -p|mysql .*-p|://[^:/ ]+:[^@ ]+@|Bearer '

On Windows PowerShell, pipe git log --all -p -- .claude/ into Select-String -Pattern 'PGPASSWORD=|sshpass -p|Bearer ' instead.

Also check other agent folders. The DEV write-up recommends scanning .claude/, .cursor/, .gemini/ and .specstory/, because saved chat transcripts made up part of Apiiro's 2,539 total.

4. Check published packages

npm pack --dry-run

If .claude/ shows up in the file list, add it to .npmignore, or tighten the files field in package.json. Then review versions you've already published.

Cleanup: rotate first, then untrack

Do these in this order. Deleting the file first feels productive, but it doesn't help: the secret is still in history, in forks (Apiiro found 211 forks of 74 repos carrying the same secrets), and in every clone.

1. Rotate every credential the file has ever held. That includes database passwords, SSH passwords, API tokens and cloud keys. For Supabase service-role keys, rotate in the project dashboard, then update your deploy environment.

2. Check access logs for each rotated credential, going back to the first commit that contained it.

3. Stop tracking the file and ignore it in the repo:

   git rm --cached .claude/settings.local.json
   echo '**/.claude/settings.local.json' >> .gitignore
   git add .gitignore
   git commit -m "Stop tracking Claude Code local settings"
   

4. Clean the rules on your machine. Use /permissions or edit the file to delete any allow rule that contains a secret. Otherwise the plaintext is still on disk, and gets committed again the next time something stages it.

5. Optionally rewrite history with a tool like git filter-repo. This is cleanup only. It doesn't undo exposure that has already happened, and it forces every collaborator to re-clone.

Prevent it: change the habit and add a guardrail

Keep secrets out of approved commands

Put credentials in environment variables, loaded from a secrets manager or an ignored .env, so the approved command contains only the variable name:

PGPASSWORD="$DB_PASSWORD" psql -h "$DB_HOST" -U app

If you approve that, the saved rule contains $DB_PASSWORD, not the password. When the prompt offers a pattern (such as npm run test *), take it instead of approving one exact command. You get fewer rules and less chance of a literal value being saved.

Then stop Claude reading the files that hold the real values. The settings docs show deny rules for this:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

Put this in ~/.claude/settings.json to cover every project, or in the shared .claude/settings.json to cover the team. The docs say deny rules in the shared file apply immediately, without waiting for workspace trust. Note that this blocks Claude's file tools; it doesn't stop a shell command from running cat .env. Treat it as one layer, not a sandbox.

Add a guardrail that runs everywhere

A pre-commit hook that refuses the file outright is simpler and more reliable than hoping a scanner recognizes a password:

#!/bin/sh
# .git/hooks/pre-commit (or a shared pre-commit framework hook)
if git diff --cached --name-only | grep -qE '(^|/)\.claude/settings\.local\.json$'; then
  echo "Refusing to commit .claude/settings.local.json (may contain approved commands with secrets)."
  exit 1
fi

Run the same check in CI with git ls-files, because local hooks can be skipped. Failing the build on a tracked local settings file costs nothing and catches commits made by agents.

For teams and platform owners

• Add **/.claude/settings.local.json to your organization's .gitignore templates and repo scaffolding.
• Add rules to your secret scanner for passwords inside commands (PGPASSWORD=, sshpass -p, mysql -p, credentials in URLs), not just provider-prefixed keys.
• Review the shared .claude/settings.json in code review like any other config. The settings docs note that the VS Code extension's approval card lets you choose the shared file as the destination, which commits a rule for everyone.
• If you're comparing coding agents, ask each vendor where approvals are saved and whether they're redacted. Apiiro's 16-agent comparison suggests the answer varies. The AI coding assistants directory is a starting point for a shortlist.

What to watch and what to do this week

The fix that matters is on Anthropic's side: redacting or refusing secrets in saved rules, and writing the ignore rule into the repo's own .gitignore instead of a global file. As of November 8, 2026, none of the coverage includes a response from Anthropic or a changelog entry addressing it. Watch the Claude Code settings docs for a change to the ignore behavior.

Until then, the checklist is short:

1. Run the three git checks above in every repo where you've used Claude Code.
2. Rotate anything you find, starting with database and cloud credentials on publicly reachable hosts.
3. Commit a repo-level ignore rule and a pre-commit or CI check.
4. Move credentials out of command lines and into environment variables.

If you ship tools for developers, the same lesson applies to your product: a convenience feature that saves user input to disk needs a redaction step and a safe ignore default. More security write-ups for builders are on the LaunchBoosts blog.