Skip to content
AI Security Wire

Published

- 4 min read

By

Claude Code Approval Rules Leave Secrets in 1,122 Public GitHub Files

Claude Code secrets leakage GitHub coding agents credential exposure Apiiro developer security
img of Claude Code Approval Rules Leave Secrets in 1,122 Public GitHub Files

Passwords and API keys that developers typed into approved Claude Code commands are sitting in public GitHub repositories. Apiiro, a software security company, published the research on 5 November 2026, and The Hacker News covered it on 10 November.

What Apiiro found

By default, Claude Code asks before running most shell commands. Anthropic’s settings documentation says that choosing “Yes, and don’t ask again” for a Bash command saves the approval as an allow rule in .claude/settings.local.json. Apiiro’s point is that the saved rule can be the exact command, so a password or token typed into it is stored too, in plain text.

Apiiro searched public GitHub and counted 104,185 copies of the file in 103,617 repositories. Of those, 1,122 copies (about 1.1%) hold at least one secret, 1,379 distinct secrets in total. Apiiro’s breakdown includes 379 database passwords, 43 SSH logins for public servers, 42 GitHub, GitLab and npm tokens, and 23 AWS keys. It says 63 organizations are affected, and that one of them confirmed a key had been live. Apiiro did not test whether the other secrets still work.

Apiiro says every file holding a secret was still on its repository’s default branch on 2 November 2026, and in the median affected repository the file had first been committed 217 days earlier. It also counted 211 forks of 74 repositories that carry the same secrets as the originals, which is why deleting the original file does not undo the exposure.

Counting file history, the shared .claude/settings.json file and saved agent chat transcripts, Apiiro puts the total at 2,539 secrets across 1,994 repositories.

Why the protection fails

Anthropic’s documentation says that, in a git repository that does not already ignore the file, Claude Code adds **/.claude/settings.local.json to the user’s global git excludes the first time it writes the file. Apiiro argues this does not help in several common cases: a file already committed, a clone on another machine, or a folder that becomes a repository later. The rule is never added to the project’s own .gitignore, so nothing travels with the project.

In 539 of the 1,105 repositories with a secret that Apiiro traced, a commit co-authored by Claude changed the file. Apiiro reads that as evidence that Claude often commits the file itself.

Apiiro compared 16 coding agents’ documentation and says Claude Code is the only one confirmed to save the full approved command in a project file by default.

Anthropic’s response

On 7 November a Hacker News user named bcherny, writing “Boris from the Claude Code team here”, replied to the research (Apiiro identifies this person as Anthropic’s head of Claude Code). The comment says Claude Code has historically not done secret scrubbing, and that the team is “looking into what we can do to prevent this.” It also makes three points: the file “is meant to stay local” and is gitignored automatically when Claude creates it, so in the commenter’s view the exposed files were created manually and checked in; permission rules are “old hat” and users should use auto mode instead; and everyone should enable secret scanning on their source host.

Our reading: the manual-creation point sits uneasily with Apiiro’s finding that Claude co-authored commits touched the file in 539 repositories. We have not tested either side’s claim.

What to do

Apiiro’s recommended order is to rotate first and clean up second.

  1. Search your GitHub organization for .claude/settings.local.json and .claude/settings.json, and check git history even where the files are gone.
  2. Rotate every password, token and key those files have held.
  3. Run git rm --cached .claude/settings.local.json and add the file to the repository’s own .gitignore.
  4. Delete rules containing secrets from the file on your own machine.
  5. Keep secrets out of commands by referring to variables such as $DB_URL, and approve patterns instead of single commands.

For security teams, Apiiro suggests treating agent folders such as .claude/, .cursor/ and .gemini/ like .env files, adding them to pre-commit and CI secret scanning, and making sure the scanner catches passwords inside commands.

Our assessment: the useful lesson is wider than one tool. Any agent that records what it ran will record what you typed into it, and key-format scanners will miss a plain password in a command line.

References

Frequently Asked Questions

How does a secret end up in .claude/settings.local.json?
When Claude Code asks to run a shell command and the developer picks Yes, and don't ask again, it saves an allow rule in .claude/settings.local.json. If the offered rule is the exact command, any password or token typed into that command is saved in plain text. Apiiro says it reproduced this with the latest models, Opus 5.5 and Fable 5.1.
Is deleting the file from the repository enough?
No. Apiiro says older versions of the file stay in git history and in forks, and it counted 734 secrets in earlier versions that no current copy holds. The recommended order is to rotate every password, token and key the file has ever held, then clean up the repository.
Do secret scanners catch these leaks?
Often they do not. Apiiro ran gitleaks and TruffleHog without verification over every copy. Of the 1,122 files with a secret, gitleaks flagged 564, TruffleHog flagged 643, and 215 were flagged by neither. The misses are mostly passwords typed inside commands, which look like ordinary words to scanners tuned for key formats.