The button, the file, and the command
The application-security firm Apiiro published research on 6 November that found 2,539 real secrets in 1,994 public GitHub repositories, almost all of them written there by a coding agent’s own permission file.
The mechanism is ordinary. Claude Code asks before it runs a shell command. Choose “Yes, and don’t ask again” and it stores an allow rule in .claude/settings.local.json inside the project folder. When the approved rule is a literal command rather than a pattern, whatever was typed into that command — a database password, a bearer token, an SSH login — is stored with it, in plain text, in a file that sits next to the code.
Apiiro searched public GitHub between 1 and 3 November and found 104,185 copies of that file across 103,617 repositories. Of those, 1,122 files, about 1.1%, held a real secret: 1,379 distinct values in all, of which 636 matched a known provider key format and 743 were passwords or tokens sitting next to a public host. More than a third open a database directly, including 379 database passwords and 122 Supabase service-role keys, alongside 43 SSH logins for public servers, 42 GitHub, GitLab and npm tokens and 23 AWS keys.

Why the files are public at all
Claude Code does try to keep the file local: when it creates it inside a repository, it adds it to the developer’s global git excludes. That covers the common case and nothing else. It does not cover a folder that becomes a repository later, a clone on a second machine, or a file someone has already committed, and the rule never goes into the repository’s own .gitignore, so no protection travels with the project.
Apiiro also reports that the agent often commits the file itself: in 539 of the 1,105 repositories with a real secret that it traced, a commit co-authored by Claude changed it. Claude Code’s commit instructions tell the model not to commit .env or credentials.json; its own settings file is not on that list. Of 16 coding agents whose documentation Apiiro compared, it says Claude Code is the only one confirmed to write the full approved command to a project file by default.
The exposure is not brief. Every affected file was still on its repository’s default branch when Apiiro checked, and in the median case it had been there for 217 days. Deleting it does not close the hole: earlier versions of the file hold a further 734 secrets across 509 repositories that appear in no current copy, and 211 forks of 74 repositories carry the same values.

What the scanners miss, and what Anthropic says
Generic secret scanners caught about half of it. Run over all 104,185 files, gitleaks flagged 564 of the 1,122 with a real secret and TruffleHog 643; 215 were flagged by neither. The gap is passwords typed into commands — after PGPASSWORD=, sshpass -p or mysql -p — which look like ordinary words rather than provider key formats.
Apiiro says it notified each affected organisation on 2 and 3 November and Anthropic through its requested disclosure channel. It also notes that users have reported the mechanism in Claude Code GitHub issues since August 2025, that none received a reply, and that three were closed automatically as inactive or duplicate.
Anthropic’s head of Claude Code, Boris Cherny, answered on Hacker News on 7 November. “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,” he wrote, listing “making sure auto mode catches this, building in basic secret scanning” among approaches the team would prototype “before we ship something”. He also said Claude Code gitignores the file when it creates it, so in his view the exposed copies were created by hand and checked in.
Apiiro’s own limits are stated plainly: no credential was used or tested, and “real secret” means a value matching a provider format or pointing at a public host, not one known to work. One notified company confirmed its key was live. The advice that follows from that is unglamorous — rotate anything the file has ever held, untrack it, and approve patterns rather than literal commands.