This affects any developer or company using Claude Code on their projects, and the fix is clear. I'll update this story if new details come out.

◢What happened

Sometimes the rule is a pattern, such as npm test *. Sometimes it is the exact command you approved. Ask it to check why login fails on staging or to run a migration, and the command it proposes carries the database password, because it can't work without it. Approve it for good and that password is stored in plain text. According to Apiiro¹, this is how the tool behaves, not the model: they reproduced it with Opus 5.5 and Fable 5.1, Anthropic's latest models.

◢Why does a local file end up on GitHub?

The catch is that this protection lives in one person's git settings on one computer. It isn't added to the project's own .gitignore, so it doesn't travel with the project, and it doesn't cover a folder that becomes a repository later, a clone on another machine or a file that was already committed. Keep in mind too that .gitignore doesn't affect files git already tracks: "local" is only a name. Apiiro¹ found that in 539 of the 1,105 repositories it traced, a commit listing Claude as co-author changed the file. That doesn't prove the assistant added every credential, but it does show it often makes the commit.

◢What we know

These are the figures from Apiiro's report¹, based on data collected from November 1 to 3:

• ▹Apiiro¹ found 104,185 public copies of the file in 103,617 repositories. About 1.1%, or 1,122 copies, hold at least one real secret, with 1,379 different secrets in total.
• ▹More than a third open a database directly: 379 database passwords and 122 Supabase service-role keys. There are also 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys.
• ▹63 organizations are affected, mostly software companies. The cases include a database vendor's own admin cloud key, a production Azure Postgres password and the owner password of a medical-records database.
• ▹Older versions of the file, which stay in git history even after it is deleted, hold 734 more secrets in 509 repositories. Adding the shared .claude/settings.json file and agent chat logs committed to repositories, the total reaches 2,539 secrets across 1,994 repositories.
• ▹Common secret scanners miss many of them. Gitleaks flagged 564 of the 1,122 files and TruffleHog 643, and 215 were flagged by neither. It is usually a password typed inside a command, after PGPASSWORD= or sshpass -p, which looks like an ordinary word.

◢What we don't know

This is an exposure risk, not a proven breach. Apiiro¹ did not use any credential or contact any host, so "real secret" means it matches a known key format or points at a public host, not that it works. It notified the organizations on November 2 and 3, and only one has confirmed its key was live. Nor do we know whether anyone has already used any of these secrets.

Anthropic has not responded publicly so far. According to Apiiro, users have reported this behavior in the Claude Code repository since August 2025, in several issues that got no reply, three of them closed automatically as inactive or duplicate. It's also worth knowing that Apiiro sells security products for applications and AI agents.

◢What to do if you use Claude Code

Order matters. Rotate first and clean up second, because deleting the file doesn't remove it from git history or from forks.

1. ▹Search the repositories in your account or organization for .claude/settings.local.json and .claude/settings.json, including git history where the file is gone.
2. ▹Rotate every password, token and key that has appeared in those files, even if you think nobody saw it.
3. ▹Stop tracking the local file with git rm --cached .claude/settings.local.json and add it to the project's .gitignore, so the protection travels with the repository.
4. ▹Open the file on your own machine, even if you never pushed it, and delete any rule that contains a secret. It can end up in an npm package, a Docker image, a zip file or a synced folder, and malware that steals credentials from developer machines already looks for files like this.
5. ▹Keep secrets out of commands. Use variables such as $DB_URL backed by a secrets manager, so the rule stores the variable name rather than the value. Careful: writing DB_PASS=something command on the same line still puts the password in the command.
6. ▹When you approve something permanently, prefer a command pattern over an exact command.

If you run security for a team, treat coding agent folders (.claude/, .cursor/, .gemini/) the way you treat a .env file, add .claude/settings.local.json to your organization's .gitignore templates, and make sure your secret scanner also looks for passwords inside commands and checks git history.

◢The takeaway

Coding assistants work with the same permissions and the same secrets you do, and they store things in places we rarely look. A convenience button like "don't ask again" ends up creating a file full of credentials that nobody reviews.

I've written before about stolen AI API keys and AI agents with too many permissions: this case brings both problems together. If your team is starting to use these tools and you want it done with good judgment, that's part of what I cover in my cybersecurity and AI training.