Claude Code's 'don't ask again' rules put secrets in 1,122 public GitHub files, Apiiro says

When Claude Code asks to run a shell command and you pick “Yes, and don’t ask again”, it saves an allow rule in .claude/settings.local.json in the project, its settings documentation says. Security company Apiiro has looked at what ends up in those files on public GitHub, and found passwords and API keys.

What Apiiro found

According to The Hacker News and iTWire, Apiiro researchers Shmulik Cohen and Matan Giladi published their findings on 5 November. They collected public data from 1 to 3 November and found 104,185 copies of the file in 103,617 repositories. They classed 1,122 copies, about 1.1%, as holding at least one secret, 1,379 distinct values in all. Counting older versions in git history, the shared .claude/settings.json and saved agent transcripts, the total was 2,539 secrets across 1,994 repositories.

The mechanism is simple. A saved rule is sometimes a pattern, such as npm test *, and sometimes one exact command. If the exact command had a password typed into it, after PGPASSWORD=, mysql -p or sshpass -p, the password is saved too, in plain text. Apiiro says more than a third of the secrets opened a database directly, including 379 database passwords, plus 43 SSH logins, 42 GitHub, GitLab and npm tokens and 23 AWS keys. Gitleaks and TruffleHog together missed 215 of the files, because a password inside a command line does not look like a key format.

Apiiro did not try the credentials, so this is an exposure risk, not a proven breach. It says it notified affected organisations on 2 and 3 November and that one confirmed its key had been live. We could not open Apiiro’s own write-up (the site blocked our fetch), so the figures here are as reported by those two outlets.

Why the file gets committed

Claude Code does try to keep the file private. The docs say that the first time it writes the file in a git repository, it adds **/.claude/settings.local.json to your global git excludes. That protection lives in one user’s git config on one machine. It does not cover a file that was already committed, a clone on another computer, or a file you created by hand, and Claude Code does not add the file to the project’s own .gitignore. Git ignore rules never apply to files that are already tracked.

What to do

Apiiro’s steps, as reported:

1. Search your organisation for .claude/settings.local.json and .claude/settings.json, including git history where the files were later deleted.
2. Rotate every password, token and key those files ever held. Do this before cleaning up, because deleting the file does not remove it from history, forks or clones.
3. Run git rm --cached .claude/settings.local.json and add the path to the repository’s own .gitignore.
4. Open your local copy, even if it was never committed, and delete any rule that contains a secret.
5. Keep secrets out of commands: use variables such as $DB_URL from a secrets manager, so a saved rule stores the name, not the value.
6. Approve patterns such as Bash(npm run:*) rather than single literal commands.

Why this matters

Agent approval files are config that quietly records what you typed, and secret scanners tuned for key formats miss passwords inside commands. Add .claude/settings.local.json to every repo’s .gitignore now, and treat any value that ever passed through a saved command as exposed. Our earlier guide to how secrets leak in agent workflows covers the other common paths, and the OpenCode Console breach shows why rotation comes first.