Claude Code secrets end up in a file many developers never meant to share. Apiiro’s research team scanned public GitHub repositories and found 2,539 real secrets across 1,994 of them: database passwords, cloud keys, API tokens and SSH root logins. The file that held them is the one Claude Code writes when a developer picks Yes, and don’t ask again on a command it proposes.
What Does Claude Code’s Don’t Ask Again Option Do?
Claude Code asks for permission before it runs a shell command, and it asks again for the next command too. Apiiro’s post says that after the tenth interruption in a session, most developers stop reading the commands closely. Picking Yes, and don’t ask again lets Claude Code run the command and saves a permission rule, so it will not ask again for that exact command text.
The rule is saved in .claude/settings.local.json, inside the project folder. Apiiro’s post says the rule is the command string itself, so a secret typed into that command is saved with it. The file is meant to stay on the developer’s machine. When Claude Code creates it inside a git repository, it adds the file to the developer’s own global git ignore list.
That step covers the common case, Apiiro’s post says, but not every one. It does not cover a folder that becomes a repository later, a clone on another machine, or a file someone already committed. The rule never goes into the repository’s own .gitignore, so nothing travels with the project to protect it.
- The secretLives in a config file, an environment variable or a cloud console on your machineWho covers itYou
- The approved commandCarries the secret because the task needs it to runWho covers itClaude Code
- The permission file.claude/settings.local.json stores the exact command text, inside the project folderWho covers itClaude Code
- Your global git ignoreAdded automatically when the file is created inside a git repositoryWho covers itClaude Code
- The repository’s own .gitignoreNever updated automatically, so a later clone, a new machine or an already committed file is not coveredWho covers itYou
- GitHubIf the file reaches a public repository, this is where Apiiro’s search found itWho covers itYou
What Did Apiiro Find on GitHub?
Apiiro searched GitHub’s public code and commit history from 1 to 3 November 2026 and found 104,185 copies of .claude/settings.local.json in 103,617 repositories. It says 1,122 of those files, about 1.1%, hold a real secret: a key in a known provider format, or a password or token next to a public host.
Counting the file’s history, a shared settings.json that teams commit on purpose, and agent chat transcripts saved in repositories, the total changes. Apiiro says it reaches 2,539 distinct real secrets in 1,994 repositories. 63 organizations hold a real secret in a public allow list, from student and hackathon groups to startups, software agencies and established vendors. One organization confirmed to Apiiro that its key had been live.
Apiiro describes the strongest cases without naming the organizations. They include a database vendor’s own cloud key with manage access, a startup’s production database password and a software agency’s payment processor access token. An information-technology services firm’s medical-records application exposed its database owner password the same way. The allow lists also hold 43 SSH logins for public servers, some of them a root password.
Why Do Secret Scanners Miss Many of These?
Apiiro ran gitleaks and TruffleHog over all 104,185 files. Of the 1,122 files with a real secret, gitleaks flagged 564 and TruffleHog 643, and 215 were flagged by neither tool. Apiiro says the gap is passwords written inside a command, such as after PGPASSWORD= or sshpass -p. To a scanner built for key formats, that password reads as an ordinary word in an ordinary command line.
Why Does This Problem Reach Beyond One File?
The allow list is not the only file at risk, Apiiro says. Teams commit a shared .claude/settings.json on purpose, and 298 of 76,011 checked copies hold a real secret. Apiiro also found secrets in 120 agent chat transcripts across 87 repositories and in agent memory files in 9 repositories. It found them in 33 deployment and handoff notes too, a third of which the agent itself had written.
Secrets from these agent files travel even when a developer never commits anything. In September 2025, the Shai-Hulud npm worm downloaded TruffleHog and ran it over a victim’s files to harvest credentials, as we cover in our Shai-Hulud entry. Weeks earlier, malicious Nx packages told the developer’s own Claude Code and Gemini CLI to search the disk for secrets, the incident we describe in our Nx Console write-up.
How Do You Check and Rotate Claude Code Secrets?
Apiiro’s post lists what a developer and a security team should do once a copy of the file turns up. The order below follows its advice.
- Check whether the file is publicSearch your GitHub organization for .claude/settings.local.json and .claude/settings.json; each hit is a file anyone can read right now.
- Check whether it was ever committedLook in each repository’s git history for the file, even if it is gone today; a file that was once committed is still in every fork and clone.
- Read the allow listOpen every copy on your own machines and read what each approved command carries: passwords, tokens, keys and connection strings.
- Rotate firstApiiro says to rotate every credential the file has ever held before cleaning it up, because removing the file does not clear git history, forks or clones.
- Stop typing secrets into commandsReference them as a variable from your secrets manager, and approve a command pattern rather than the literal command text.
What Did Anthropic Say, and What Should Change Next?
Apiiro’s post says it shared the research with Anthropic before publishing. It reports that Boris Cherny, who leads Claude Code, then wrote on Hacker News that Anthropic is looking into what it can do to prevent this. Basic secret scanning, Cherny said, is one approach Anthropic plans to try.
The same gap applies to any AI coding agent that records what it runs, not just Claude Code. Our Claude Code extension response playbook covers a different Claude Code incident, and it explains what to do once an agent’s permissions have already been abused.
For the broader question of how an agent’s own tokens and credentials should be managed, see our page on AI agent identity and access. Our entry on credentials in files covers the wider technique of pulling secrets out of configuration.