Claude Code's "don't ask again" button left real passwords in 1,122 public GitHub files

If you use Claude Code and you ever clicked "Yes, and don't ask again" on a command that included a password, that password is now written in plain text in a file in your project. And if that file was pushed to GitHub, it's public. The security firm Apiiro published a study on November 5, 2026 that measured the size of the problem: out of 104,185 public copies of .claude/settings.local.json on GitHub, 1,122 contain at least one real secret. There are production database passwords, cloud keys, and root SSH credentials. If you code with agents, check this today.

How it happens

The mechanism isn't a hack or a model bug. It's how the tool works, and it's in its official documentation. When Claude Code asks your permission to run a terminal command and you choose "Yes, and don't ask again," it saves that permission as an allow rule in .claude/settings.local.json, inside the project folder. According to Apiiro, the rule is the literal text of the command. If the command was PGPASSWORD=... psql -h ... or a curl with an Authorization: Bearer ... header, the password or token gets copied as is.

And the command almost always carries the secret. You ask the agent to check why login is failing on staging or to run a migration, and it grabs the connection string from your config file because it can't do anything without it. Apiiro describes something we've all lived through: after the tenth interruption in a session nobody reads the whole command anymore, and the password is just one word lost in a very long line.

The researchers say they reproduced it with recent Anthropic models, Opus 5.5 among them, because the behavior comes from Claude Code and not from the model. Of the 16 coding agents they compared against their documentation, Claude Code is the only one they confirmed writes the full approved command to a project file by default.

Diagrama: cómo una contraseña pasa de un comando aprobado en Claude Code a .claude/settings.local.json y de ahí a un repositorio público, con los pasos para revisarlo y corregirlo

What about gitignore?

Here's the subtle part. Anthropic's documentation says that the first time Claude Code writes that file inside a git repository that doesn't ignore it, it adds **/.claude/settings.local.json to your global git excludes, that is, your machine's ignore file, not the project's .gitignore. The same page clarifies that if you created the file by hand, you have to ignore it yourself.

Apiiro acknowledges that this protection covers the common case, but points out the gaps: it doesn't cover a folder that became a repo later, a clone of the project on another machine, or a file that was already in a commit. Since the rule never makes it into the repo's .gitignore, nothing travels with the project to protect it. One uncomfortable fact: in 539 of the 1,105 repos with a real secret that they tracked, a commit co-authored by Claude modified that file.

The numbers

Apiiro ran read-only searches on GitHub between November 1 and 3, 2026 and downloaded every file. Here's what they found:

104,185 public copies of .claude/settings.local.json across 103,617 repositories.
1,122 files (1.1%) with at least one real secret, adding up to 1,379 distinct secrets: 636 keys in provider format and 743 passwords or tokens next to a public host.
More than a third open a database directly: 379 database passwords and 122 Supabase service-role keys. There are also 103 Supabase account tokens, 43 SSH credentials, 42 GitHub, GitLab, and npm tokens, 23 AWS keys, and 6 private keys.
63 organizations affected, from student groups to a database provider with its own cloud key with admin permissions, a startup with its production Postgres password on Azure, and an IT company with the owner password for the database of a medical records app. One company confirmed its key was live.
Counting git history, the .claude/settings.json that teams deliberately share (298 files with secrets out of 76,011 reviewed), and transcripts of chats with agents, the total rises to 2,539 secrets in 1,994 repositories.

Gráfica de barras: tipos de secretos encontrados en los 1,122 archivos .claude/settings.local.json públicos con secretos reales, encabezados por 379 contraseñas de bases de datos

Two more data points say a lot. Large files concentrate the risk: one in ten files over 8 KB has a secret, versus fewer than one in 500 of those under 500 bytes. The longer you go approving without reading, the more piles up. And deleting the file isn't enough: earlier versions in the history hold 734 secrets that no longer appear in any current copy, and 211 forks of 74 repos carry the same secrets.

Mind a limit that Apiiro itself flags: "real secret" means the value has the format of a known provider or points to a public host, not that it still works. They didn't use or test any credentials.

Why scanners don't see it

This part matters to anyone who relies on secret scanning in their CI. Apiiro ran gitleaks and TruffleHog over all 104,185 files. Of the 1,122 with a real secret, gitleaks flagged 564 and TruffleHog 643, and 215 weren't flagged by either one. The reason: those tools look for key formats (a provider prefix and a long random string). A password written after PGPASSWORD=, sshpass -p, or mysql -p is just an ordinary word inside an ordinary command, and they almost always miss it.

What Anthropic says

Apiiro says it shared the research with Anthropic before publishing. Once it was out, Boris Cherny, who leads Claude Code, wrote on Hacker News that the tool "has historically not done secret scrubbing" and that they're looking at what they can do to prevent it. In that same comment he argued that the file is "meant to stay local," that it's ignored automatically when Claude creates it, and that, in these cases, the files were created by hand and pushed. He recommended using auto mode instead of maintaining allowlists and turning on your git provider's secret scanning.

The problem isn't new. Claude Code users have been reporting it since August 2025: in issue #5544 someone described exactly this behavior, with steps to reproduce it. That report was closed on its own for inactivity in January 2026, with no response from the team.

What to do

These recommendations come from Apiiro and the Claude Code documentation. I haven't tested them on a repo of my own.

Look for the file in your repos and in your GitHub organization: .claude/settings.local.json and also .claude/settings.json.
Check the history even if it's not there today: git log --all --oneline -- .claude/settings.local.json. If the history has it, so do the forks and the clones.
Remove it from the repo with git rm --cached .claude/settings.local.json and add it to the project's .gitignore, not just the global one.
Rotate first, clean up later. Every credential that was ever in that file gets changed. Deleting the file doesn't make it disappear from the internet.
Open the file even if you never pushed it and delete every allow rule that carries a password, token, or key. Malware like the npm Shai-Hulud worm was already hunting for secrets on developers' disks, according to the same research.
Change the habit: pass secrets as variables ($DB_URL) from your secrets manager, so the rule stores the variable and not the value, and approve patterns like Bash(npm run:*) instead of literal commands.
If you handle security on a team: treat .claude/, .cursor/, .gemini/, and agent memory files the same as a .env, and configure your scanner to detect passwords inside commands.

My take

Both sides have a point. Anthropic does try to keep the file from being pushed, and nobody publishes a key on purpose. But the design stores the secret in plain text inside the project folder, and protecting it depends on an exclusion that lives on a single machine. That leaves too much room for human carelessness, and there are 1,122 public files that prove it. Until a real fix ships, the best defense is the same old one: secrets live in variables, not in commands.