Claude Code settings files leaked 31,088 secrets on GitHub

What we know as of November 9, 2026, from GitGuardian's report of November 9, 2026. Figures are theirs.

Claude Code asks before it runs a shell command, and it offers a shortcut for commands you expect to approve all afternoon. GitGuardian researcher Guillaume Valadon has published an account of what that shortcut has left behind in Claude Code projects on public GitHub: 31,088 distinct secrets in the file .claude/settings.local.json, spread across 23,276 repositories between January 2025 and November 7, 2026. GitGuardian says 5,343 of those secrets were valid when it detected them.

The report builds on an analysis Apiiro published on November 5. Apiiro looked at what is exposed in current copies of the file; GitGuardian counted every version it saw pushed, including versions that were later deleted or rewritten, and checked whether each credential still worked. The leak is not a breach of any one company. It is a habit, repeated by thousands of developers, that turned a local convenience into a public record of their keys.

How does an approved command end up holding a key?

GitGuardian walks through the case that first put it on the trail. A developer asks Claude Code to list the workflows on an n8n server, and the agent proposes a curl command with the n8n API key in a header. The developer answers "Yes, and don't ask again." According to the report, Claude Code then writes an allow rule into .claude/settings.local.json in the project folder, and that rule is the command string itself, key included.

The report says Claude Code keeps that file out of git on the machine where it creates it, but nothing in the repository does. On another machine, in an older clone, or where the file was already tracked, it gets committed along with everything else. In a sample of about 3,000 occurrences, GitGuardian found every secret it could place sitting in an allow rule or an environment block, in the exact shape the permission prompt writes.

By GitGuardian's count, curl commands carrying bearer tokens and API keys make up about half of the volume. The credentials that most often still worked came from database and SSH commands: the file held 1,955 distinct valid Postgres connection strings and 292 valid SSH passwords, along with valid Google API keys, Telegram bot tokens and AI service keys. The researchers add that 63% of occurrences came from generic detectors, such as a password after PGPASSWORD=, which has no provider prefix for a pattern-based scanner to match.

Why doesn't deleting the file fix it?

Because copies have already travelled. GitGuardian also looked at public Docker Hub images and found the same files in 543 image repositories and 7,625 tags. The report explains why: a COPY . . instruction in a Dockerfile takes the working tree rather than the git index, so a file that git ignores still ships unless .dockerignore lists .claude/. That produced 613 distinct secrets, 99 of them valid, and the report describes one valid Cloudflare API token that appears in 559 tags of a single image. Deleting the file from the repository does nothing for images already pushed, nor for forks and git history.

The report notes two related exposures. CLAUDE.md, the instructions file developers give the agent, held 6,155 distinct secrets, 2,537 of them valid, which GitGuardian calls the highest validity rate of any file it examined. And it found the agent's own login file, .claude/.credentials.json, in 371 repositories, which it reads as whole home directories being committed. It reports a similar pattern for another agent's .codex/auth.json.

There is some encouraging news in the data. Monthly leaks in settings.local.json peaked at 12,535 occurrences in April 2026 and fell to 959 by October, a 92% drop. GitGuardian says it does not yet know why, and lists possible causes on both its own side and the tool's.

What has Anthropic said?

GitGuardian cites a reply on Hacker News, reported by iTnews, from Anthropic's Claude Code lead. According to that account, the team is looking into the problem, Claude Code has not historically scrubbed secrets, and auto mode and built-in secret scanning are being prototyped but may not fully solve it. The reply also said Claude Code gitignores the file when it creates it, so exposed copies were likely created manually and committed. GitGuardian responds that, in the occurrences it inspected, the contents matched what the permission prompt writes rather than hand-typed rules.

What should teams do now?

GitGuardian's advice for developers starts with rotation, because history, forks and images keep copies that a cleanup cannot reach. The order matters:

1. Rotate every credential the file ever held.
2. Add .claude/ to the repository's own .gitignore and .dockerignore.
3. Open the file, or run /permissions, and delete every rule that contains a secret.

From then on, the report recommends referring to secrets by variable, such as $N8N_API_KEY, so that a saved rule records the name rather than the value, and approving narrow command prefixes rather than a broad rule that approves any curl. For security teams, it suggests treating agent configuration folders and files such as CLAUDE.md and .mcp.json the way they already treat .env files: scanned before commit, in CI, in history and in the container registry.

What is the wider lesson for credentials you share at work?

A key pasted into a command does not stay in that command. It can be written to a settings file, kept in a transcript, baked into an image and pushed somewhere public, long after the task that needed it is done. The same is true of a key pasted into a team chat so a colleague can try something quickly: the convenient copy is the one that outlives the work.

The habit that helps in both places is to keep the value out of the text people and tools save. Load keys from the environment or a secrets manager rather than typing them into commands, and when a teammate needs a key or a .env file, hand it over in an encrypted link that expires after it is read rather than in a message thread. Our guides to sharing an API key and sharing .env files cover the handover; with CredenShare, browser-created shares are encrypted before they leave the browser, while shares created from Slack are encrypted on CredenShare's servers. And if a key does turn up somewhere public, our post on the LiteLLM key that was deleted but not revoked shows why rotation, not deletion, is what closes the door.

---

Sources (checked on November 9, 2026):
GitGuardian: Claude Code settings.local.json Secrets: 17 months of exposure on GitHub, & Docker Hub (November 9, 2026)

Product names are trademarks of their respective owners. CredenShare is not affiliated with them.