Claude Code’s “Don’t Ask Again” Can Remember Your Password, Too
A convenience click can preserve a credential in a project file. Apiiro found secrets in 1,122 public copies of Claude Code’s local settings file, but did not test whether those credentials still worked.
The actual story.
What the button remembers
Claude Code’s permissions documentation says permanent approvals are saved in .claude/settings.local.json. A Bash rule can match an exact command. That makes the contents of the command worth checking before agreeing to remember it.
Apiiro’s research describes the trap: approve a command containing a password or token, and the saved rule can contain that secret. Commit and push the file to a public repository, and the credential can become public.
“Local” is not a security boundary
Anthropic’s settings guide says Claude Code adds the local file to the developer’s global Git excludes when first writing it in a repository. That is a machine-level ignore rule, rather than a rule committed with the project. The documentation separately identifies .claude/settings.json as the shared settings file intended for version control.
Those similar names deserve very different treatment. Before committing agent configuration, inspect the actual changes, rather than assuming a file called “settings” is harmless.
Exposure, not 1,122 confirmed break-ins
Apiiro examined 104,185 public local-settings files. Across its wider investigation, including history and other agent files, it counted 2,539 distinct secrets in 1,994 repositories. Its classification does not establish that every credential was valid or abused. The researchers say they did not use the credentials or contact the hosts.
Anthropic’s response
Boris Cherny of the Claude Code team said on Hacker News that the local settings file should not be committed and recommended secret scanning. In a follow-up, he listed possible approaches including basic secret scanning and changes to auto mode, saying the team would prototype options before shipping.
That response describes work being considered, not an announced, released fix.
Before your next push
Check saved approval rules and staged changes for credentials. If a secret has already reached a repository, GitHub’s guidance puts revoking or rotating it first. Deleting the visible file does not remove earlier commits, forks or clones. History cleanup needs coordination with collaborators.
For future commands, keep secret values out of the text being approved. Review what a standing permission will actually store and allow.
An approval system can become another place to store secrets. Check what “remember” saves, keep private settings out of commits, and rotate exposed credentials before treating cleanup as finished.
Receipts, not rumors.
- Apiiro research and methodology
- Claude Code: Configure permissions
- Claude Code: Settings files and precedence
- Boris Cherny’s initial response
- Boris Cherny: prototyping possible mitigations
- GitHub: Removing sensitive data from a repository
Read the original reporting: Apiiro
The reporting above provides context. Illustrations are editorial interpretations, not source photographs.
What’s your take?