Introduction
I clicked "Yes, and don't ask again" in Claude Code last week. It felt like the most boring click of my day. Claude had asked permission to run a database check, the command looked fine, and I didn't want to be asked again every time I ran it. One click, and the prompt went away forever.
Then I read Apiiro's research, published on November 5, 2026, and that boring click suddenly looked very different. When you choose "don't ask again," Claude Code doesn't save a tidy pattern like "allow database commands." It saves the entire command — password and API key included — into a file called .claude/settings.local.json inside your project folder. If that file ever gets committed, your secret goes to GitHub with it, in plain text, for anyone to read.
Apiiro's researchers, Shmulik Cohen and Matan Giladi, searched public GitHub between November 1 and 3 and found 104,185 public copies of that file. In 1,122 of them — about 1.1% — there was a real secret. Not a placeholder: real database passwords, production cloud keys, and API tokens. One was a database vendor's own admin-level cloud key. Another was the owner password for a medical-records database.
Here's what happened, what the numbers do and don't prove, and the check you can run tonight in about fifteen minutes.
How one click saves your password
Let me walk through the exact sequence, because the scary part is how ordinary it is.
You're working in Claude Code, Anthropic's terminal-based AI coding agent. You ask it to check a database or call an API. Claude drafts the shell command, and because it touches something sensitive, it asks for permission first — exactly the behaviour you want from an agent that runs things on your machine.
You look at the command. It includes a password or a token, because that's how the command works. You click "Yes, and don't ask again" — you trust this command and don't want the same interruption tomorrow.
Here's the part nobody tells you: Claude Code's permissions documentation confirms that choosing "don't ask again" stores the approved command as an "allow" rule in
.claude/settings.local.json. Apiiro's key finding is that the saved rule is the complete command string itself, secret included. There is no redaction step. The file now holds your password in plain text, sitting in your project directory next to your source code.The file is supposed to stay on your machine. Claude Code's settings documentation describes a safeguard: the first time it writes the file inside a git repository that doesn't already ignore it, it adds
/.claude/settings.local.json to your global git excludes file (core.excludesFile, usually ~/.config/git/ignore). That covers the common case — but not the gaps. The folder becomes a repository later, and you only run git init after Claude wrote the file. You clone onto another machine, and the global excludes file lives on your first computer, not in the repository. The file was already committed, so a new ignore rule does nothing. And the rule never goes into the project's own .gitignore, so teammates don't inherit the protection.Here's the detail that stopped me cold: in 539 of the 1,105 leaking repositories Apiiro traced, a commit co-authored by Claude itself had changed the settings file.
What the numbers actually say
Headlines lose the caveats, so let me be precise — the honest version is bad enough without exaggeration.
Between November 1 and 3, Apiiro used GitHub's code search to collect 104,185 public copies of
.claude/settings.local.json across 103,617 repositories. Of those, 1,122 files — about 1.1% — contained a real secret. Apiiro's definition of "real secret" is strict: a credential in a known provider format, or a password or token sitting next to a host reachable from the public internet. That gave 1,379 distinct secret values: 636 provider keys and 743 passwords or tokens for internet-reachable hosts. Counting old versions of the file in git history, the shared .claude/settings.json teams commit on purpose, and saved agent chat transcripts, the wider total reaches 2,539 distinct secrets across 1,994 repositories.Sixty-three organisations are affected, mostly software companies. The exposed credentials include a database vendor's admin-level cloud key, a production Azure Postgres password, a Square production token, and the owner password of a medical-records application's database. Apiiro notified affected organisations on November 2 and 3, and one confirmed its exposed key was live.
Now the caveats. Apiiro did not test the credentials, so the research proves exposure risk, not demonstrated compromise — one key was confirmed live by its owner, but not how many of the other 1,378 still work. The history count is a minimum resting partly on an LLM reviewer's judgement, no third party has repeated the counts, and the snapshot covers public GitHub only, so the real total is almost certainly larger. Apiiro also sells security products for coding agents — a commercial stake worth knowing, though the files are public and anyone can verify them.
One more number: in the median leaking repository, the file had first been committed 217 days before Apiiro's November 2 snapshot. These secrets sat in public, searchable, for months — every one of the 1,122 files on its repository's default branch.
Your secret scanner probably won't catch this
If your response is "we run secret scanning" — Apiiro checked that too, and the results are uncomfortable.
The researchers ran gitleaks and TruffleHog, two of the most popular open-source secret scanners, over all 104,185 files. Of the 1,122 files holding a real secret, gitleaks flagged 564 and TruffleHog flagged 643. Two hundred and fifteen files — roughly one in five — were flagged by neither.
Why do the scanners miss them? Because most of these secrets aren't keys in a recognisable format. They're passwords typed inside a command, sitting next to a hostname. A scanner looking for
sk-live-... or an AWS key pattern walks straight past a database URL with a password embedded in it — and the Shai-Hulud npm worm, which ran TruffleHog over its victims' files in bulk, would have caught only 643 of these 1,122 files.There's a second file to worry about. Claude Code has a shared settings file,
.claude/settings.json, which teams commit deliberately so everyone shares the same permissions. A separate open bug report on Claude Code's GitHub tracker says approvals are sometimes written to that shared file instead of the local one, and Apiiro found secrets in 298 of 76,011 public copies of it. The file is committed by design, so every secret in it was shared on purpose by someone who didn't realise what was inside. Apiiro compared the documentation of 16 coding agents and found Claude Code was the only one confirmed to write the full approved command to a project file by default — "Claude Code's own behaviour, not the model's," reproduced with Opus 5.5 and Fable 5.1. Users reported this on Claude Code's GitHub tracker as early as August 2025 without a reply, and as of November 8 Anthropic has still not responded to Apiiro's research or changed the documentation. There is no patch. The fix, for now, is yours.The 15-minute check: are you exposed?
Stop reading and check — this is the highest-value security task on your list today.
1. Search your GitHub organisation for
.claude/settings.local.json and .claude/settings.json across every repository you own or contribute to. Each hit is a file anyone on the internet can read right now. Check the git history too — deleting a file from the current commit doesn't remove it from history.2. Search your own machine for
.claude/settings.local.json in every project folder, and read the permissions.allow rules. If any rule contains a password, token, or key, treat it as exposed — even if the repo is private today, because private repos become public, get forked, and get cloned onto machines you don't control.3. Rotate anything you find. If a secret appeared in any committed file, assume it is compromised and rotate it. Removing the file is not enough — the secret is still in git history.
4. Purge the history. Once the secret is rotated, remove the file from your git history with
git filter-repo or BFG Repo-Cleaner, then force-push — coordinating with your team first, since this rewrites history. If the repo was public, someone may already have cloned it.5. Fix the root cause. Add
.claude/ to your project's .gitignore — the whole directory — and to your global git excludes file. And stop putting secrets on the command line: use environment variables, an ignored .env file, or your cloud provider's secret manager.6. Add a scanner that actually looks for this. If you run gitleaks or TruffleHog in CI, add a custom rule flagging
.claude/settings.local.json and .claude/settings.json in any commit — or block the files from being committed with a pre-commit hook. The scanners miss one in five of these secrets on their own; the filename check is cheap and catches all of them.Conclusion
The Claude Code settings leak is not a sophisticated attack. There's no zero-day, no supply-chain compromise, no clever prompt injection. It's a permission checkbox doing exactly what it was designed to do, in a place nobody thought to look. That's what makes it dangerous: 1,122 public files holding real secrets, 63 organisations affected, a median exposure of 217 days, and one in five secrets invisible to the standard scanners.
The fix is entirely in your hands and takes fifteen minutes. Search GitHub for the file. Search your machine. Rotate what you find. Ignore the directory. Stop putting secrets in commands. Then tell your team to do the same — and put
.claude/ in your organisation's standard .gitignore template today, with a CI check that fails any pull request containing a settings file. If you use other AI coding agents, audit those too: agents persisting approvals and logs into project folders is industry-wide.Anthropic may eventually add the redaction step that should have been there. Until then, the safeguard is you — and the fifteen minutes you spend tonight checking.
---
FAQ
1. What exactly is
.claude/settings.local.json?Claude Code's per-project local settings file. It stores your permission rules — which commands Claude may run without asking again — plus other local preferences. It's meant to stay on your machine and never be committed.
2. How does a secret end up in the file?
When Claude Code asks permission to run a shell command and you choose "Yes, and don't ask again," it saves the full command as an allow rule. If that command contains a password, API key, or token, the secret is stored in plain text.
3. I use Claude Code but my repos are private. Am I safe?
Safer, but not safe. Private repos get made public, forked, and cloned onto other machines. The file can also leak when a folder becomes a repo later, or via the shared
.claude/settings.json. Check anyway — it takes minutes.4. Will gitleaks or TruffleHog catch this for me?
Only partly. Apiiro ran both over all 104,185 public copies: gitleaks flagged 564 of the 1,122 secrets, TruffleHog flagged 643, and 215 were flagged by neither. Scanners miss passwords typed inside commands because they don't match known key formats. Add a filename-based rule for
.claude/settings*.json instead.5. I found a secret in my repo's history. Is deleting the file enough?
No. Deleting the file removes it from the current commit, but the secret stays in git history where anyone can still read it. Rotate the credential first — assume it's compromised — then purge the file from history with
git filter-repo or BFG Repo-Cleaner and force-push.6. Has Anthropic fixed this?**
As of November 8, 2026, no. There is no public reply from Anthropic to Apiiro's research, no documentation change, and no cited patch — users reported the behaviour on Claude Code's GitHub tracker as early as August 2025 without a response. The fix is currently yours: rotate, untrack the file, clean history, and keep secrets out of command lines.
