Agent chaosVerified·8 Nov 2026
Claude Code's 'don't ask again' button left real passwords in 1,122 files on public GitHub
Clicking "Yes, and don't ask again" in Claude Code can save the approved command, password and all, into .claude/settings.local.json. Researchers scanned 104,185 public copies of that file and found real secrets in 1,122 of them, 2,539 distinct secrets in total once git history and transcripts were included, touching 63 organisations.
No prompt injection, no stolen account, no malware. Just a developer clicking the most convenient button in Claude Code, and a settings file quietly doing what it was built to do.
What happened
Security researchers at Apiiro examined 104,185 public copies of .claude/settings.local.json on GitHub, collected between 1 and 3 November 2026. Real secrets sat in 1,122 of those files, holding 1,379 distinct credentials. When they also checked earlier commits, shared settings files and saved agent transcripts, the total rose to 2,539 distinct secrets across 1,994 public repositories, linked to 63 organisations, mostly software companies.
The examples are not toy keys: an admin-level cloud key belonging to a database vendor, a production Azure PostgreSQL password, a Square production token and the owner password for a medical-records database. One company confirmed its exposed key had been live.
How it went wrong
The flow is ordinary. You ask Claude Code to check a database, test an API or debug a failed login. It builds a shell command with a credential pulled from a config file and asks permission. You pick "Yes, and don't ask again". That command, secret included, is saved as an allow rule in .claude/settings.local.json so it can run again without a prompt. Commit and push that file, and the password is public.
Claude Code does try to stop this: the first time it writes the file inside a Git repository, it adds an exclusion to the developer's global Git ignore file. But that protection does not travel with the project, does not cover files that are already tracked, and does not reliably protect a folder that becomes a repository later. A GitHub issue flagged plaintext credentials in approved commands as far back as August 2025.
What leaked
Databases dominated: 379 database passwords and 122 Supabase service-role keys. There were cloud credentials, private keys, package-registry tokens and 43 SSH logins, some carrying root passwords.
Standard scanners missed a lot. Of the 1,122 affected files, Gitleaks flagged 564 and TruffleHog flagged 643; neither flagged 215. Passwords tucked after PGPASSWORD=, sshpass -p or inside request headers do not look like provider-issued keys, so pattern matching sails past them.
What to do now
Search your repos and their history for .claude/settings.local.json and review shared .claude/settings.json too. Look for passwords, tokens, connection strings and authorization headers inside allow rules. Rotate first, delete second: removing the file does not remove the secret from git history. Then untrack the file with git rm --cached and add the path to the repository's own .gitignore. Saved conversations, memory files and deployment notes were also found holding secrets.
Our take
Permission memory is a credential store whether anyone designed it as one or not. Keep literal secrets out of agent commands entirely and reference a secret manager or environment variable instead, so there is nothing worth saving when you click the lazy button.
Never let an agent approval memorise a command with a literal secret in it: reference a secret manager, ignore agent settings per repo, and rotate before you delete.
