Security firm Apiiro counted 1,122 public GitHub files holding real secrets on November 5, 2026, and every one of them got there the same way: a developer clicked "Yes, and don't ask again" in Claude Code, and the coding agent saved the approved command, password and all, into a project settings file that later reached GitHub. The wider count is 2,539 secrets in 1,994 public repositories. The median exposed file had sat on its repository's default branch for 217 days, and in 118 repositories it had sat there for more than a year.
How one click saves a password
Claude Code asks before it runs a shell command, several times a session. When a developer picks "Yes, and don't ask again," the agent runs the command and adds a permission rule to .claude/settings.local.json inside the project folder, so it will not ask again. The rule is the command string itself. If the command carries a secret, because Claude Code pulled it from a .env file or a config file to check a database or call an API, the secret is saved verbatim into the file. Apiiro's research, published November 5, 2026 by Shmulik Cohen and Matan Giladi, reproduced the behavior with the Opus 5.5 and Fable 5.1 models, and calls it Claude Code's own behavior, not the model's: the agent writes the rule, the model only proposes the command.
The file is meant to stay on the developer's machine, and Claude Code tries to keep it there. When it creates the file inside a git repository, it adds the file to the developer's global git ignore list. That covers the common case. It does not cover a folder that becomes a repository later, a clone on another machine, or a file someone already committed, because the rule never goes into the repository's own .gitignore, so nothing travels with the project to protect it. And often Claude Code commits the file itself: in 539 of the 1,105 repositories with a real secret that Apiiro traced, a commit co-authored by Claude changed the file. Those commits name every recent model, from Sonnet 4.5 to Opus 5.5.
What Apiiro found
Apiiro downloaded every public copy of the file it could find on GitHub between November 1 and 3, 2026: 104,185 copies in 103,617 repositories. Of those, 1,122 files, about 1.1 percent, hold a real secret, and together they hold 1,379 distinct secrets: 636 provider keys and 743 passwords and tokens for public hosts. More than a third open a database directly: 379 database passwords and 122 Supabase service-role keys, a total of 501. The 63 affected organizations are mostly software companies, and the strongest cases, each checked at a pinned commit, include a database vendor's own cloud API key with manage access and no expiry claim, a production Azure Postgres password at a B2B startup, a Square production token at a software agency, and the owner password for a medical-records app's cloud Postgres database at an IT services firm.
The largest secret types, as Apiiro's chart lists them, are:
| Secret type | Distinct secrets found |
| Service API tokens | 398 |
| Database passwords | 379 |
| AI model API keys | 149 |
| Supabase service-role keys | 122 |
| Google API keys | 110 |
| Supabase account tokens | 103 |
| SSH server logins | 43 |
| GitHub, GitLab and npm tokens | 42 |
| AWS keys | 23 |
Large allowlists drive the rate. Fewer than one in 500 files under 500 bytes holds a real secret, against one in ten files over 8 kilobytes. Deleting the file does not solve it: earlier versions of the file hold 734 real secrets in 509 repositories that appear in no current copy, and 211 forks of 74 repositories carry the same secrets. Counting git history, the shared settings file, and agent chat transcripts saved in repositories, the total comes to 2,539 distinct secrets in 1,994 public repositories.
Why the scanners missed one in five
Apiiro ran gitleaks and TruffleHog over all 104,185 files. Of the 1,122 files with a real secret, gitleaks flagged 564 and TruffleHog flagged 643. Neither flagged 215, one in five. The gap is passwords inside commands. Scanners look for key formats: a provider prefix, a long random string. A password after PGPASSWORD=, sshpass -p, or mysql -p, or a bearer header in a curl call, is an ordinary word in an ordinary command line, and both tools pass over it. Apiiro's example is a real rule from a public file, a database password next to a public host in a psql command, that neither scanner flagged. Scanners are the last line here, not the first, and our October security report card found the same pattern across nine 2026 incidents: detection keeps arriving after the exposure, because the tool that saves the secret is not the tool that scans for it.
It is not only this file
The allowlist is the clearest case, but agents write secrets into other files developers commit. The shared .claude/settings.json, which teams commit on purpose, holds secrets in 298 of 76,011 copies. Agent chat transcripts hold secrets in 120 files across 87 repositories, agent memory files in 9 of 1,200 checked, handoff and deploy notes in 33 of 2,095, and VS Code Copilot auto-approve settings in 9 of 173. A third of the handoff notes with a secret were written by the agent itself. The file leaks beyond GitHub too: of 31,053 Hugging Face Spaces, 126 hold it, and one has allow rules with a database service key and a user password; on GitLab.com, 2 of 69 public copies hold a real secret, including a GitLab access token. This is the third secrets-exposure pattern ByteHerald has tracked in six weeks: in October, researchers found AI hacking tools with their own control panels left open to the internet, and Meta's own app leaked private chats through share links anyone could enumerate. The habit that leaks is the same everywhere: typing a secret into a command that an agent then records as an approval.
The fix, in order
Apiiro's order matters: rotate first, clean up second. Removing the file does not clear git history, forks, or clones, so every credential the file has ever held must be rotated before anything else. Then untrack the file with git rm --cached .claude/settings.local.json and add it to the repository's own .gitignore, open every copy on your machine and delete every rule that contains a secret, and stop typing secrets into commands: reference them as $VAR from a secrets manager, so the command carries no secret for the agent to record. Approve patterns, like Bash(npm run:*), instead of literal commands. For security teams, Apiiro's advice is to treat agent folders, .claude/, .cursor/, .gemini/, .specstory/, and agent memory files, as secret-bearing, include them in pre-commit and CI secret scanning including history, make sure the scanner catches passwords inside commands and not just key formats, and triage credentials paired with public hosts first, because those are the ones that give access. The issue itself is not new: users reported it as a GitHub issue in August 2025, four issues have been filed since, none got a reply from Anthropic, and three were closed automatically as inactive or duplicate. Apiiro reported each organization case to its owner on November 2 and 3, 2026, and one company confirmed its key had been live.
By ByteHerald Staff. Apiiro researchers Shmulik Cohen and Matan Giladi reported on November 5, 2026 that 1,122 of 104,185 public copies of Claude Code's settings.local.json file on GitHub hold a real secret, with 2,539 distinct secrets across 1,994 repositories in total, a median exposure of 217 days, and 215 of the 1,122 files missed by both gitleaks and TruffleHog, and that no credential was used or tested, so "real secret" means a credential matching a provider format or pointing at a public host. Anthropic's Claude Code settings documentation confirms that standing approvals are saved in the project's local settings file and that the file is added to the developer's global git ignore list when created inside a repository. iTWire's summary of the research, published in November 2026, confirms the collection dates of November 1 to 3, 2026, the 63 affected organizations, and that one notified company confirmed its exposed key had been live.
Comments
Post a Comment