Key points
- Apiiro found Claude Code's "don't ask again" feature saved passwords, API keys and SSH logins in plain text to .claude/settings.local.json files exposed across more than 1000 public GitHub repositories.
- The search uncovered 1122 files with at least one real secret, totalling 1379 distinct secrets, including database passwords, Supabase keys, SSH logins and AWS keys.
- Anthropic's Boris Cherny acknowledged the issue on Hacker News but proposed fixes like auto mode and secret scanning might not fully solve it.
Anthropic's Claude Code saved passwords, API keys and SSH logins in plain text to a settings file that ended up in more than 1000 public GitHub repositories, security firm Apiiro has found.
The problem stems from a "don't ask again" user convenience feature to save developers from repeatedly having to give Claude Code permission to perform an action, a phenomenon known as approval fatigue.
Claude Code asks before running most shell commands, and a user who picked "Yes, and don't ask again" had an allow rule saved to .claude/settings.local.json in the project folder.
Where that rule recorded an exact command rather than a pattern, any secret typed into the command was saved with it.
Apiiro reproduced the behaviour with Anthropic's current Opus 5.5 and Fable 5.1 models, noting it was a property of Claude Code rather than the model.
The firm's search of public GitHub turned up 104,185 copies of the file in 103,617 repositories.
Of those, 1122 held at least one real secret -1379 distinct secrets in all.
More than one third opened a database directly, including 379 database passwords and 122 Supabase service-role keys.
The haul also included 43 SSH logins for public servers, some of them root passwords, along with 42 GitHub, GitLab and npm tokens and 23 AWS keys.
Adding older versions of the file, a shared settings file teams commit deliberately and saved agent chat transcripts, the tally reached 2539 secrets across 1994 repositories.
Apiiro did not test whether the credentials still worked, although one organisation it notified confirmed its key had been live.
Most of the exposed files belonged to individual developers, but 63 organisations were also affected, from student groups to established vendors.
Among them were a database vendor's own cloud API key with management access, a software agency's production Square token, and the owner password for a medical-records app's cloud database.
"Yeah good catch," Anthropic's proposed fix might not work
Apiiro said it shared the research with Anthropic before publication.
Boris Cherny, head of Claude Code at Anthropic, responded in a discussion on Y Combinator's Hacker News forum, saying the AI company is looking into the problem.
"Historically Claude Code has not done secret scrubbing (there are many good tools for that), but we are looking into what we can do to prevent this," Cherny said.
He said the team planned to prototype approaches including making auto mode catch such commands and building in basic secret scanning, but it might not fix the problem.
"Yeah good catch," Cherny replied when a reader pointed out the same exposure could occur in auto mode.
He also argued that because Claude Code gitignores the file on creation, the exposed copies had been created manually and checked in, and recommended auto mode over permission rules along with the secret scanning GitHub and other hosts provide.
Conventional secret scanners offered patchy protection against the credentials leakage, however.
Of the 1122 files with a secret, gitleaks flagged 564 and TruffleHog 643, while 215 slipped past both.
The risk doesn't end at GitHub either, since the file sits in plain JSON format on developer machines.
Malware has hunted for such files before: the Shai-Hulud npm worm ran TruffleHog over victims' files in September 2025.
Long-reported issue
Claude Code users have in fact reported the problem in GitHub issues since August 2025.
In April, Check Point-owned Lakera found credentials in 33 such files across 30 packages published to the npm registry.
Apiiro advised rotating every credential the file had ever held before cleaning up, since deleting it leaves secrets in git history, forks and clones.
It also recommended untracking the file, adding it to each repository's .gitignore, referencing secrets as environment variables rather than typing them into commands, and approving patterns instead of literal commands.

Cloud Resilience Summit
iTnews Benchmark Security Awards 2026
iTnews State of Security Breakfast Sydney
iTnews Executive Retreat - Security Leaders Edition - VIC



