Apiiro found tens of thousands of public copies of a Claude Code configuration file on GitHub, and more than a thousand of them hold exploitable secrets. The culprit is a feature built to speed up day-to-day work with the agent, one that saves an approved command without telling a login credential apart from a harmless argument.
A trusted file that also remembers secrets
When a developer answers “Yes, and don’t ask again” to a run request, Claude Code writes the rule to .claude/settings.local.json at the project root. If the rule matches an exact command rather than a generic pattern, any argument typed into that command, a password or an API token included, gets written in plain text. The tool adds the file to the machine’s global Git exclusions, but not to the repository’s own .gitignore, so the protection never travels with the code. The parallel with handling environment variables and secrets cleanly is hard to miss: a credential that passes through a shell command instead of a dedicated manager stays exposed at the first slip.
How big the problem is, per Apiiro
The security firm found more than 104,000 copies of this file across more than 103,000 public repositories. Of those, 1,122 hold at least one exploitable secret, for a total of 1,379 distinct secrets. Counting Git history, duplicate forks, and a second configuration file, .claude/settings.json, the total climbs to 2,539 secrets spread across 1,994 repositories and 63 organizations.
| Secret category | Count found | Main risk |
|---|---|---|
| Database passwords | 379 | Direct access to production data |
| Tokens (GitHub, GitLab, npm) | 42 | Publishing or changing code under an account’s name |
| SSH logins to public servers | 43 | Takeover of an exposed machine |
| AWS keys | 23 | Access to the targeted account’s cloud infrastructure |
An admin-level cloud key belonging to a database vendor and the owner password of a medical records database are among the cases cited. Researchers did not systematically test whether each secret still worked, but one notified company confirmed one of its keys was still active.
Why standard scanners miss it
Of the 1,122 files holding a secret, gitleaks caught 564 and TruffleHog 643; 215 slipped past both, since a secret buried in a command line doesn’t always look like a standard API key. Apiiro recommends treating agent folders, .claude/ as much as .cursor/, as risk zones on par with an .env file, and beefing up pre-commit and CI scanners accordingly, as part of the command-line toolkit already running on a developer’s machine.
Across 1,105 repositories where a commit credits Claude as co-author, 539 show this configuration file being modified automatically by the agent itself.
How to fix the configuration right now
The order of operations matters: revoke the exposed credentials before cleaning up the repository, not after, since a purged Git history removes nothing that crawlers may have already indexed.
# 1. Untrack the file without deleting it from disk
git rm --cached .claude/settings.local.json
# 2. Add it to the project's .gitignore, not just the global exclusion
echo ".claude/settings.local.json" >> .gitignore
# 3. Check that no approved rule holds a full command with a secret in it
grep -n "Bearer\|password\|API_KEY" .claude/settings.local.json
git rm --cached does not clean up history: any secret already committed stays readable in old commits and existing forks. Immediate rotation of the secret remains the only reliable protection.What to remember
- Claude Code’s “don’t ask again” setting can write a secret in plain text to a project file that isn’t protected at the repository level by default.
- More than 1,300 exploitable secrets were found in public repositories, including database, SSH, and cloud access.
- Standard secret scanners miss close to one case in five when the credential is buried inside a command.
- The fix starts with rotating the credentials before cleaning up the repository, then adding the file to the project’s
.gitignore.
On projects tracked day to day, this agent configuration file gets the same treatment as an environment file: it never enters a commit, full stop. The habit of answering “don’t ask again” to save a few seconds has a cost that only shows up once a repository goes public. A secrets manager paired with approval rules based on patterns rather than exact commands fixes the problem at the source, without giving up the convenience these agents otherwise bring, see the field notes on editorial agents in production on that point. — Simon Janvier
Further reading: Apiiro’s full report, via The Hacker News.
