Skip to content

Independent cybersecurity briefing

Latest

RSS
Breaches, bounties, zero-days, and AI.

AI & Tech

Claude Code: 1,122 copies leak keys

Apiiro found 1,122 public GitHub copies of a Claude Code settings file that store passwords and API keys saved when a developer approved a command. Search organization history for that file, rotate every secret it ever held, and only then delete it.

By ZeroDay Times Desk4 min read

Editorial thumbnail for “Claude Code: 1,122 copies leak keys”, neural graphic on a royal purple and neon rail-right card, [ AI ] badge, and the ZeroDay Times mark.

Apiiro said this week that 1,122 public copies of a Claude Code settings file on GitHub each hold at least one password or key. Anthropic’s coding assistant writes that file when a developer approves a shell command and chooses to skip the question next time. When the approval covers one exact command, the saved rule keeps the full line. A token or password typed into it sits in the project in clear text, where a later commit can publish it.

The file is common. Apiiro counted 104,185 copies across 103,617 repositories. About 1.1 percent of those copies contain a secret, and those 1,122 files hold 1,379 distinct values. More than a third open a database directly, including 379 database passwords. The same pile includes 43 SSH logins for public servers, 42 tokens for GitHub, GitLab, and npm, and 23 AWS keys. Sixty-three organizations own files in the set, most of them software companies of every size. The sharpest cases Apiiro describes are an admin-level cloud key belonging to a database vendor and the owner password of a medical-records database.

Apiiro did not test whether the secrets still authenticate. One company notified earlier in the week confirmed that its key was still live. As of Monday, every file that held a secret was still on the repository’s default branch. In half of those repositories it had been there for at least 217 days.

The ignore rule stays on one laptop

Claude Code tries to keep the local settings file out of git. The first time it creates the file in a repository, it adds the path to that user’s global git excludes, so git on that computer skips the file everywhere. The exclude lives in one person’s settings on one machine. A copy already committed is outside its reach. The assistant does not add the file to the project’s own ignore list, so the protection stays behind when the project is cloned, forked, or opened on another computer.

Apiiro traced 1,105 repositories and found that in 539 of them a commit listing Claude as a co-author is what changed the file. The reading the researchers offer is that the assistant often commits the file itself. Removing the current copy leaves the secret in history. Older versions hold 734 further secrets across 509 repositories, usually because someone deleted the file later. Forks carry the same values on: 211 forks of 74 repositories still contain secrets that match the originals.

A second file, the shared project settings that teams commit on purpose, held secrets in 298 of 76,011 public copies, mostly inside allow rules. Fold in older versions and saved agent chat logs and Apiiro’s total is 2,539 secrets across 1,994 repositories.

Of 16 coding agents whose docs Apiiro compared, Claude Code is the only one confirmed to save the full approved command in a project file by default. Users had already reported it. A bug filed on August 11, 2025, said approved commands were landing in the local settings file with API keys and tokens intact. An automated bot closed that report as not planned on January 3, after 60 days without activity. Apiiro says the four related reports it cites were all closed by the same bot, the latest yesterday, and that none drew a reply from Anthropic.

Rotate first, then clean the repo

Search the GitHub organization for .claude/settings.local.json and .claude/settings.json, and search history, including repositories where the files are already gone. Rotate every password, token, and key those files have ever held before anyone deletes them or rewrites history. A value that has been public has to be dead at the issuer. Cleanup is the second step.

On each developer machine, open the local file even if it never left the laptop, and drop every rule that contains a secret. Keep secrets out of the command line. Pull them from a manager and let the command refer to a variable, so a remembered approval stores the name. Prefer an approval that covers a class of commands over an approval of one full line. A copy that never reaches GitHub still counts: the file is plain JSON in the project folder, and it can travel inside a package, an image, an archive, or a synced directory.

Security teams should treat agent folders and agent memory the way they treat environment files, on laptops and in repositories. Put those paths in pre-commit and CI secret scanning, and include git history. A scanner that only matches known key formats misses a password typed into a command. Apiiro ran two common scanners over the 1,122 files without the verification step. One flagged 564, the other 643, and 215 files were flagged by neither. Most of those misses were passwords inside commands. Start the rotation with credentials that sit next to a public server address. Add the local settings file to the organization’s ignore templates so the next laptop does not depend on a personal git exclude.

This briefing relies on public reporting by The Hacker News and on Apiiro’s research note.

Corrections and tips:[email protected]