Apiiro reported that Claude Code’s “Yes, and don’t ask again” approval can save a shell command containing a password or token in .claude/settings.local.json. If that project settings file is published to a public GitHub repository, the credential in the saved command can be exposed.
How an approval can preserve a credential
The approval option is intended to let a command run again without prompting. In Apiiro’s reported finding, choosing it can save the approved command as a rule in the project’s local settings file. A credential written directly into that command can be stored there in plaintext too.
SavvyNik discusses Apiiro’s reported mechanism, Git history, and remediation in this English-language video.
What the reported counts measure
Apiiro’s study, published November 5, 2026, covered public GitHub data collected from November 1 through November 3. Apiiro reported finding secrets in 1,122 of 104,185 public copies of .claude/settings.local.json, or about 1.1% of the copies examined. Those files contained 1,379 distinct secrets: 636 provider keys and 743 passwords or tokens associated with internet-reachable hosts. The 1.1% is a share of those file copies, not of Claude Code users.
A separate, broader Apiiro tally counted 2,539 distinct secrets across 1,994 repositories and 63 organizations. That total included Git history and other agent-related files, so it counts a wider set of material than the 1,122 settings-file copies.
Apiiro said one company confirmed that one exposed key was active. Apiiro did not test the credentials, so that single confirmation does not describe the status of the other reported secrets.
Why deleting the current file may not remove an exposure
The reports describe a developer-level Git exclusion for the local settings file. It does not add an ignore rule to the project’s .gitignore, travel with the repository, or protect files already tracked by Git. If the file was committed, deleting the current copy does not remove earlier commits or copies in forks and clones.
Apiiro also reported that 215 of the 1,122 secret-bearing files were flagged by neither Gitleaks nor TruffleHog. Passwords embedded in commands or request headers may not match the recognizable formats used to detect provider keys.
What to do if a credential may have been exposed
Revoke or rotate the potentially exposed credential first. Removing a file from the working copy or repository cannot invalidate a credential, and copies may remain in Git history or elsewhere.
Then inspect the current files and Git history for the settings file, remove it from tracking where needed, and add an appropriate ignore rule to the repository. Check the local settings for credentials embedded in approved commands, and avoid putting literal secrets in commands that may be saved.
