Claude Code's "Don't Ask Again" Saved Passwords Into 1,122 Public Repo Files. Here Is the Ten-Minute Cleanup.
Security firm Apiiro found 104,185 public copies of Claude Code's .claude/settings.local.json file on GitHub, and 1,122 of them contain at least one credential. The Hacker News reported the findings on November 7. The file is where Claude Code stores the "Yes, and don't ask again" permissions you grant, and when the approved command contained a password or token, the whole command lands in the file as plain text.
What actually happens
When you approve a command with "don't ask again," Claude Code saves an allow rule to .claude/settings.local.json. If the prompt offered the exact command, that exact command is what gets stored, secrets included. Sometimes the rule is a pattern instead, which is safe. The exact-command version is the problem.
The file is meant to stay on your machine. According to the report, the first time Claude Code writes it inside a git repo, it adds the file to your global git excludes. It does not add it to the project's own .gitignore. So the protection lives on one computer, and a fresh clone, a second laptop or a teammate's machine has no such rule.
The reported numbers: 1,122 of the 104,185 copies (about 1.1%) held a secret. More than a third opened a database directly, including 379 database passwords, plus 43 SSH logins, 42 GitHub, GitLab and npm tokens, and 23 AWS keys. Counting older file versions, the shared .claude/settings.json and saved chat logs, Apiiro reports 2,539 secrets across 1,994 repositories. Apiiro did not test whether the secrets still work, though one notified company confirmed its key was live.
Why your scanner may not save you
The report says gitleaks flagged 564 of the 1,122 files and TruffleHog flagged 643. Neither caught 215 of them. Passwords embedded inside a shell command do not look like the key formats scanners are tuned for. If your safety net is a pre-commit secret scan alone, you are covered for some of this, not all of it.
Also worth knowing: the article says four related GitHub issues were closed by an automated bot without a reply from Anthropic, the earliest filed in August 2025. I could not reach Apiiro's own write-up, so everything above is The Hacker News's account of it. Treat the exact counts as reported, not independently confirmed.
The ten-minute cleanup
Do these in order. The order matters.
- Search every repo you own, including history, for the files:
git log --all --full-history -- .claude/settings.local.jsonand the same for.claude/settings.json. - Open any hit and look for allow rules containing a literal password, token or connection string.
- Rotate every credential the file ever held. Deleting the file does not undo the leak, because git history and forks keep it.
- Only then clean up:
git rm --cached .claude/settings.local.json, and add that path to the project.gitignore. - Replace literals with environment variables or a secrets manager, so the command you approve contains a variable name and not a value.
The researchers also suggest approving patterns like Bash(npm run:*) instead of single exact commands. That is the habit change that matters most.
The honest take
I would not stop using the "don't ask again" option. It is what makes an agent usable for a solo builder who cannot babysit every prompt. But the option is only safe when the command you approve is secret-free, and that is on you, because the tool will happily store whatever you approved.
The counter-take is fair: 1.1% is a small slice, and most of those hits may be dead credentials or test values. Nobody has measured how many are live. But the cost of checking is ten minutes, and the cost of one live production database password in a public repo is not comparable. I would run the history search on every repo this week, and add the local settings file to my global .gitignore template so new projects start protected.
Author
Lukas
@lukcombinator