Passwords and API keys that developers typed into commands approved in Claude Code are sitting in public GitHub repositories, where anyone can read them, according to research published on 5 November by software security company Apiiro.

The problem starts with a single click. When Claude Code, Anthropic's AI coding assistant, proposes a shell command, it asks for permission before running it. If the developer chooses "Yes, and don't ask again", the tool saves that exact command as an "allow" rule in a project file called .claude/settings.local.json, so matching commands run without asking in later sessions. When the approved command contains a password or an API key, the secret is saved with it, in plain text.

Apiiro's researchers, Shmulik Cohen and Matan Giladi, searched public GitHub and found 104,185 copies of the file across 103,617 repositories. Of those, 1,122 copies, about 1.1 per cent, held at least one real secret, together containing 1,379 different secrets.

The exposed credentials are not trivial test keys. More than a third open a database directly, including 379 database passwords. The haul also includes 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. Apiiro says 63 organisations are affected, mostly software companies of all sizes, and the strongest cases include a database vendor's own admin-level cloud key and the owner password of a medical-records database. One company the researchers notified confirmed that its leaked key had been live.

Counting older versions of the file in git history, the shared settings file that teams commit on purpose, and saved agent chat logs, Apiiro puts the wider total at 2,539 distinct secrets across 1,994 repositories. Deleting the file does not undo the leak, because older versions remain in git history and in forks: 211 forks of 74 repositories carry the same secrets as the originals. In the median leaking repository, the file had first been committed 217 days before Apiiro's 2 November snapshot.

Claude Code does try to keep the file out of version control. Its settings documentation says the first time it writes the file in a git repository, it adds it to the user's global git excludes, so git on that computer ignores it in every repository. Apiiro says that protection stays on one machine and does nothing for a file that was already committed, a folder that becomes a repository later, or a clone on another computer. Claude Code never adds the file to the project's own .gitignore, so the protection does not travel with the project. In 539 of the 1,105 leaking repositories the researchers traced, a commit listing Claude as a co-author had changed the file, which they take to mean the tool often commits the file itself.

Of 16 coding agents whose documentation the researchers compared, Claude Code was the only one confirmed to save the full approved command in a project file by default. Apiiro reproduced the behaviour with Anthropic's latest models, Opus 5.5 and Fable 5.1, and describes it as "Claude Code's own behavior, not the model's". Users have reported the behaviour on Claude Code's GitHub tracker since August 2025. Apiiro cites four such reports and says none received a reply from Anthropic, and three were closed automatically as inactive or duplicates. As of 7 November, Anthropic had not commented publicly on the research.

Standard secret scanners miss many of these files. The researchers ran gitleaks and TruffleHog over every copy: gitleaks flagged 564 of the 1,122 secret-bearing files and TruffleHog flagged 643, while 215 were caught by neither, usually because the secret is a password typed inside a command after PGPASSWORD=, sshpass -p or mysql -p, rather than a key in a recognisable format.

Apiiro's advice is to rotate first, then clean up: search a GitHub organisation for .claude/settings.local.json and .claude/settings.json, check each repository's git history even where the files are gone, and change every password, token and key the files have ever held before deleting anything. Developers should then stop tracking the local file, add it to the project's own .gitignore, and open the local copy to delete any allow rule containing a secret. Secrets should be passed as variables from a secrets manager, such as $DB_URL, so a saved rule holds the variable name and not the secret, and approvals should cover patterns, such as Bash(npm run:*), instead of single literal commands.

Two caveats matter. Apiiro sells security products for coding agents, so it has a commercial interest in the topic, and its figures have not been independently replicated. The researchers also did not test whether the credentials still work, so "real secret" means a value matching a key format or pointing at a public host, not a credential proven to be live.