1,122 public copies of a developer settings file on GitHub contain at least one password, token, or key — files that, once committed, can and do persist in history and forks where anyone can read them.
.claude/settings.local.json: how an approved command becomes a public secret
When a user selects "Yes, and don't ask again," Anthropic's AI coding assistant, Claude Code, saves an allow rule in a project file named .claude/settings.local.json, according to its permissions documentation. That rule records the approved command word‑for‑word so that matching commands run without prompting in later sessions. If the approved command was an exact command line that included a password or token, the secret is saved in plain text inside the file.
Claude Code attempts to keep the file out of git by adding it to the invoking user's global git excludes the first time it writes the file in a repository. That protection, the researchers note, remains only on that one computer and does not add the file to the project’s own .gitignore, so it does not travel with the project or prevent earlier commits from already containing the file.
Apiiro's findings: scale, types of secrets, and who is affected
Software security company Apiiro searched public GitHub and found 104,185 copies of the file across 103,617 repositories. About 1.1% of those copies — 1,122 files — held at least one secret, for a total of 1,379 different secrets in the current copies. When Apiiro extended its view to older versions, forks, shared team files, and saved agent chat logs, the aggregate was 2,539 secrets across 1,994 repositories.
The current-copy breakdown includes 379 database passwords, 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. Apiiro identified 63 organizations among the file owners, mostly software companies, and highlighted strong cases such as a database vendor’s admin‑level cloud key and the owner password of a medical‑records database. As of Apiiro’s Monday check, every file with a secret was still on its repository’s default branch, and in half of the affected repositories the file had been present for at least 217 days.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleGit behavior, commits, forks and persistence
Removing the file from a project does not undo the leak because older versions remain in git history and forks. Apiiro traced 1,105 repositories and found that in 539 of them a commit listing Claude as a co‑author changed the file, which the researchers take as evidence that Claude often commits the file itself. They also found 211 forks of 74 repositories carrying the same secrets as the originals, and older versions across 509 repositories contained 734 additional secrets that are no longer in current copies.
Scanner gaps and malware context
Common secret scanners miss many of these files because passwords typed inside shell commands look like ordinary words rather than recognizable key formats. Apiiro ran gitleaks and TruffleHog over every copy without those tools’ verification steps: gitleaks flagged 564 of the 1,122 secret‑containing files and TruffleHog flagged 643; 215 files were not flagged by either tool. Apiiro notes that scanners should look for passwords inside commands, not only known key formats.
The researchers also reminded readers that files on developer machines matter even if they never reach GitHub: the JSON file can be left in an npm package, Docker image, zip archive, or a synced folder. Apiiro referenced a prior incident in which the Shai‑Hulud worm ran TruffleHog over infected computers in September 2025, and the scanner flagged more than half of the files it examined as secret.
What this means for developers, security teams, and enterprises
- Developers: Apiiro’s first step is rotation — change every password, token and key the file has ever held before attempting cleanup. Then search GitHub organizations for .claude/settings.local.json and .claude/settings.json, inspect git history even where the files were deleted, stop tracking local files with git rm --cached .claude/settings.local.json, add the file to the repository’s own .gitignore, and delete any rule that contains a secret from local copies. Keep secrets out of literal commands: use variables (for example, $DB_URL) so saved allow rules do not contain raw secrets, and prefer approving patterns (such as Bash(npm run:*)) instead of single exact commands.
- Security teams and enterprises: treat agent folders such as .claude/, .cursor/, .gemini/ and .specstory/ as you would .env files on laptops and in repositories. Add those locations to pre‑commit and CI secret scanning that includes git history, update organization .gitignore templates to include .claude/settings.local.json, and prioritize checking credentials paired with public servers first.
Apiiro also notes that Claude Code is the only one of 16 coding agents they compared that is confirmed to save the full approved command in a project file by default. Earlier bug reports about this behavior were filed as far back as August 11, 2025; an automated bot closed a report as "not planned" on January 3 after 60 days without activity. Apiiro says the four related reports it cites have all been closed by the same bot, the most recent yesterday, and that none received a reply from Anthropic.
The practical takeaway is stark and immediate: an AI assistant’s convenience setting has left readable secrets in public repositories, and those secrets propagate through history and forks. Rotation, exhaustive discovery, and better scanning rules are the remedies Apiiro prescribes — actions that must precede cleanup if organizations hope to close the window these files have opened.
