Claude Code’s ‘Don’t Ask Again’ Put Real Secrets in 1,122 Public GitHub Files, and 215 Escape Both Major Scanners

Apiiro downloaded every public copy of .claude/settings.local.json it could find between 1 and 3 November: 104,185 files in 103,617 GitHub repositories. Of those, 1,122 files, about 1.1%, held a credential the researchers classified as real.

The leak needs no model exploit. It needs a developer to click “Yes, and don’t ask again” on a Claude Code permission prompt. Claude Code saves the approved shell command as an allow rule in the project’s local settings file, and the rule keeps the command exactly as written, secret included.

Apiiro counted 1,379 distinct secrets in those files and 2,539 across every agent artifact it checked, in 1,994 repositories. It reported each organization case to its owner on 2 and 3 November, and one company confirmed its key had been live.

Quick answer: Apiiro found 1,122 public GitHub files containing real credentials saved by Claude Code’s “Yes, and don’t ask again” approval. The files held 1,379 distinct secrets, including 379 database passwords, 103 Supabase account tokens and 43 SSH logins, across 63 organizations. gitleaks flagged 564 of the 1,122 files and TruffleHog flagged 643, but 215 were flagged by neither because the secret was a password inside a command. Anthropic’s documentation confirms that the approval is stored as an allow rule in .claude/settings.local.json. The counts are Apiiro’s, not an independent audit, and no credential was tested.

How a permission prompt becomes a public secret

Claude Code asks before it runs a shell command. The prompt offers a standing approval, and the standing approval is written to .claude/settings.local.json as a permissions.allow entry. Anthropic’s settings documentation, updated on 7 November 2026, describes exactly this: the file is created the first time you give a standing approval, such as “Yes, and don’t ask again” for a Bash command.

The command string is the rule. If you ran PGPASSWORD=... psql -h db.example.com, that whole line is what gets saved, so the password is saved with it. Apiiro says it reproduced the behaviour with Opus 5.5 and with Fable 5.1, so this is a client behaviour rather than a model decision.

Anthropic does try to keep the file out of git. The docs say that the first time Claude Code writes the file in a repository, it adds **/.claude/settings.local.json to the developer’s global git excludes. That fails in three cases: a folder that becomes a repository later, a clone on another machine, and a copy committed before the exclude existed. The rule never goes into the repository’s own .gitignore.

The 1,122 number, and what sits behind it

The 1,122 files are 1.1% of the 104,185 public copies Apiiro downloaded. They held 636 provider-format keys and 743 passwords or tokens paired with a public host, and more than a third open a database directly: 379 database passwords and 122 Supabase service-role keys. Another 103 are Supabase account tokens, which control every project in an account.

The published cases are anonymized but specific: a database vendor’s own cloud API key with manage access and no expiry claim, a B2B startup’s production Azure Postgres password, a software agency’s Square production token, and the owner password for a medical-records app’s cloud Postgres database.

Size predicts risk. One in ten files over 8 KB held a real secret, against fewer than one in 500 under 500 bytes, and the median affected repository first committed the file 217 days before 2 November. Forks carry the problem: 211 forks of 74 repositories hold the same secrets.

Earlier versions of the file hold 734 real secrets in 509 repositories. Removing a tracked file without rotating the credential leaves the secret in every clone and fork.

Scanners miss the passwords, not the keys

Apiiro ran gitleaks and TruffleHog over all 104,185 files. gitleaks flagged 564 of the 1,122 files and TruffleHog 643, but neither flagged 215 of them, about 19%.

The gap is structural. Both tools look for provider prefixes and long random strings, while a password typed after PGPASSWORD=, sshpass -p or a bearer header in a curl call is an ordinary word in a command line. The same blind spot applies to agent transcripts, memory files and handoff notes.

Detector	Files flagged	Share of 1,122	What it looks for
gitleaks	564	50.3%	Provider key formats and high-entropy strings
TruffleHog	643	57.3%	Credential patterns, with and without verification
At least one of the two	907	80.8%	Union of the two rule sets
Neither	215	19.2%	Passwords embedded in command lines

Source: Apiiro, 5 November 2026. Both tools ran without credential verification.

It is not only one file

