Claude Code's 'Don't Ask Again' Secrets Leak (November 2026): How to Check Your Repos and Fix settings.local.json

If you use Claude Code and have ever clicked "Yes, and don't ask again" on a command that contained a password, a token or a connection string, that secret is probably sitting in plain text in .claude/settings.local.json inside your project. Apiiro scanned public GitHub in early November 2026 and found 1,122 public copies of that file holding at least one secret: 1,379 distinct credentials, more than a third of them database passwords. The fix is short. Check every repo for the file (including git history), rotate anything you find before you delete it, untrack the file, and stop putting secrets inside commands your agent runs.

I'm Kunal Vohra, a security researcher and cybersecurity advisor, and I build AI products myself. This post is the practical version: who is exposed, how it happens, the exact commands to check, and what I'd change on a startup team this week.

Who should care

You should spend ten minutes on this if any of these is true:

Anyone on your team uses Claude Code on a repository that is public, or that might become public (open-sourcing, a fork, a template, a client handover).
Your developers run database, SSH, cloud or deploy commands through the agent with credentials typed inline, such as psql "postgres://user:password@host/db", PGPASSWORD=... psql, sshpass, or curl -H "Authorization: Bearer ...".
You use Supabase, a managed Postgres or MySQL, or any database with a public endpoint. Database passwords next to a public host were the largest category Apiiro reported.
You have private repos shared with contractors or agencies. Private is not the same as safe; anyone with read access can read the file.
You run security scanning and assume it would catch this. In Apiiro's results, neither of the two most common open-source scanners flagged 215 of the 1,122 files.

If nobody on your team uses Claude Code, the lesson still applies to every coding agent that remembers approvals, so read the guardrails section anyway.

What actually happened

Apiiro, an application security company, published research in the first week of November 2026 (reports date it 5 or 6 November; one report says the data was collected 1 to 3 November). The Hacker News, GBHackers and Cyber Security News all covered it on 7 November. I could not open Apiiro's own post, so the numbers below are as those outlets report them, and they agree with each other.

The mechanism. When Claude Code asks permission to run a command and you pick "Yes, and don't ask again", it saves a permission rule so it won't ask next time. Anthropic's documentation says that rule goes into .claude/settings.local.json at the root of the git repository. Sometimes the saved rule is a prefix pattern (the docs show an example like npm test *); sometimes it is the exact command. If the exact command contained a password or a token, the secret is now in the rule, in plain text, in a file inside your project folder.

Why it reaches GitHub. Anthropic's docs say Claude Code keeps the file out of git when it creates it, by adding **/.claude/settings.local.json to your global git excludes file, not to the project's own .gitignore. That protects the one machine where the global excludes file exists. It doesn't travel with the repository. A teammate whose global config is different, a fresh laptop, a container, a git add -f, or a file created by hand all bypass it. Apiiro also reported that in 539 of the 1,105 repositories it traced, the commit that changed the file was co-authored by Claude, so in about half the cases the agent itself was part of the commit.

The numbers, as reported:

104,185 public copies of settings.local.json across 103,617 repositories.
About 1.1% of them, 1,122 files, held at least one secret: 1,379 distinct secrets.
379 database passwords, 122 Supabase service-role keys, 43 SSH logins, 42 GitHub, GitLab or npm tokens, 23 AWS keys.
734 more secrets sat only in older versions of the file in git history, across 509 repositories.
211 forks of 74 repositories carried the same secrets.
The shared .claude/settings.json file had secrets too, in 298 of 76,011 copies.
Counting history, forks, shared settings and agent chat logs: 2,539 secrets across 1,994 repositories, from 63 organizations, mostly software companies.
Gitleaks flagged 564 of the 1,122 files and TruffleHog 643 (both run without their verification step); neither flagged 215.

Apiiro says it did not test whether the credentials still work, though the reports say one notified company confirmed its exposed key was live. When Apiiro last checked, every file with a secret was still on the default branch, half of them for at least 217 days.

Anthropic's response. As of the 7 November coverage, none. The Hacker News reports that a GitHub issue raising plaintext storage in this file was opened in August 2025 and closed by a bot as "not planned", and that four related reports were also closed automatically. Apiiro compared the documentation of 16 coding agents and says Claude Code is the only one confirmed to save the full approved command in a project file by default. I'd treat that as Apiiro's claim, not a settled ranking; the general point holds for every agent that remembers approvals.

