Claude Code’s “Yes, and don’t ask again” approval flow can save passwords and API keys inside project settings, and those secrets can later reach public GitHub repositories. Apiiro found the problem across 1,994 public repositories and tied it to 2,539 distinct secrets.
Local approvals become shared files
The leak begins during routine development work. A developer asks Claude Code to check a database, test an API, or troubleshoot a failed login, and Claude prepares a shell command with a credential from a configuration file before asking for permission to run it. If the developer chooses “Yes, and don’t ask again,” that command and its secret can be stored in .claude/settings.local.json as an allow rule, letting Claude Code run it again without another prompt.
Claude Code does try to reduce the risk when it first writes the file inside a Git repository. It adds an exclusion to the developer’s global Git ignore file. That protection does not travel with the project, does not cover files already tracked, and does not reliably protect a folder that becomes a repository later.
What Apiiro found in public repositories
Apiiro researchers examined 104,185 public copies of .claude/settings.local.json. They found real secrets in 1,122 files, with 1,379 distinct credentials in those files. When earlier commits, shared settings, and agent transcripts were added, the total reached 2,539. The collection took place November 1-3, 2026.
The research identified 63 affected organizations, mostly software companies. Exposed credentials included a database vendor’s admin-level cloud key, a production Azure PostgreSQL password, a Square production token, and the owner password for a medical-records database. One company confirmed that its exposed key had been live.
What kinds of secrets were exposed
Databases accounted for a large share of the exposed access. Apiiro found 379 database passwords and 122 Supabase service-role keys. Other exposed items included cloud credentials, private keys, package-registry tokens, and 43 SSH logins. Some SSH commands contained root passwords.
The exposure also extended beyond literal passwords. Passwords embedded after PGPASSWORD=, sshpass -p, or inside request headers often do not match the clear formats used to recognize provider-issued keys. Apiiro said standard scanning did not catch every case.
What the scanners missed
Of the 1,122 affected local settings files, Gitleaks flagged 564 and TruffleHog flagged 643. Neither tool flagged 215 files. Keeping the files off GitHub also leaves a local risk, since malware can read plaintext settings on compromised laptops. The Shai-Hulud npm supply-chain attack already showed attackers using TruffleHog to search developer files for credentials.
That background makes agent approval files a practical target, not just a publishing mistake. Earlier Claude Code configuration vulnerabilities involved attackers changing project settings to steal API keys, while this case concerns secrets recorded during legitimate work.
What to check and how to respond
Developers should search current files and Git history for .claude/settings.local.json and inspect shared .claude/settings.json files. They should review allow rules for passwords, tokens, connection strings, and authorization headers. Apiiro also found secrets in saved agent conversations, memory files, and deployment notes.
The first response is rotation, not deletion. Exposed credentials should be revoked before files are removed or history is rewritten. Local settings should be untracked with git rm --cached .claude/settings.local.json, and the path should be added to the repository’s .gitignore. Security teams should scan agent folders and history, including command-embedded passwords as well as recognizable API keys.
Licensed under CC BY-ND 4.0 International