Claude Code's “Don't Ask Again” Can Save Secrets. What Should You Check?

You ask Claude Code to check a database connection. It proposes a command containing the password. You approve it and choose the option that stops it asking again. That convenience can create another copy of the password: inside the rule remembering your approval.

If you have approved commands containing credentials, check your saved rules privately. A credential that reached a public repository or another unauthorized destination needs revocation or rotation first, followed by file cleanup. The approval creates the saved rule; publication happens when its contents are shared.

What the approval saves, and where

Anthropic's permissions guide says a saved rule covers the text its approval option names, often a command prefix. A credential inside that text is saved with it. Read the proposed rule before accepting it: a literal credential visible there is the earliest warning that the approval could retain it.

Here is a deliberately fake illustration, using a fictional client:

Build rule:  Bash(npm run build)
Secret-bearing shape:  Bash(example-client --password FAKE_PASSWORD_DO_NOT_USE *)

The second rule retains the literal password in its saved text.

The settings documentation distinguishes two routes. Terminal approvals go to .claude/settings.local.json. The VS Code extension lets you choose the destination, including the shared .claude/settings.json. That shared file is intended for version control, so a credential saved there can travel with the project's committed settings.

For the local file, Claude Code adds a global Git exclusion on its first write inside a repository that does not already ignore it. Manually created files need your own exclusion. This protection is specific to the local-settings path; it leaves the shared settings file available for commits.

A committed project .gitignore travels with a clone. A user's global exclusion belongs to that user's Git configuration. Git's ignore rules leave already tracked files in the index. Anthropic also applies repository trust checks to tracked local settings, which controls whether their allow rules take effect. Published credential text remains readable regardless of that execution safeguard.

File location matters too. Current terminal sessions generally save local settings at the repository root, with documented exceptions including Windows and non-repository folders. Before v2.1.211, the file stayed in the starting directory; current versions still read those older copies. Check subfolders as well as the root.

What the research and response establish

Apiiro's investigation reported 1,122 secret-bearing local-settings files among 104,185 public copies. Its wider count, including the file’s history, shared settings and agent transcripts, was 2,539 distinct secrets across 1,994 repositories. The vendor did not test whether the credentials worked; Choosely has not reproduced its scan.

In the Hacker News discussion, Claude Code's Boris Cherny said historical secret scrubbing was absent. He stressed the local file's intended privacy, attributed exposed copies to manual creation and check-in, and recommended Auto Mode and host secret scanning.

Apiiro's evidence complicates that explanation. In its separate traced set of 1,105 repositories with classified secrets, 539 had a Claude-coauthored commit that changed the file. That is recorded attribution. It cannot establish who chose to include the file or the sequence of approvals. These are traced repositories, distinct from the 1,122-file count and wider 1,994-repository total.

A reader also pointed out that Auto can still ask about sensitive commands, allowing an approval to save a rule. Cherny acknowledged the point and said the team was considering improvements. He described prototyping prevention, including Auto detection and basic scanning. Switching modes therefore leaves existing saved secrets and their distributed copies to address.

As checked November 9, Claude Code’s changelog listed 2.1.319 as its latest entry and did not identify a change removing credentials from saved rules. The discussion describes work being explored, with no release established for that specific protection.

Which situation are you in?

Start with your own project and the credential's actual path. The same filename can describe very different exposure.

Git exclusions govern Git. Container build contexts, package contents and archive uploads need their own review: an ignored file can still leave through another route.

For a founder who does not manage the repository, ask the responsible developer to establish which row applies. Keep the settings file with its owner during that review.

Check filenames before opening contents

Owners can run these read-only checks from the repository root. The quoted patterns cover both named settings files at any depth, including copies older versions left in subfolders:

git ls-files -- ':(top,glob)**/.claude/settings.local.json' ':(top,glob)**/.claude/settings.json'
git log --all --format=%H -- ':(top,glob)**/.claude/settings.local.json' ':(top,glob)**/.claude/settings.json'

The first command lists paths in the index, including newly staged files. The second lists matching commit hashes from locally available history. Neither prints file contents or commit messages. A history match warrants private inspection to establish whether that version contained the credential and where it went.

No result is not an all-clear: shallow clones, missing refs, renamed paths and copies elsewhere can escape these checks. They also exclude files outside the repository. Use the same private review for other project folders where you started Claude Code.

For an untracked local-settings file, this exclusion diagnostic shows the matching rule and its source:

git check-ignore -v -- .claude/settings.local.json

Replace the path with each nested local-settings path you find. Tracked files normally produce no output; a negated rule beginning with ! means the path is not ignored. Check tracking first and read the result carefully.

Use a trusted local editor to review current allow lists and relevant historical versions for passwords, tokens and connection strings. Keep the contents out of public tickets, chats and scanners. Review shared settings while preserving the legitimate configuration the team needs.

Contain exposure, then clean up

GitHub's guidance puts revocation or rotation first. The credential owner should follow the provider's replacement process, update dependent services and review access during the exposure window.

Then add repository ignore rules covering the local-settings copies. For a tracked local file, deliberately remove it from the index while retaining the working copy, and review the intended change before committing. Earlier copies still require an exposure assessment. Shared settings need their sensitive rules removed while useful team configuration is preserved.

History rewriting can disrupt collaborators and needs coordination. GitHub says it may be unnecessary after a credential is invalidated. Secret scanning supplies another detection layer, with coverage dependent on patterns and configuration.

For future commands, use a supported method that keeps literals out of recorded approvals, such as runtime secret injection. Processes may still read environment values, and command expansion or logs can reveal them. Inspect the actual command and output, and retain narrow permissions.

Choosely's verdict

A saved approval belongs in your review of sensitive project state. Check its destination, inspect both local and shared rules, and account for older copies in subfolders. Where credentials escaped their intended scope, contain the exposure before tidying the files.

The convenience is worth keeping. The reusable password is worth keeping out of the approval record.

For the broader delegation decision, our Claude Auto Mode explainer covers what changes when an automated check handles more approvals.