Claude Code Secrets Leak to GitHub via 'Don't Ask Again' Button
Apiiro found 2,539 secrets in 1,994 public GitHub repos, saved by Claude Code's 'don't ask again' option. Here's why scanners missed them and how to fix it.
Published 5 min read

Thousands of Claude Code secrets, including database passwords, cloud keys and SSH logins, are sitting in public GitHub repositories. Security firm Apiiro found 2,539 distinct secrets across 1,994 repositories, and the cause is a small convenience button in Anthropic's AI coding assistant: "Yes, and don't ask again."
Apiiro researchers Shmulik Cohen and Matan Giladi published the study on Nov. 5 and updated it on Nov. 8, and Ars Technica picked it up on Nov. 9. The important caveat up front: Apiiro did not test whether the credentials still work, and nobody has reported them being abused. One company it notified did confirm its exposed key had been live.

How do Claude Code secrets end up on GitHub?
Claude Code asks for permission before it runs most shell commands. If you pick "Yes, and don't ask again," it saves an allow rule in a file called .claude/settings.local.json inside your project folder. Sometimes that rule is a pattern, but often it is the exact command, word for word.
So if the command carried a password, the password gets saved too, in plain text. Think of a psql connection string, a PGPASSWORD= value, sshpass -p, mysql -p or a token inside a curl authorization header.
Anthropic does try to protect that file. The first time Claude Code writes it, it adds the file to the user's global git excludes on that computer. A .gitignore file, by comparison, is the list inside a project that tells Git which files never to upload, and it travels with the code. The global exclude does not. It does nothing on another machine or container, in a folder that becomes a repository later, or for a file Git is already tracking. Apiiro also found that in 539 of 1,105 traced repositories with secrets, a commit listing Claude as co author had changed the file.
How big is the leak?
Apiiro searched public GitHub between Nov. 1 and Nov. 3, 2026. Here is what it counted:
| What Apiiro counted | Number |
|---|---|
| Public copies of settings.local.json | 104,185 in 103,617 repos |
| Copies holding at least one secret | 1,122 (about 1.1%) |
| Distinct secrets in those copies | 1,379 |
| Extra secrets found only in git history | 734 across 509 repos |
| Total incl. history, shared settings and transcripts | 2,539 across 1,994 repos |
| Organizations affected | 63, mostly software companies |
More than a third of the secrets open a database directly, including 379 database passwords and 122 Supabase service role keys. The Hacker News also lists 43 SSH logins for public servers, 42 GitHub, GitLab and npm tokens and 23 AWS keys. Most of the affected accounts belong to individual developers.
Why did secret scanners miss them?
A secret scanner is a tool that combs code for things that look like passwords or API keys before they go public. The two popular open source options, gitleaks and TruffleHog, caught roughly 50% and 57% of the risky files. Even used together, they missed 215 files, about 19%.
The reason is simple. Scanners hunt for known key formats, like a string that starts the way an AWS key does. A plain password typed after -p in a command just looks like ordinary text.
What did Anthropic say?
Boris Cherny, who leads Claude Code, said on Hacker News that the team is "looking into what we can do to prevent this." He added that these files should basically never be checked in, and that the cases seemed to come up when "the files were manually created and checked in."
Cherny suggested using auto mode instead of "manually maintaining finicky allow/deny lists." When another user pointed out that auto mode can still save sensitive commands, he called it a "good catch." He also recommended secret scanners and said the team is considering building secret scanning into Claude Code itself. According to Ars Technica, the same behavior was flagged in a Claude Code bug report back in August 2025, but those reports were closed after 60 days of inactivity.
What should developers do now?
Deleting the file is not enough, because the secret stays in git history, forks and local clones. Start with the credentials, then clean up:
- Rotate every password, token and key that has ever been in that file.
- Remove plain text secrets from your allow rules.
- Add
.claude/settings.local.jsonto the project's own .gitignore, not just your machine's. - Pass credentials through environment variables tied to a secrets manager instead of typing them into commands.
- Treat
.claude,.cursorand.geminifolders and agent memory files as sensitive as a.envfile. - Turn on GitHub secret scanning for your repositories.
Apiiro says the problem is not unique to Claude Code. It also found secrets in saved agent chat transcripts, memory files and handoff notes. Note that Apiiro sells application security products, so it has a stake in the topic, but the mechanism matches Anthropic's own documentation.
Our take: convenience is the new attack surface
Nothing here was hacked. Developers clicked a time saving button, and the tool quietly turned a password into a config file. That is a design problem more than a user error, and it fits a wider pattern: AI agents now touch the same folders, keys and servers we do, from a backdoored Claude Code extension to prompt injection and the Fireworks AI breach. The relative test is easy: if you would not paste a password into a public README, do not approve a command that contains one. Until Anthropic ships a fix, treat every "don't ask again" as a line you may one day publish.