Approved Once, Leaked Everywhere: Claude Code's "Don't Ask Again" File Put 2,539 Secrets on GitHub

2026-11-07 Agent & Supply Chain Security by al-ice.ai Editorial

Passwords and API keys that developers typed into commands they approved in Claude Code are sitting in public GitHub repositories, readable by anyone. Software security company Apiiro reported on 6 November 2026 that 1,122 public copies of Claude Code's project settings file hold at least one secret, and The Hacker News covered the findings on 7 November. The mechanism is the "Yes, and don't ask again" approval option: when a user picks it, the assistant saves the command word-for-word — secret included — in plaintext in .claude/settings.local.json inside the project. Apiiro's sweep found 104,185 copies of that file across 103,617 public repositories; about 1.1% of them hold at least one secret, totalling 1,379 distinct secrets in current copies. Counting older file versions, forks, the shared settings.json, and saved agent chat logs, the total reaches 2,539 secrets across 1,994 repositories. Apiiro did not test whether any of the secrets still work — but one company the researchers notified earlier in the week confirmed its key had been live.

How a secret lands in the file

By default Claude Code asks before running most shell commands. Choosing "Yes, and don't ask again" writes an allow rule to .claude/settings.local.json so matching commands run without prompting in later sessions. Sometimes the rule is a pattern such as npm test *; sometimes it is one exact command — and when it is exact, any password or token typed into it is persisted too, in plaintext. The researchers reproduced the behaviour on the latest models. The cruel detail is that Claude Code's own safeguard does not travel: the first time it writes the file inside a git repository, it adds the filename to the user's global git excludes on that one machine, per its settings documentation. That gitignore entry stays in one developer's git configuration on one computer. It does nothing for a file that was already committed — and Claude Code never adds the file to the project's own .gitignore, so the protection is not inherited by anyone who clones the repo. In 539 of the 1,105 repositories the researchers traced, a commit listing Claude as a co-author had touched the file, which they read as evidence that Claude often commits the file itself.

What the 1,122 files contain

A value counted as a secret when it matched a known key format, or when a password or token sat beside the address of a public server — with an AI reviewer required to agree. More than a third of the secrets open a database directly, including 379 database passwords. The remainder include 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. Among the file owners are 63 organizations, mostly software companies of all sizes, and the strongest cases Apiiro cites are a database vendor's own admin-level cloud key and the owner password of a medical-records database. As of Monday 2 November, every file with a secret was still on its repository's default branch, and in half of those repositories it had been sitting there for at least 217 days. Deletion does not undo the leak: older versions of the file hold 734 more secrets across 509 repositories that appear in no current copy, usually because the file was later deleted, and 211 forks of 74 repositories carry the same secrets as their originals. Secrets also sit in 298 of 76,011 copies of the shared .claude/settings.json — the file teams commit on purpose — mostly inside allow rules. Of 16 coding agents whose documentation the researchers compared, Claude Code is the only one confirmed to save the full approved command in a project file by default.

Scanners miss the passwords inside commands

The researchers ran gitleaks and TruffleHog over every copy, without the tools' verification step. Of the 1,122 files holding a secret, gitleaks flagged 564 and TruffleHog 643 — and neither flagged 215. The misses are overwhelmingly passwords typed inside commands: scanners look for known key formats, and a password after PGPASSWORD=, sshpass -p, or mysql -p looks like an ordinary word on an ordinary command line. Copies that never reach GitHub still matter — the file is plain JSON in the project folder and can also end up inside an npm package, a Docker image, a zip archive, or a synced folder — and there is precedent for malware hunting exactly this material: the Shai-Hulud worm ran the TruffleHog scanner over infected machines in September 2025, and the scanner flagged more than half of the files as secret. This is the same lesson as the MCP configuration secrets sprawl we covered in October: agent tooling keeps inventing new files that function as .env files without being treated as such. And the exposure pairs grimly with the theft side — Aoki and WardenStealer already harvest AI coding credentials from developer machines, so a plaintext secret in a synced or published settings file is exposed at both ends.

Users reported it first; the issue is closed

Claude Code users had flagged this behaviour before Apiiro measured it at scale. GitHub issue anthropics/claude-code#5544 — "[BUG] approved bash commands containing credentials are stored as is with plain text credentials in settings.local.json" — was opened 11 August 2025 and is now closed after 6 comments. That history matters for defenders: a known, user-reported credential-persistence behaviour sat in the product while the public corpus of exposed files grew past a hundred thousand copies. It also connects to a busy week for Claude Code attack surface on this site — from the Edit-tool TOCTOU symlink workspace escape (CVE-2026-88968) to the Dispatch cross-machine RCE via the ThisBash extension and the child-session hook guardrail bypass. The pattern across all four is the same: the agent's convenience features — approvals, extensions, hooks, sessions — keep becoming the exfiltration or persistence path.

What to actually do

Rotate first, clean second. Search your GitHub organization for .claude/settings.local.json and .claude/settings.json, check each repository's git history for them even where the files are gone, and change every password, token, and key those files have ever held before cleaning up — history and forks keep the old values.
Stop tracking the local file with git rm --cached .claude/settings.local.json and add it to the repository's own .gitignore (not just your global excludes), so the protection travels with the project.
Open the file on your own machine — even if it was never committed — and delete every rule containing a secret. Check credentials paired with a public server address first; those are the ones that grant access.
Keep secrets out of commands. Reference them as variables from a secrets manager (e.g. $DB_URL) so the saved rule holds the variable name, not the secret — and approve patterns such as Bash(npm run:*) instead of single commands.
For security teams: treat agent folders (.claude/, .cursor/, .gemini/, .specstory/) and agent memory files as secret-bearing like .env files on laptops and in repos; add them to pre-commit and CI secret scanning including git history, with rules that catch passwords inside commands, not only known key formats; and add the local settings file to the organization's .gitignore templates.

Our verification was read-only. We read The Hacker News report by Swati Khandelwal in full first-hand (7 November 2026: "Yes, and don't ask again" mechanism, .claude/settings.local.json, 104,185 copies in 103,617 repos, 1,122 with secrets, 1,379 distinct secrets in current copies, 2,539 across 1,994 repos including history/forks/settings.json/chat logs, 379 database passwords, 43 SSH logins, 42 Git/GitLab/npm tokens, 23 AWS keys, 63 organizations, 539/1,105 Claude-co-authored commits, 734 historical secrets in 509 repos, 211 forks of 74 repos, 298/76,011 settings.json copies, gitleaks 564 / TruffleHog 643 / neither 215, 217-day median persistence, Opus 5.5 and Fable 5.1 reproduction, 16-agent comparison, Shai-Hulud September-2025 precedent), cross-checked the headline figures against Brave-indexed GBHackers, runtimewire and dev.to summaries (all agreeing: 1,122 files, 1,379 current-copy secrets, 2,539 total), and confirmed GitHub issue anthropics/claude-code#5544 first-hand via the API (opened 11 August 2025, closed, 6 comments). The Apiiro research write-up itself is Cloudflare-bot-gated from our network, so its figures are carried via THN's full account and declared openly here. We checked the site search index for apiiro, settings.local.json, don't-ask-again and allow-list coverage and found no overlap. We cloned no repository, tested no secret, ran no scanner, and contacted no vendor. Brave Search was used for discovery only.

Sources: