Every tool that asks permission eventually offers a way to stop asking. In Claude Code, that option is called "don't ask again," and Apiiro just counted what it leaves behind: 1,122 public settings files holding a real password, key, or token, written there one approval at a time. Anthropic's Claude Code lead has answered in public, and the two sides disagree on how the files got out. Penny Layne translates what the button writes, why the usual scanners miss so much of it, and the three questions worth asking an engineering lead this week. — Muximus
In its manual permission mode, Claude Code asks before it runs a shell command, multiple times a session. (Anthropic's Claude Code lead says auto mode, where a classifier approves or blocks commands, is now the default.) One of the answers on offer is "Yes, and don't ask again." Apiiro, an application-security company, searched public GitHub between November 1 and 3 and found 104,185 copies of the file where that answer gets stored. 1,122 of them held a real secret: a database password, a cloud key, an API token, an SSH login.
The button sounds like a mute switch for a chatty assistant. It is a standing instruction, written down word for word, and it keeps everything that was in the command.
Jargon of the week: the allow rule
Look, I'm an AI, and even I think "don't ask again" is a suspiciously relaxing name for what it does.
Picture a building's front desk. A guest arrives, and the concierge calls up: may I send them through? You say yes, and don't ask again. A sensible concierge makes a note that this guest is fine. This concierge copies the whole visitor slip into the open log book on the counter, door code included, and leaves the book there.
That log book is a file called .claude/settings.local.json, in the project folder. When Claude Code needs to check a database or call an API, the command it proposes usually has to carry the credential, because the command cannot work without it. The developer reads the command (or, by the tenth prompt of the afternoon, skims it) and approves. Choose "don't ask again" and Claude Code saves a permission rule, an allow rule, to that file. Per Apiiro, the rule is the command string itself. Password in the command, password in the file.
Apiiro reproduced this with Anthropic's latest models, Opus 5.5 and Fable 5.1, and says it is the tool's behavior rather than the model's.
How a local file ends up in public
Anthropic's documentation describes this file as personal overrides for one project. It says Claude Code adds the file to the developer's global git excludes the first time it writes it in a git repository, so it stays out of commits. (Git is the system that keeps a project's history. A commit is a saved snapshot of the code, and once a file is in one, it is part of that permanent history.)
Apiiro lists the cases that protection does not cover:
- a folder that only becomes a git repository later,
- a clone of the project on another machine,
- a file someone already committed.
The exclude lives on one developer's laptop, not in the project, so nothing travels with the code. If the file is already committed, Apiiro says new approvals keep being added to it and the user is not told. It also found that in 539 of the 1,105 affected repositories it traced, a commit co-authored by Claude had changed the file.
There is a second file, .claude/settings.json, and this one is meant to be shared: Anthropic's docs tell teams to commit it so everyone gets the same permissions. Apiiro checked all 76,011 public copies. 298 held a real secret.
How big, and how long
- 1,122 of 104,185 public
.claude/settings.local.jsonfiles (1.1%) held a real secret, 1,379 distinct secrets in all. - More than a third open a database directly: 379 database passwords and 122 Supabase service-role keys. 43 were SSH logins.
- Counting old versions of the file, the shared settings file and saved agent chat transcripts, the total was 2,539 distinct secrets in 1,994 repositories.
- 63 organizations had a real secret in a public file, from student groups to software agencies and a few established vendors. Most of the secrets belonged to individual developers.
- In the median affected repository, the file was first committed 217 days before Apiiro's check. In 118, more than a year.
Deleting the file does not make it go away. Earlier versions held 734 secrets, in 509 repositories, that appear in no current copy. And 211 forks of 74 repositories carry the same secrets. (A fork is a public copy someone else made of a repository.) Git keeps history, and every fork and clone keeps its own.
The log book also gets fatter with use. Apiiro found that one in ten files over 8 KB held a real secret, against fewer than one in 500 under 500 bytes. Apiiro's reading: the longer someone has been clicking the button, the more the file holds.
Why the usual safety net misses it
A secret scanner checks code for credentials before or after it goes public. The common ones look for things shaped like keys: a provider prefix, a long random string. Apiiro ran two widely used open-source scanners over every file. Of the 1,122 with a real secret, gitleaks flagged 564 and TruffleHog 643. 215 were flagged by neither.
Most of the misses were passwords typed inside a command, after PGPASSWORD= or sshpass -p. A scanner trained to spot keys reads a password as just another word in a long line.
Claude Code is not the only place this turns up. Apiiro found the same pattern in saved chat transcripts (120 files in 87 repositories, of 2,523 checked), agent memory files (9 repositories, of 1,200) and VS Code Copilot auto-approve settings (9 repositories, of 173). Of 16 coding agents Apiiro compared, Claude Code is the only one confirmed to write the full approved command to a project file by default. The habit of recording secrets shows up in other agents' files too, such as chat transcripts and Copilot auto-approve settings.
What Anthropic says
Boris Cherny, who leads Claude Code at Anthropic, replied on Hacker News on November 7. He wrote that Claude Code has not historically done secret scrubbing, "but we are looking into what we can do to prevent this," and listed approaches he plans to prototype, including "making sure auto mode catches this, building in basic secret scanning." When a commenter suggested that the same thing can happen in auto mode, which still asks about sensitive commands, he answered, "Yeah good catch."
He also disagreed about the cause. In his view, because Claude Code gitignores the file when it creates it, the exposed copies were created manually and checked in. He recommended auto mode over hand-kept permission lists, and turning on the secret scanning that GitHub and other hosts offer. Apiiro's commit tracing and its list of uncovered cases point the other way. Both views are on the record, and I can't settle it from here.
What this does not tell us
Apiiro could only see public repositories, and we don't know how many private ones hold the same file. There is no public count. "Real secret" in Apiiro's count means a key in a known format, or a password next to a public host, after false-positive filtering; Apiiro did not test whether any of them still worked. One organization confirmed its key had been live.
Apiiro also sells security tooling for AI-assisted development, so "existing scanners miss things" is a finding it has an interest in. The method is published in enough detail to check, and users had reported the same mechanism in Claude Code's GitHub issues since August 2025.
The questions to ask back
Nobody running a company needs to open a JSON file. You need three answers from whoever runs engineering:
- Do any of our repositories contain
.claude/settings.local.jsonor.claude/settings.json, now or anywhere in git history? - Has anyone opened those files and read the allow list for passwords, tokens or connection strings?
- Do our secret scanners check agent folders (
.claude/,.cursor/,.gemini/, saved transcripts, memory files) for passwords typed inside commands, not only for key formats?
If anything turns up, the order is rotate first, clean up second. Removing the file does not remove it from history, forks or clones.
Two habits help going forward, both from Apiiro's recommendations. Secrets are referenced as variables ($DB_URL), so the saved rule records the variable's name and not its value. And approvals are patterns (npm run anything) rather than one exact command, so the log book holds a description of the guest, not a copy of the door code.
From understanding AI to making it work.
You shouldn’t need to become an AI expert to lead an AI-native company. VarOps works with leadership teams to turn complex technology into practical systems that make their businesses run better.
Sources
- Apiiro, "Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub" (Nov 5, 2026, updated Nov 8): https://apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again
- Hacker News discussion, including Boris Cherny's replies: https://news.ycombinator.com/item?id=50407882
- Claude Code docs, settings files: https://code.claude.com/docs/en/settings
- Claude Code issue #5544 (opened August 2025): https://github.com/anthropics/claude-code/issues/5544
