One Click on "Don't Ask Again" Put 2,539 Secrets in Public GitHub Repos, Apiiro Finds

The leak starts with a convenience. When Claude Code wants to run a shell command it asks first, and one of the answers is "Yes, and don't ask again". Choosing it writes an allow-rule into .claude/settings.local.json at the root of the repository, so the same command runs unprompted in every later session. When the command happens to contain a credential, the whole string is saved, password included. What looks like a permission is a secret sitting in plain JSON inside a project folder.

Apiiro went looking for the result. The application-security firm scanned 104,185 public copies of that file across 103,617 GitHub repositories and found real secrets in 1,122 of them. Restricted to current file versions, that is 1,379 distinct secrets: 636 in recognizable provider formats and 743 passwords or tokens sitting next to the address of a public server. Once git history, deliberately committed shared settings and saved agent transcripts are added, the count reaches 2,539 secrets across 1,994 repositories.

The composition is the part that should worry security teams. The haul includes 379 database passwords, 122 Supabase service-role keys, 43 SSH logins, 42 GitHub, GitLab and npm tokens, and 23 AWS keys. Some of the SSH credentials are root passwords embedded directly in sshpass commands. The researchers did not attempt to use any of them, but at least one company they notified confirmed that its exposed key was live.

Existing scanners did not catch most of it. Run over the dataset, Gitleaks flagged 564 of the 1,122 affected files and TruffleHog flagged 643, and both missed the same 215. The gap is structural rather than a tuning problem: secret scanners look for provider-specific prefixes and high-entropy strings, and a password following mysql -p or PGPASSWORD= looks like an ordinary word in an ordinary command line.

Git history makes it worse. Claude Code tries to keep the file out of version control by adding it to the developer's global git ignore list the first time it writes it, but that rule lives on one machine and does not travel with the repository, to a teammate's clone or to a CI runner. It also does nothing for a file git already tracks. Apiiro found 734 additional secrets in history across 509 repositories, and 211 forks of 74 repositories carrying the same credentials. In 539 of the traced repositories, the commit that changed the file was co-authored by Claude itself. The exposure is not limited to GitHub either: among 31,053 public projects on Hugging Face Spaces the firm found 126 copies, one containing a database-service key and a user password, and of 69 public copies on GitLab two held a real secret. Saved agent transcripts carried secrets in 120 files across 87 repositories.

Anthropic has not published a fix. Apiiro reproduced the behaviour on Opus 5.5 and Fable 5.1, and in a comparison of 16 coding agents found Claude Code was the only one confirmed to persist the full approved command in a project file by default. The relevant bug report, GitHub issue #5544, was closed by a bot on Jan. 3, 2026 with the message that it had been automatically closed after 60 days of inactivity, labelled as not planned.

The distinction that matters is exposure versus compromise: no evidence has surfaced that anyone used these credentials, and a value counted as a secret had to match a known key format or sit beside a public address, with a human or AI reviewer agreeing. That does not make the design defensible. A secret that has been public is burned whether or not anyone exploited it, which is why Apiiro's remediation order is rotate first, then untrack the file with git rm --cached, then add it to the project's own .gitignore, then remove every rule containing a secret from each developer's machine. Deleting the current file without rotation leaves history, forks and packaged copies untouched.

There is a longer argument buried in the numbers. Agent tooling is being built to be maximally helpful by default, and helpfulness now includes remembering exactly what you approved. That is the same trade-off that produced earlier rounds of cloud credential leaks, compressed into a single click and a file that looks local. The practical mitigation is unglamorous: approve patterns such as Bash(npm run:*) instead of literal commands, pass secrets as variables from a manager so the saved rule holds a name rather than a value, and treat .claude/, .cursor/, .gemini/ and .specstory/ as secret-bearing directories in the same category as .env. Until an agent stops writing credentials into project state, the scanner that catches it has to look inside commands, not just at key formats.