Claude Code Leaked 2,539 Secrets Onto GitHub. I Checked My Own Repos the Same Morning

I found out about it the way you find out about most things that ruin your morning: a link in a group chat, no context — "bro check your repos."

Apiiro had scanned public GitHub for copies of .claude/settings.local.json — the file where Claude Code keeps your local settings — and found 104,185 copies sitting in 103,617 public repos. Of those, 1,122 copies, about 1.1%, held at least one secret. Total damage: 2,539 secrets, spread across 1,994 repos. The breakdown reads like a password manager someone dropped in a car park: 379 database passwords, 43 SSH logins, 42 GitHub, GitLab and npm tokens, 23 AWS keys. Sixty-three organisations caught in it.

Two hundred and fifteen of those secrets slipped past both TruffleHog and GitHub Secret Scanning — the two tools most of us treat as the safety net.

Why this one file is special

Claude Code has a feature called "Don't Ask Again." You approve a command once, it remembers, and it stops asking. Handy. The problem is where it remembers: it saves the full approved command, secrets and all, into settings.local.json. Apiiro checked 16 coding agents. Claude Code was the only one confirmed to save full approved commands by default.

So the leak isn't some exotic bug. It's a convenience feature doing exactly what it was built to do, in a file that was never supposed to leave your machine — except people commit their dotfiles and their "backup of my laptop" repo, and the file rides along. Once it's in git history, deleting it from the current commit doesn't help; the secret stays in the older versions, which is part of how that 2,539 number got so big.

Boris Cherny, Anthropic's head of Claude Code, replied on Hacker News on November 9: they're exploring safeguards, with prototype checks to catch sensitive commands in auto mode plus some basic secret scanning. No date given. But "we're working on it" doesn't rotate your AWS keys for you.

The check I ran on my own stuff

The check takes ten minutes. Ten. That's the part I keep coming back to, because the check is so small and the number of people who will never do it is so large.

Step 1: search GitHub for the filename. GitHub's code search, logged in, across your org and your own account: filename:settings.local.json. Also search for .claude as a path. If anything comes back that you don't recognise, that's your answer — stop and deal with it first.

Step 2: grep your local repos. This is the one people skip, because the public scan only catches what's already pushed. Run this from wherever you keep your code:

grep -r "settings.local.json" ~/code --include="*.git*" -l 2>/dev/null
git ls-files | grep -i claude

The second command is the one that matters: if .claude/settings.local.json shows up there, it doesn't matter what your .gitignore says — it's already in.

Step 3: rotate anything you find. Not "check if it was used." A database password that sat in a public repo for six months is compromised whether or not anyone tried it. Same rule for AWS keys, npm tokens, SSH keys.

What I found in mine: nothing

And that's the honest ending to this story. I checked. My repos were clean. No .claude directory tracked anywhere, no stray settings file in an old dotfiles repo I'd forgotten about.

I'm not telling you that to brag. "I checked and found nothing" is the only good outcome here, and it cost me ten minutes and a search query I should have run months ago. The 1.1% figure sounds small until you remember it's 1,122 copies of a file that should never have been public, in repos belonging to real teams, with production database passwords in them.

The fix, and the catch in the fix

The actual protection is a machine-local git exclude, not a .gitignore you commit to the repo — that only helps people who clone after you add it, and does nothing for files git already tracks. The exclude lives in .git/info/exclude on your own machine and tells git to never pick the file up.

The catch: it only protects future commits on that machine. If the file is already tracked, you have to untrack it, rewrite the history it touched, and rotate every secret in it — history is public forever once pushed.

So do the ten-minute check, today, while the story is still fresh enough to scare you into it. The people in that 1.1% didn't think they were the kind of person who leaks secrets onto GitHub either. Somebody has to be the one. Make sure it isn't you — and make sure you actually checked instead of just assuming.