The line I'd want every engineering lead to remember: an agent's memory of what you approved is a file, and files get committed.

How to check your repos in ten minutes

Run these from the root of each repository. Nothing here changes anything; it only looks.

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

# currently tracked agent settings files
git ls-files | grep -E '(^|/)\.claude/settings(\.local)?\.json$'

# ever committed, on any branch
git log --all --oneline -- '.claude/settings.local.json' '**/.claude/settings.local.json'

If both come back empty, the file has never been committed in this repo. Still do step 3, because the file may exist on disk.

2. Search your whole GitHub organization at once. In GitHub code search, try path:.claude/settings.local.json org:your-org, and the same for path:.claude/settings.json. Code search covers default branches, so it won't see history; step 1 covers that per repo.

3. Look for secrets in the local file, tracked or not.

grep -nE '://[^/ "]+:[^@ "]+@|PGPASSWORD=|MYSQL_PWD=|sshpass|AKIA[0-9A-Z]{16}|gh[pousr]_[A-Za-z0-9]{20,}|npm_[A-Za-z0-9]{20,}|sk_live_|Bearer [A-Za-z0-9._-]{20,}|service_role' \
  .claude/settings.local.json .claude/settings.json 2>/dev/null

This is a rough net, not a scanner. It catches the common shapes (connection strings with a password, inline password variables, AWS, GitHub, npm and Stripe keys, bearer tokens, Supabase service-role mentions). Read the file by eye as well; it is usually short.

4. Check where your global excludes actually point.

git config --global core.excludesFile
cat "$(git config --global core.excludesFile 2>/dev/null || echo ~/.config/git/ignore)" 2>/dev/null | grep -n claude

If the second command prints nothing, the automatic protection isn't in place on this machine.

How to fix it, in the right order

Step 1: Rotate first. If a secret was ever pushed anywhere others can read, assume it is known. Change the database password, revoke and reissue the token, deactivate the AWS key, regenerate the Supabase service-role key. Do this before you clean up the repo, because deleting the file does nothing for copies in forks, clones and history. Then check the provider's logs (database connection logs, CloudTrail, GitHub audit log, Supabase logs) for use you don't recognise since the commit date.

Step 2: Untrack the file and ignore it in the project.

git rm --cached .claude/settings.local.json
printf '\n# Claude Code personal settings (may contain approved commands)\n.claude/settings.local.json\n' >> .gitignore
git add .gitignore
git commit -m "Stop tracking Claude Code local settings"

Putting it in the project's own .gitignore means the protection travels with the repo to every laptop, container and CI runner.

Step 3: Decide about history. Rewriting history with git filter-repo removes the file from future clones, but forks and existing clones keep it, which is why rotation comes first. For a public repo with a real secret in history, I'd rotate, then rewrite if the repo is small and the team can re-clone; for everything else, rotation is the fix and a rewrite is housekeeping.

