Claude Code secrets leak via “Yes, and don’t ask again”

On November 5, Apiiro researchers Shmulik Cohen and Matan Giladi published a report on a Claude Code secrets leak to GitHub. In 104,185 public copies of the .claude/settings.local.json file they found 1,122 files with at least one secret, adding up to 1,379 distinct passwords, API keys and tokens.

How does the Claude Code secrets leak work?

When Claude Code asks for permission to run a terminal command, we can pick “Yes, and don’t ask again”. According to the Claude Code documentation, that approval is saved as an allow rule in the project’s .claude/settings.local.json file.

The problem is that the rule stores the entire approved command, including whatever we typed into it. If the command had a password in it, say PGPASSWORD=… psql … or a curl with an API key in a header, that password lands in the file in plain text.

Interestingly, this isn’t a new discovery. In August 2025 someone reported exactly this problem in issue #5544 (with examples of API keys and Jira tokens). A bot closed it on January 3, 2026, after 60 days of inactivity, as “not planned”, with no fix.

If the file is local, how did it end up on GitHub?

The file is meant to be private. The first time Claude Code writes it, it adds **/.claude/settings.local.json to git’s global excludes file so it stays out of commits (that’s how the documentation describes it).

That protection has a few holes, though:

1. The global exclude works only on one machine and doesn’t travel with the repository.
2. If we created the file by hand, Claude Code doesn’t exclude it, and we have to add it to .gitignore ourselves.
3. Ignore rules don’t apply to files git already tracks, so a file committed once keeps going into later commits.
4. Deleting the file from the repository doesn’t remove it from history or from forks.

According to iTWire, in 539 of the 1,105 repositories traced, the file was changed by commits co-authored by Claude.

How big is it?

The numbers from the report (data collected from public GitHub on November 1–3):

1. 104,185 public copies of settings.local.json, of which 1,122 (about 1.1%) contained at least one secret.
2. Those files held 1,379 distinct values.
3. Counting git history, the shared .claude/settings.json file and saved agent conversations, the total comes to 2,539 secrets in 1,994 repositories.
4. Apiiro notified companies on November 2 and 3, and one of them confirmed the exposed key was live.

One caveat: Apiiro didn’t check whether the credentials it found actually work. It filtered candidates with false-positive filters and a language model’s assessment, so some of them may already have been stale.

Why is everyone talking about it?

On Saturday evening the report hit the front page of Hacker News. The point of “don’t ask again” is to stop the agent from asking about the same thing over and over, so it’s easy to forget what actually got saved.

It’s also another example of secrets leaking today not only from application code but from agent config files too (much like the OpenCode leak). So far, media coverage contains no response from Anthropic.

What should we watch out for?

1. First revoke and rotate every password or key that was ever in this file in a public repository. Only then clean up the history.
2. Check whether the file is tracked: git ls-files .claude. If it is, stop tracking it (git rm --cached .claude/settings.local.json) and add it to .gitignore in the repository itself, not just globally.
3. Also review the history (git log --all -- .claude/settings.local.json), the shared .claude/settings.json and saved agent conversations.
4. Don’t type passwords directly into commands. It’s better to pass them through environment variables or a secrets manager, and to use patterns in allow rules, such as Bash(npm run test *) from the documentation.

I write more about keeping API keys away from agents in the AI agent security guide, and the basics of the tool are in the Claude Code tutorial.

FAQ

Does Claude Code send my passwords to GitHub by itself?

No. The settings.local.json file stays on our disk. The leak only happens when the file makes it into a commit and a public repository.

How do I check whether my settings.local.json is in the repository?

Run git ls-files .claude in the project directory. If settings.local.json is on the list, git is tracking it. It’s also worth opening the file itself and looking for passwords, tokens and keys in the allow rules.

Is it enough to delete the file from the repository?

No. The file stays in git history and in forks, which is why the most important step is revoking and rotating the exposed credentials.