Two security vendors reported in early November 2026 that Claude Code’s per-project approval file, .claude/settings.local.json, has been committed to public repositories with working credentials inside it. Apiiro published its analysis on 5 November 2026 and GitGuardian published its own on 9 November 2026. The two counts differ by more than an order of magnitude because they measure different things. For research groups that keep analysis code, pipelines or lab-instrument scripts on GitHub, the practical step is the same under either count: check repositories for the file and rotate any credential it has ever held.
What happened
When a developer answers a Claude Code permission prompt for a shell command with “Yes, and don’t ask again”, Claude Code saves that approval as an allow rule in .claude/settings.local.json. The rule is the command string, so a password or API key typed into the command is stored with it. Anthropic’s settings documentation describes this behaviour: the file is written the first time a standing approval is given, and the approval is saved as an allow rule.
Apiiro’s analysis, as reported by The Hacker News on 7 November 2026 and CSO Online on 11 November 2026, found the file committed in public repositories, and GitGuardian’s research post extended the picture to its full public history and to Docker Hub images.
The two sets of numbers
Apiiro
- 104,185 copies of
.claude/settings.local.jsonacross 103,617 public repositories. - 1,122 of those copies (about 1.1%) contained at least one secret, 1,379 distinct secrets in total. Over a third of the secrets gave direct database access, including 379 database passwords; the rest included SSH logins, tokens for GitHub, GitLab and npm, and AWS keys.
- Counting older file versions, shared
.claude/settings.jsonfiles and saved agent chat logs, the total rose to 2,539 secrets across 1,994 repositories. - Apiiro did not test whether the secrets still work, according to The Hacker News report.
GitGuardian
- 31,088 distinct secrets in
.claude/settings.local.jsonfiles across 23,276 public GitHub repositories, 5,343 of them valid when detected. The count covers everything pushed from January 2025 to 7 November 2026. - 8,271 distinct secrets in
.claude/settings.jsonacross 6,839 repositories, 1,283 valid when detected. - 613 distinct secrets in Claude Code settings files inside public Docker Hub images, 99 valid, across 543 image repositories.
- Monthly leaks in
settings.local.jsonpeaked at 12,535 in April 2026 and fell to 959 by October; GitGuardian says it does not know why.
Why the figures differ
GitGuardian’s post states that the studies measured different things: Apiiro looked at what was exposed at the time of its scan with a conservative filter and no validity check, while GitGuardian counted everything ever pushed and included an automatic, read-only validity check. The numbers should therefore not be read as one measurement disputed by two vendors, nor added together. GitGuardian also sells secret-detection products, including a tool that scans agent commands, so its post is a vendor analysis rather than an independent audit.
Anthropic’s documented behaviour and response
The documentation says that the first time Claude Code writes the file in a git repository that does not already ignore it, Claude Code adds **/.claude/settings.local.json to the user’s global git excludes file. That entry lives on the machine where it was written. It is not added to the project’s own .gitignore, so it does not travel to collaborators or to other clones, and it does nothing for a file that is already tracked. The documentation adds that a file created by hand should be added to .gitignore by the user. CSO Online reports that the protection does not reliably carry over to other machines and that Docker does not respect .gitignore, so the file can be copied into images unless .dockerignore excludes it.
CSO Online reported that Anthropic did not immediately respond to its request for comment. GitGuardian’s post, citing a report by iTnews, says Boris Cherny, who leads Claude Code at Anthropic, replied on Hacker News that the team is investigating, that Claude Code has not historically scrubbed secrets, and that auto mode and built-in secret scanning are being prototyped but may not fully solve the problem. By that account he suggested the exposed copies were likely created manually and committed. Apiiro’s analysis, as summarised by The Hacker News, instead traced 1,105 repositories and found that in 539 of them a commit listing Claude as co-author changed the file. These two readings are not reconciled in the published reporting.
What it means for research software and lab code
The sources describe public GitHub and Docker Hub generally; none of them measures academic repositories specifically. The relevance to research software engineers, labs and research offices is therefore the exposure pattern, not a measured share of research code. A repository that holds analysis pipelines, instrument-control scripts or data-access code often also holds database passwords, cloud keys or repository tokens, and any of those typed into an approved command can end up in this file.
Steps recommended in the Apiiro and GitGuardian reporting, applicable to a research group or institutional GitHub organization:
- Search repositories and git history for
.claude/settings.local.jsonand.claude/settings.json, including forks and archived projects. - Rotate every credential either file has ever contained before cleaning up, because git history, forks and container images keep copies. Deleting the file does not revoke a key.
- Stop tracking the local file (
git rm --cached) and add it to.gitignoreand.dockerignore. - Delete allow rules that contain a secret and reference secrets through environment variables or a secrets manager rather than typing them into commands. Prefer narrow command patterns over broad ones.
- Treat agent folders such as
.claude/,.cursor/and.gemini/like.envfiles in pre-commit and CI secret scanning, and confirm the scanner detects passwords inside commands. In Apiiro’s comparison, gitleaks and TruffleHog run without verification each missed many of the files that contained secrets, mostly passwords typed inside commands.
What is not established
- How many of the exposed credentials belonged to university or research-institution repositories is not reported.
- Neither vendor reports misuse of any exposed credential; Apiiro did not test validity, and GitGuardian reports validity at detection time only.
- The cause of the decline in monthly leaks after April 2026 is unknown, according to GitGuardian.
- Anthropic’s account of how the files reached public repositories and the commit-author evidence in Apiiro’s analysis have not been reconciled.