Step 4: Clean the rules themselves. Open .claude/settings.local.json and delete any allow rule containing a secret. Approve patterns instead of exact commands, and keep credentials in the environment:

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(psql \"$DATABASE_URL\" *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

The rule now contains $DATABASE_URL, a reference, not the password. The deny rules follow Anthropic's own settings example and stop the agent reading your .env files by name. Note the docs say deny rules on reads don't cover a shell command that reads a file without naming it, so they reduce exposure; they don't make secrets invisible.

Step 5: Block the file at commit time. Scanners missed about one in five affected files, so don't rely on pattern matching. Block the path itself with a pre-commit hook:

#!/bin/sh
# .git/hooks/pre-commit (or wire it into your pre-commit framework)
if git diff --cached --name-only | grep -qE '(^|/)\.claude/settings\.local\.json$'; then
  echo "Refusing to commit .claude/settings.local.json (personal agent approvals)."
  exit 1
fi

Then turn on secret scanning with push protection on your GitHub organization, and make sure your scanner's configuration doesn't exclude dot-folders like .claude/.

What changes beyond this one file

This incident is small in code and large in pattern. Coding agents now write files into your repository that nobody reviews: approval lists, settings, memory files, chat transcripts, plans. Apiiro counted chat logs among the leak sources too. Each of those is a new place a secret can land, and none of them existed in your threat model two years ago.

Three structural points matter more than the one-line fix:

Secrets should never be in a command in the first place. If a developer has to paste a production password into a terminal for the agent to run, the problem is the workflow. Use .env files that are ignored, a secrets manager, short-lived credentials, or a local proxy that holds the key.
More than a third of the leaked secrets opened a database directly. That means many of those databases accept connections from the public internet with a password alone. A leaked password for a database behind a private network or an IP allowlist is an incident; for a publicly reachable one, it's a breach.
Agents should run with development credentials. An agent on a laptop has no business holding production write access. Give it a seeded dev database and a scoped token, so that whatever it remembers or leaks is cheap to rotate.

I covered the permission model I use for agents in AI agent security for startups, and the wider basics in the startup security checklist. This week has been heavy on identity and AI-driven attacks too; if your team runs Microsoft 365 or Google Workspace, the device code phishing guide is the other thing I'd read.

What I'd do as a CTO this week

If I were running engineering at a ten to fifty person startup, this is the order:

Today: send one message to the team asking everyone who uses Claude Code (or any agent) to run the four checks above on every repo they touch, and to report anything found without fear of blame. Speed beats shame.
Today: rotate every secret that turns up, then check provider logs for use since the commit date.
This week: add .claude/settings.local.json to the .gitignore of every repo and to your repo template, add the pre-commit hook, and enable organization-wide secret scanning with push protection.
This week: move database access for agents to dev credentials, and put production databases behind a private network or an allowlist if they aren't already.
This month: write a one-page "agents in our repos" policy: which agents are allowed, what they may run without asking, where credentials live, and which agent-written files are never committed. If you have no senior engineer to own that, it is exactly the kind of decision a technical advisor or fractional CTO should make once and enforce.

None of this means you should stop using coding agents. They are among the best productivity tools a small team has. It means you treat their memory like any other config that can hold a secret.

Frequently asked questions

What is .claude/settings.local.json? It is Claude Code's personal, per-project settings file. When you choose "Yes, and don't ask again" on a permission prompt, Claude Code saves the approval there as a permission rule. Anthropic's docs describe it as your settings for one project, not meant to be shared.

Is .claude/settings.local.json ignored by git automatically? Partly. Anthropic's docs say Claude Code adds it to your global git excludes file when it creates the file, not to the project's .gitignore. That works only on machines where that global file exists and is used, so add the path to the project's .gitignore yourself.

Did Anthropic fix the Claude Code "don't ask again" leak? As of the 7 November 2026 coverage, there was no Anthropic statement or fix tied to Apiiro's research, and earlier GitHub reports about plaintext storage had been closed automatically. Check Claude Code's changelog for later changes.

How do I know if my secrets were exposed? Run git log --all -- .claude/settings.local.json in each repo, search your GitHub organization for the path, and read the file on disk. If a secret was ever pushed somewhere others could read, rotate it and check the provider's logs.

Will Gitleaks or TruffleHog catch this? Often, not always. In Apiiro's results, Gitleaks flagged 564 of the 1,122 affected files and TruffleHog 643, and neither caught 215. Block the file path with a pre-commit hook rather than relying on pattern matching alone.

Does this affect other AI coding agents? Apiiro says Claude Code is the only one of 16 agents it compared that saves the full approved command in a project file by default. Any agent that stores approvals, memories or transcripts inside the repo can leak the same way, so apply the same rule: agent-written files are untracked unless you decide otherwise.

If you want a second pair of eyes on how your team uses coding agents, from credentials to repo hygiene, book a 30-minute call and we'll go through it together.

Sources

Claude Code's 'Don't Ask Again' File Exposes Passwords and Keys in 1,122 Public Copies on GitHub (The Hacker News)
Claude Code's 'Don't Ask Again' Feature Exposes 2,539 Secrets Across 1,994 GitHub Repositories (GBHackers)
Claude Code's "Yes, and Don't Ask Again" Option Can Leak Passwords and API Keys to GitHub (Cyber Security News)
Original research on coding agents leaking secrets via "don't ask again" (Apiiro)
Claude Code settings (Anthropic documentation)
Claude Code permissions (Anthropic documentation)
anthropics/claude-code issue #5544 (GitHub)

Written By

Kunal Vohra

Technical Co-Founder & Fractional CTO

I've co-founded 6+ startups across India, the UAE, and the US, spanning AI, Web3, fintech, and cybersecurity. I write about the technical and strategic decisions that determine whether a startup thrives or stalls.

Work With Me Medium →LinkedIn →

Comments

Loading comments…