Claude Code's "don't ask again" button has been writing passwords into public repos
One convenient click turned out to be a secret store. Apiiro, an application security company, counted 2,539 real secrets in 1,994 public GitHub repos, and most of them got there the same way: a developer picked "Yes, and don't ask again" in Claude Code. The research was published Nov 5 and reached Hacker News on Saturday.
The mechanism is simple. Ask Claude Code to check why staging login fails, and the command it proposes carries the database password, because it can't work without it. Approve it permanently, and Claude Code saves that exact command string, password included, as an allow rule in .claude/settings.local.json in the project folder. It puts the file in the developer's global gitignore, not the repo's own .gitignore, so a fresh clone, a folder that becomes a repo later, or a file already committed is not covered. In 539 of 1,105 traced repos, a commit co-authored by Claude changed the file itself.
The numbers, all Apiiro's: 104,185 public copies of the file, 1,122 holding a real secret, 379 database passwords, 122 Supabase service-role keys, 43 SSH logins, 63 organizations including a database vendor's own admin cloud key. The part security teams should worry about: gitleaks flagged 564 of those files and TruffleHog 643, and 215 were caught by neither. Scanners look for key formats. A password typed after PGPASSWORD= or sshpass -p is just a word in a command line. Apiiro also found the same pattern in agent transcripts and MEMORY.md files, and says Claude Code is the only one of 16 coding agents it checked that writes the full approved command to a project file by default. Users reported the behavior in GitHub issues since August 2025; Apiiro says none got an Anthropic reply. We found no Anthropic response either.
Take the vendor pitch into account, but the fix list is cheap. Search your org for .claude/settings.local.json, git rm --cached it, add it to the repo's .gitignore, rotate anything it ever held, approve patterns like Bash(npm run:*) instead of literal commands, and reference secrets as $DB_URL so the rule records the variable, not the value.
The bigger point: every agent now keeps a diary of what it ran, and that diary is a new place for credentials to land. Treat .claude/, .cursor/ and memory files like .env, because that is what they have become.
Source: https://apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again
← Back to all articles
The mechanism is simple. Ask Claude Code to check why staging login fails, and the command it proposes carries the database password, because it can't work without it. Approve it permanently, and Claude Code saves that exact command string, password included, as an allow rule in .claude/settings.local.json in the project folder. It puts the file in the developer's global gitignore, not the repo's own .gitignore, so a fresh clone, a folder that becomes a repo later, or a file already committed is not covered. In 539 of 1,105 traced repos, a commit co-authored by Claude changed the file itself.
The numbers, all Apiiro's: 104,185 public copies of the file, 1,122 holding a real secret, 379 database passwords, 122 Supabase service-role keys, 43 SSH logins, 63 organizations including a database vendor's own admin cloud key. The part security teams should worry about: gitleaks flagged 564 of those files and TruffleHog 643, and 215 were caught by neither. Scanners look for key formats. A password typed after PGPASSWORD= or sshpass -p is just a word in a command line. Apiiro also found the same pattern in agent transcripts and MEMORY.md files, and says Claude Code is the only one of 16 coding agents it checked that writes the full approved command to a project file by default. Users reported the behavior in GitHub issues since August 2025; Apiiro says none got an Anthropic reply. We found no Anthropic response either.
Take the vendor pitch into account, but the fix list is cheap. Search your org for .claude/settings.local.json, git rm --cached it, add it to the repo's .gitignore, rotate anything it ever held, approve patterns like Bash(npm run:*) instead of literal commands, and reference secrets as $DB_URL so the rule records the variable, not the value.
The bigger point: every agent now keeps a diary of what it ran, and that diary is a new place for credentials to land. Treat .claude/, .cursor/ and memory files like .env, because that is what they have become.
Source: https://apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again
Comments