Claude Code secrets leak: check your settings.local.json now

The Claude Code secrets leak is not a breach at Anthropic. It comes from a convenience feature: when you choose "Yes, and don't ask again" for a shell command, Claude Code saves that exact command to a settings file, and if the command contained a password or API key, the secret is saved with it. When that file ends up in a public GitHub repository, so does the secret.

Security firm Apiiro published the research on November 5, 2026, and it has been covered widely since. This article explains what was found, who is affected, and how to check and fix your own projects in about ten minutes.

What is the Claude Code secrets leak?

Claude Code asks before it runs most shell commands. One of the answers is "Yes, and don't ask again", which saves a standing approval so you are not asked about the same command again. According to the Claude Code settings documentation (opens in a new tab), that approval is written as an allow rule to .claude/settings.local.json in your project.

The rule can be a pattern, such as npm run *, or an exact command. If you approved an exact command like a database login with the password typed inline, the password is now stored in plain text in that file. As iTnews reports (opens in a new tab), Apiiro reproduced the behavior and described it as a property of the tool, not of the underlying model.

What did Apiiro find on GitHub?

Apiiro searched public GitHub for copies of the file. The figures below come from The Hacker News (opens in a new tab) and Qodo (opens in a new tab), which both report the research.

Two details matter for anyone cleaning up. First, the common secret scanners missed many of the files: Gitleaks flagged 564 of the 1,122 and TruffleHog flagged 643, and 215 were flagged by neither, mostly because a password typed into a command does not look like a standard key. Second, the files tend to stay put. In half of the affected repositories, the file had been on the default branch for at least 217 days, according to Qodo.

Apiiro did not test whether the secrets still worked, so treat every one as live until it is rotated. Qodo also reports that of 16 coding agents Apiiro compared, Claude Code was the only one confirmed to save the full approved command in a project file by default.

Why did a local file end up on GitHub?

The file is meant to stay on your machine. The documentation says Claude Code adds it to your global git excludes the first time it writes the file in a git repository, and that if you create the file by hand, you should add it to .gitignore yourself.

The catch is that this protection lives in one developer's git configuration on one computer, not in the project. Notebookcheck (opens in a new tab) and Qodo describe the ways it slips:

• the folder was turned into a git repository after the file was written,
• the file was created by hand or copied from another project,
• the file was written on a second machine whose git settings do not exclude it.

Qodo adds that in 539 of the affected repositories, a commit with Claude listed as co-author changed the file, which suggests that some of these commits were made with an agent in the loop.

What has Anthropic said?

Boris Cherny, head of Claude Code, responded publicly. iTnews quotes him as saying "Historically Claude Code has not done secret scrubbing", and Notebookcheck reports that the team is considering built-in secret scanning and changes to how the tool handles command permissions. Qodo quotes him as saying the file "is meant to stay local" and "is not a file you should check into source control".

As of November 11, 2026, no fix has been released. A related bug report from August 2025, issue 5544 (opens in a new tab), was closed as "not planned" in January 2026.

How to check your repositories for the Claude Code leak

You do not need special tools for a first check. In each project that has used Claude Code, run this from the repository root:

git ls-files | grep "settings.local.json"
git log --all --oneline -- .claude/settings.local.json

The first command shows whether the file is tracked now. The second shows whether it was ever committed, even if it has since been deleted. Then open the file itself and read through the allow list for anything that looks like a password, token, connection string, or key. Do the same for the shared .claude/settings.json and any saved agent transcripts in the repository.

What to do if your secrets were exposed

Work in this order, which follows the advice Apiiro gave in its research:

1. Rotate first. Change every password and key the file has ever held, including old versions in git history. Deleting the file does not remove it from history or from forks, as Notebookcheck points out, so treat anything that was committed as compromised.
2. Untrack the file. Remove it from the repository with git rm --cached .claude/settings.local.json and add .claude/settings.local.json to the project's own .gitignore, so the protection travels with the project.
3. Clean the rules. Delete any allow rule that contains a secret.
4. Keep secrets out of commands. Reference secrets through environment variables or a secrets manager, so the command Claude Code sees contains a variable name, not the value.
5. Approve patterns, not literal commands. The permissions documentation (opens in a new tab) explains rules such as Bash(npm run *), which approve a family of safe commands without recording the details of each one.

If you rotate keys for AI providers or cloud accounts, our guide to protecting AI API keys covers spend limits, usage alerts, and keeping one key per job, so a leak like this costs less next time.

What this means for teams using AI coding tools

The lesson reaches beyond one file. When an agent works in a repository, its settings, permission rules, and transcripts sit next to your code and deserve the same review before they are committed. A simple team rule helps: agent configuration that should be shared goes in the committed .claude/settings.json, personal approvals stay local and ignored by the project, and nobody types a secret into a command that an agent will see. It is the same least-privilege thinking we describe in roles and permissions in business software.

Frequently asked questions

Is this the same as the Claude Code source code leak?

No. Earlier in 2026, Anthropic accidentally published the source code of Claude Code version 2.1.88 in its npm package through a source map file, as AlternativeTo reported (opens in a new tab). That exposed Anthropic's own code. The November 2026 issue exposes users' secrets through their own repositories.

Was Anthropic hacked?

No. Nothing in the research describes a breach of Anthropic's systems. The secrets were exposed because a local settings file containing them was pushed to public repositories.

Does "don't ask again" always save secrets?

Only if the approved command contained a secret. Approving npm test saves nothing sensitive. Approving a command with a password typed inline saves that password in plain text.

Do private repositories need checking too?

Yes. A private repository is not exposed to the public, but anyone with access, any connected tool, and any future fork can read the file. Rotating a secret that sat in a shared repository is the safe choice.

Will Anthropic fix it?

Anthropic has said it is considering built-in secret scanning and changes to how command permissions are handled, but as of November 11, 2026, it has not shipped a fix. Until then, the steps above are the protection.

The ten-minute check

Run the two git commands in every project that has used Claude Code, read the file, and rotate anything that should not be there. Then add the file to each project's .gitignore. It is a small job, and it closes a gap that common secret scanners often miss.