Claude Code Settings.local.json Secrets GitHub Explained: 2,539 Passwords and Keys Exposed on GitHub
Image: Wikimedia Commons / Anthropic, public domain — the Claude brand mark. Claude Code is Anthropic's AI coding agent; this story is about a settings file it writes, not a new model.
📌 KEY HIGHLIGHTS
- Apiiro's research, published 5 November 2026, found 1,122 of 104,185 public copies of Claude Code's
.claude/settings.local.jsonholding at least one real secret — 1,379 distinct secrets in total. - Counting git history, the shared settings file and saved agent chat logs, the total is 2,539 secrets across 1,994 public repositories, affecting 63 organisations.
- The cause is ordinary behaviour, not a hack: approving a command with "Yes, and don't ask again" stores the full command, password included, in plain text in the project folder.
- Deleting the file does not undo the leak — older copies stay in git history and in forks. The researchers' advice is to rotate credentials first, then clean up.
- Common secret scanners miss about one in five of the affected files, because the secrets are passwords typed inside commands, not keys in a recognisable format.
What happened?
On 5 November 2026, security firm Apiiro published research by Shmulik Cohen and Matan Giladi into a quiet way developers are publishing their own passwords to GitHub. The culprit is not a breach and not a prompt-injection trick. It is a settings file written by Anthropic's AI coding agent, Claude Code.
When Claude Code proposes a shell command — say, checking a staging database or calling an API — it asks permission first. If the developer picks "Yes, and don't ask again", the tool saves that approval so it will not ask again next time. The approval is stored as a rule in .claude/settings.local.json inside the project folder. And the rule is the command itself, word for word. If the command carried a database password or an API token, the secret is now saved in plain text in the project directory.
Anthropic's own documentation confirms the mechanism: standing approvals live in that local settings file. The researchers reproduced the behaviour with Anthropic's latest models, Opus 5.5 and Fable 5.1, and say it is "Claude Code's own behavior, not the model's". Of 16 coding agents whose documentation they compared, Claude Code was the only one confirmed to save the full approved command in a project file by default.
How Claude Code settings.local.json secrets end up on GitHub
Claude Code does try to keep the file off GitHub. The first time it writes the file inside a git repository, it adds **/.claude/settings.local.json to the developer's global git excludes, so git on that computer ignores it in every repository. But that protection lives in one user's git settings on one computer, and it has gaps the researchers spell out.
It does nothing for a file that was already committed before the exclusion was added. It does not cover a folder that becomes a repository later, or a clone on another computer. And Claude Code never adds the file to the project's own .gitignore, so the protection does not travel with the project when someone else clones it. In 539 of the 1,105 leaking repositories the researchers traced, a commit listing Claude as a co-author had changed the file — their reading is that Claude often commits the file itself.
Once the file is on a public repository, anyone can read it. In half of the affected repositories, the file had been sitting on the default branch for at least 217 days before Apiiro's snapshot on 2 November. As of that date, every file with a secret was still on its repository's default branch.
Illustrative image: Wikimedia Commons / Cycling2, CC0 — a code editor with a terminal. Claude Code runs in the terminal, where developers approve the shell commands it proposes.
What Apiiro found: the numbers
Apiiro searched public GitHub between 1 and 3 November 2026. A value counted as a secret when it matched a known key format, or when a password or token sat beside the address of a public server, with an AI reviewer agreeing. The firm is careful about what the numbers do and do not prove: it did not test any credential and contacted no host, so the counts show exposure, not demonstrated compromise. One organisation it notified on 2–3 November did confirm its exposed key was still live.
| What Apiiro counted | Figure |
|---|---|
| Public copies of .claude/settings.local.json examined | 104,185 in 103,617 repositories |
| Copies holding at least one secret | 1,122 (about 1.1%) |
| Distinct secrets in those copies | 1,379 (636 provider keys, 743 passwords or tokens) |
| Database passwords among them | 379, plus 122 Supabase service-role keys |
| Other credentials | 43 SSH logins, 42 GitHub/GitLab/npm tokens, 23 AWS keys |
| Extra secrets in git history | 734 across 509 repositories |
| Secrets in shared .claude/settings.json | 298 of 76,011 public copies |
| Total, including history, shared files and chat logs | 2,539 secrets in 1,994 repositories |
| Organisations affected | 63, mostly software companies |
The strongest cases Apiiro names are a database vendor's own admin-level cloud key, a production Azure Postgres password, a Square production token and the owner password of a medical-records database. Forks spread the files further: 211 forks of 74 repositories carry the same secrets as the originals.
There is also a scanner gap worth knowing. Apiiro ran the open-source scanners gitleaks and TruffleHog over the files. Gitleaks flagged 564 of the 1,122, TruffleHog flagged 643, and 215 — about one in five — were flagged by neither. Most misses are passwords typed inside commands, such as after PGPASSWORD=, sshpass -p or mysql -p: to a scanner they look like ordinary words in an ordinary command line, not a key in a recognisable format. A clean scan is not proof of safety.
Why it matters for Indian developers
India has one of the world's largest developer communities, and AI coding agents are now part of daily work in startups, agencies and large IT teams alike. Nothing in Apiiro's research names an Indian organisation — the 63 affected organisations are not identified by country — but the workflow that causes the leak is the same everywhere: approve a command once, never think about the file it creates, push the project to a public repository.
The risk is practical rather than theoretical. A leaked database password or cloud key is the kind of credential attackers search GitHub for, and the researchers note that malware already harvests developer credentials in bulk: the Shai-Hulud npm worm, in September 2025, ran the TruffleHog scanner over infected computers. A secret that has sat public for a median of 217 days has had ample time to be copied, forked and indexed.
There is also a history here. Developers have reported this behaviour on Claude Code's GitHub tracker since August 2025, when a bug report first said approved commands with API keys were being stored word for word in the settings file. Apiiro cites four such reports; it says none received a reply from Anthropic, and all four have been closed automatically by a bot — the most recent the day before its research was published. There is no vendor patch to wait for. The fix is yours. That is the opposite of the week's other big identity story, where Microsoft fixed a CVSS 10.0 Entra flaw before anyone could exploit it — here, the exposure needs no attacker at all, just an ordinary click and an ordinary commit.
Should you care?
Readers who want the wider picture on what Claude's agents remember between sessions should read our explainer on how Claude's agent memory and dreaming work — a different feature, but the same lesson about what an agent stores for you.
How to check your repos and fix it
Apiiro's advice, in order — rotate first, clean up second:
- Search your GitHub organisation for
.claude/settings.local.jsonand.claude/settings.json, and check each repository's git history for them, even where the files are gone. Each hit is a file anyone can read right now. - Rotate every password, token and key the files have ever held, before cleaning up. Deleting the file first leaves the old credential live in history.
- Stop tracking the local file with
git rm --cached .claude/settings.local.json, and add it to the repository's own.gitignoreso the protection travels with the project. - Open the file on your own computer, even if it was never committed, and delete every rule that contains a secret.
- Keep secrets out of commands from now on. Refer to them as variables from a secrets manager, such as
$DB_URL, so the saved rule holds the variable name, not the secret — and approve patterns, such asBash(npm run:*), instead of single commands. - For security teams: treat agent folders such as
.claude/,.cursor/,.gemini/and.specstory/as holding secrets, add them to pre-commit and CI secret scanning including git history, and add the file to your organisation's.gitignoretemplates.
Copies that never reach GitHub still matter, the researchers say: the file is plain JSON in the project folder, and it can also be left inside an npm package, a Docker image, a zip archive or a synced folder. The same rotation-first rule applies.
FAQs
What is the Claude Code settings.local.json secrets leak?
When a developer picks "Yes, and don't ask again" in Claude Code, the tool saves the exact approved command — including any password or API key typed into it — in .claude/settings.local.json in the project folder. If that file is committed to a public GitHub repository, the secret is public. Apiiro found 2,539 such secrets across 1,994 public repositories.
Is my password leaked if I use Claude Code?
Not automatically. The leak happens only if a command containing a secret was saved as an approval rule and the settings file was then committed to a public repository. Check your public repos and your git history for the file, and rotate any credential it ever held if you find one.
Does deleting .claude/settings.local.json fix the leak?
No. Older versions of the file stay in git history and in forks of the repository, and 734 extra secrets were found in history alone. Rotate every credential the file has ever held first, then remove the file and clean the history.
Why didn't secret scanners catch these leaks?
Gitleaks flagged only 564 of the 1,122 affected files and TruffleHog 643; 215 were flagged by neither. Most missed secrets are passwords typed inside commands, which do not match the key formats scanners look for. The researchers recommend scanning for passwords inside commands and checking git history, not just current files.
Takeaway: A single "don't ask again" click can turn a private password into a public file — Apiiro found 2,539 secrets proving it. Check your repos for .claude/settings.local.json today, rotate first, then clean up, and keep secrets out of command lines for good.
If you work with AI coding tools, our explainer on talking to your coding agent out loud with Cursor voice chat shows how the same agents are changing the way developers work — and why knowing what they store matters.
Sources
- Apiiro — Coding Agents Are Leaking Your Secrets to GitHub (research, published 5 November 2026)
- Claude Code documentation — Settings (Anthropic)
- Claude Code documentation — Permissions (Anthropic)
- The Hacker News — Claude Code's "Don't Ask Again" File Exposes Passwords and Keys in 1,122 Public Copies on GitHub
- Cyber Security News — Claude Code's "Yes, and Don't Ask Again" Option Can Leak Passwords and API Keys to GitHub
- FourWeekMBA — Most of 2,539 Leaked Secrets Sat in a Claude Code File
Comments
Post a Comment