The allowlist is the clearest case, but the same pattern appears in other files agents write and developers commit. Apiiro checked 76,011 shared .claude/settings.json files and found 298 with a real secret, plus 120 of 2,523 agent chat transcripts, 9 repositories among 1,200 memory files, 33 of 2,095 handoff notes and 9 repositories among 173 VS Code Copilot auto-approve files.

A third of the handoff notes with a secret were written by the agent itself. Outside GitHub, 126 of 31,053 public Hugging Face Spaces hold the local settings file. Apiiro compared 16 coding agents and says Claude Code is the only one confirmed to write the full approved command to a project file by default.

Anthropic has had the report since August 2025

The mechanism is not new to Anthropic’s issue tracker. Claude Code users filed GitHub issues #5544, #11982, #13106 and #91270 describing plaintext credentials in settings.local.json. Apiiro says none received a reply and three were closed automatically; issue #5544 is now closed as not planned.

Anthropic’s docs describe the global exclude as the protection, and it does protect the normal case. It is not a fix for the cases Apiiro counted, and the burden stays on the developer when the file is created by hand.

This is a client design problem, not a model capability problem. A smarter model does not help if the approval layer writes a production password to a file that git can see. It sits awkwardly beside the Postman plugins that installed themselves into Claude Code this month.

What it means for Indian developers

India’s IT services and startup ecosystem is close to Apiiro’s sample: agencies, B2B startups and services firms running client infrastructure. A leaked production database password in a public repository is a client breach, not just a developer mistake.

The response order is rotate, then clean. Removing the file does not clear git history, forks or clones, so the credential must be treated as compromised from the moment it was committed. Under the DPDP Act 2023 and CERT-In’s incident reporting directions, a live database credential can turn into a notifiable incident.

The cheap fixes are unglamorous. Reference secrets as environment variables, so the saved rule records $DB_URL rather than the value. Approve patterns such as Bash(npm run:*) instead of literal commands. Add agent folders to pre-commit and CI scanning, and configure the scanner to catch PGPASSWORD=, sshpass -p and bearer headers.

Any approval record is a log of what the agent ran, and logs collect secrets. Treat the agent’s state directory like .env.

Confirmed versus not confirmed

Claim	Status	Evidence
Claude Code saves a standing Bash approval as an allow rule in .claude/settings.local.json	Confirmed	Anthropic settings docs, 7 November 2026
The saved rule contains the full command, including embedded secrets	Confirmed by reproduction and user reports	Apiiro; GitHub issue #5544
1,122 of 104,185 public settings files hold a real secret	Apiiro measurement	Apiiro, 5 November 2026; not independently replicated
63 organizations are affected, and one confirmed a live key	Apiiro claim	Apiiro disclosure section
215 of the 1,122 files escape both gitleaks and TruffleHog	Apiiro measurement	Apiiro, tools run without verification
Anthropic was told in August 2025 and did not reply	Apiiro claim, consistent with public issues	Public GitHub issues; no Anthropic statement found
Every counted secret is valid and was used	Not confirmed	Apiiro did not use or test any credential
The problem is fixed in current Claude Code	Not confirmed	No fix announced; docs still describe the behaviour

FAQ

What exactly does “don’t ask again” save in Claude Code?

The approved shell command, stored as a permissions.allow rule in .claude/settings.local.json. Any secret in that command is stored in plain text.

Are my secrets exposed if I never committed the file?

They are not public on GitHub, but they are still in plain text on the machine. Malware that harvests developer credentials can read the file, and the Shai-Hulud npm worm ran TruffleHog over victims’ disks in 2025.

Does deleting the file fix the leak?

No. Earlier versions remain in git history, and every fork or clone can carry them. Rotate the credential first, then untrack the file and add it to the repository’s own .gitignore.

Which secret scanners catch this?

gitleaks and TruffleHog catch many provider-format keys, but both missed 215 of the 1,122 files. Add rules for passwords inside commands and scan git history too.

Sources

Apiiro, Coding Agents Are Leaking Your Secrets to GitHub, 5 November 2026.

Anthropic, Settings files and precedence, updated 7 November 2026.

GitHub, Issue #5544: approved bash commands containing credentials are stored as is, opened 11 August 2025.

Hacker News, discussion of the Apiiro report, 8 November 2026.

Earlier coverage: 1,465 exposed ARTEX consoles, OpenAI’s agents and 948 Linux root flaws, and Postman’s plugins inside Claude Code.