Claude Code exposed passwords: what to do right now
Claude Code saved passwords into a file that reached public GitHub. Learn what leaked, how to check, and the rotate-first fix.
Some links in this guide are affiliate links: if you buy, TechForLive may earn a commission at no extra cost to you. Details.
- Rotate every secret the file has ever held before you delete anything.
- Search GitHub and git history for .claude/settings.local.json and .claude/settings.json.
- Add the local file to your project's own .gitignore so it cannot travel again.
- Never type a password into a command. Use a variable such as $DB_URL instead.
Claude Code exposed passwords: what happened
Claude Code is an AI coding assistant from Anthropic. It asks before it runs a shell command, which is a command you type to make the computer do a job. When you pick Yes, and don't ask again, it saves that command so it can run matching commands later without asking. Trouble starts when the command holds a password or a key. It runs commands on your behalf, and it asks before it runs most of them. That ask is meant to keep you in control.
Apiiro, a security firm, searched public GitHub, a site where developers share code, and found about 104,000 public copies of the file .claude/settings.local.json. About 1 percent of them, or about 1,100 copies, held at least one real secret. Together they held about 1,400 different secrets. A small share, with large harm.
A secret counted when it matched a known key format, or when a password or token sat beside the address of a public server. Apiiro did not test whether each secret still worked. One company the researchers told earlier in the week confirmed its key had been live. That gap matters, because a leaked key that still works is an open door.
| At a glance | Answer |
|---|---|
| Public files with a secret | About 1,100 of 104,000 |
| Different secrets found | About 1,400 in those files |
| Database passwords | Hundreds of the secrets |
| Organisations affected | Dozens, mostly software firms |
| Median time exposed | More than 200 days |
| File that leaks | .claude/settings.local.json |
How one click saves a password in plain text
Say you ask Claude Code to check a database, which is where an app stores its records. Often the command it offers carries the password from your setup. Pick Yes, and don't ask again. Claude Code saves the whole command, word for word, as an allow rule in .claude/settings.local.json inside the project folder. That password goes with it.
Plain text means anyone who can open the file can read the secret. No decoding is needed. That file is meant to stay on your own machine. Claude Code tries to keep it out of git, the system that tracks changes to code. First time it writes the file in a git project, it adds the file to your global git excludes on that computer.
That guard stays on one computer. It does nothing for a file that was already committed, which means saved into the shared history. Claude Code never adds the file to the project's own .gitignore, the list that travels with the project and tells git what to leave out. In about half of the leaking projects researchers traced, a commit listing Claude as a co-author had changed the file.
Who is affected and how to check if you are
That leak hits people who use Claude Code on projects they share through GitHub. More than a third of the secrets open a database directly, including hundreds of database passwords. Others include SSH logins for public servers, tokens for GitHub, GitLab and npm, and cloud keys.
Strongest cases named by the researchers include a database vendor's own admin-level cloud key and the owner password of a medical-records database. As of the Monday before the report, every file with a secret was still on its project's default branch, the main version everyone sees. In half of those projects it had been there for more than 200 days. Some secrets belonged to small teams, and some to large firms. Size did not protect anyone, because the same button caused the same leak in each case.
Check your own work first. Search your GitHub organisation for .claude/settings.local.json and .claude/settings.json, the shared settings file teams commit on purpose. Check each project's git history for them, even where the files are gone. Open the file on your own computer too, even if it was never shared, and read each allow rule for a secret.
- GitHub search: look for both settings files in every project you own or help run.
- Git history: old versions can hold secrets long after the current file is clean.
- Your laptop: the file sits on your machine, even when it never reached GitHub.
What to do first: rotate every secret
Rotation means changing a password, token or key and replacing the old one everywhere it is used. Do that before you clean up the files. Removing the file does not undo the leak. Older versions stay in git history and in forks. Forks are copies other people made of a project. Anyone with a copy keeps the secret.
List every secret the files have ever held, then change each one at its source. Change database passwords in the database settings, and change API keys in each service's dashboard, which is its settings page on the web. Update the apps and services that use them, so they keep working with the new secret. Keep a note of each one you change, so none is missed.
Work through the public ones first, because those are the ones anyone could read. Credentials paired with a public server deserve attention first, since those give direct access. If a service shows when a key was last used, check that log after you rotate it. Watch for any use of the old key. Tell your team lead or organisation admin what happened, and check GitHub secret scanning alerts if your organisation uses them.
- Search GitHub and git history for .claude/settings.local.json and .claude/settings.json.
- Write down every password, token and key those files have ever held.
- Change each secret at its source, starting with ones paired with a public server.
- Update every app and service that used the old secret, then confirm each one still works.
Clean up the file and stop it happening again
Once every secret is changed, stop the file being tracked. Git can stop tracking a file while leaving your local copy in place. Add the file to the project's own .gitignore, so the guard travels with the project to every computer that copies it. That step protects the next person who clones the project, which means copies it to their own machine.
Open the file on your own computer and delete every allow rule that holds a secret, even if it was never committed. That file also sits on every laptop where someone clicked the button. It can turn up inside an npm package, a Docker image, a zip archive or a synced folder. Check those too if you share your work that way.
Change the habit that caused the leak. Keep secrets out of commands. Refer to them as variables from a secrets manager, such as $DB_URL, so the saved rule holds the variable name and not the secret. Approve patterns, such as Bash(npm run:*), instead of single commands. A pattern lets matching commands run without saving one exact command with a secret inside it.
To remove a secret from history, use a history-rewriting tool such as git filter-repo or BFG Repo-Cleaner. Those tools rewrite past commits to drop the file, then you push the rewritten history and everyone who copied the project must copy it again. Agree that step with your team first, because rewriting shared history can disrupt other people's work.
Stop tracking the local settings file
git rm --cached .claude/settings.local.jsonMyths you can ignore about leaked secrets
Researchers ran two well known scanners, gitleaks and TruffleHog, over every copy. Of the files with a secret, gitleaks flagged about half and TruffleHog flagged about six in ten, while about one in five was flagged by neither. Most misses were passwords typed inside commands, which look like ordinary words to a scanner. A scanner looks for a known key shape, such as a long string with a familiar prefix. A password inside a command has no such shape, so it slips past.
A leaked file also sits on your machine, and malware has looked for secrets on developer machines before. In September 2025, the Shai-Hulud worm ran the TruffleHog scanner over infected computers. A secret that never reached GitHub can still be read by software on your machine.
A third belief is that this was a fault in the AI model itself. Apiiro says it is Claude Code's own behaviour, not the model's. It reproduced the behaviour with the latest Claude models at the time of testing. Researchers compared 16 coding agents. Claude Code was the only one confirmed to save the full approved command in a project file by default.
| Check | What it finds | What it misses |
|---|---|---|
| gitleaks scan | About half of the files | Passwords typed in commands |
| TruffleHog scan | About six in ten files | Passwords typed in commands |
| Manual file read | Every rule in the file | Secrets in old history |
Quick answers
I use Claude Code but never shared my project. Am I safe?
Not quite. That file sits on your own computer, even when it never reached GitHub. Open it and delete every allow rule that holds a secret. Then change those secrets, because software on your machine could still read them.
I deleted the file from GitHub. Is the secret gone?
No. Old versions stay in git history, and forks keep their own copies. Researchers found hundreds more secrets in old versions across many projects. Rotate every secret the file has ever held, then clean up the history if your team can.
What does rotate a secret actually mean?
It means making a new password, token or key and replacing the old one everywhere it is used. Change it at its source first, then update each app or service that used it. Once changed, a leaked copy loses its value.
Why did Claude Code save my password at all?
When you pick Yes, and don't ask again, Claude Code saves the exact command as an allow rule, so matching commands run without asking later. If that command holds a password, the password is saved too, in plain text in .claude/settings.local.json.
Has Anthropic replied to the research?
Public bug reports described this behaviour and reportedly went unanswered. At the time The Hacker News reported it, Anthropic had not commented on the research.