Originally published at ReclaimLLM.

Saved Claude Code approvals can contain inline credentials. Check local settings, prevent accidental commits, and rotate secrets that were exposed.

Claude Code settings.local.json: find and fix saved secrets

Updated November 14, 2026.

A permission rule can become a credential store. If a shell command contains a password, saving that command as a standing approval can preserve the password alongside it. When the settings file then reaches a shared repository, the secret reaches everyone who can read that repository.

This is a specific Claude Code security issue worth checking across a team: inspect saved approvals, establish where copies went, and fix the repository rules that allowed them to travel.

How an approval becomes a saved secret

In November 2026, Apiiro reported finding secrets in public copies of .claude/settings.local.json. Its researchers described a path from approving an exact shell command with "Yes, and don't ask again" to saving that command, including an inline credential, as a permission rule. Their search found 1,122 public copies containing secrets. These are Apiiro's findings, rather than a ReclaimLLM scan. Apiiro did not test whether the credentials were still valid. Read the primary research, or the summaries by The Hacker News and GitLab.

For illustration, a command containing PGPASSWORD=EXAMPLE_ONLY can carry a password directly in its text. If that literal text is persisted, the settings file now holds the value too. EXAMPLE_ONLY is a dummy value here.

The exposure has two stages: writing a secret to a local file, then sharing that file. A local copy alone does not establish that a credential was published or used by someone else. Determine where it went before describing the incident.

What Claude Code already does

settings.local.json is where Claude Code stores personal project settings, such as permissions.allow. A team should check whether any secret-bearing command reached that file.

Claude Code says it prevents settings.local.json from being committed, and that its global excludes file excludes it by default. This depends on the settings in each installation, so confirm it in your setup.

Other files are not affected. Shared .claude/settings.json files still need the usual review.

A file that is absent from the index may still exist in the repository history. Use the history commands below when you want to confirm.

Use the Claude Code settings documentation to confirm the current behaviour. Use the Git ignore documentation to confirm how global and local rules interact.

Check the repository without spreading the values

Do not run these commands when a credential is visible on the screen. Inspect the settings file in a private editor first, then check the commit history:

git ls-files --error-unmatch .claude/settings.local.json
git log --follow --all --oneline -- .claude/settings.local.json

The first command reports an error when the file is not tracked. The second shows whether the file appears in earlier commits. Do not copy raw secret-bearing values into a ticket or a chat log.

Rotate exposed credentials, then clean up

For a file that contains a credential, the credential should be rotated before the file is deleted. That is the rule that matters most: a file that is deleted without rotating its credential leaves the credential live, because the credential may still exist in a clone, a fork or a local backup. Remove the credential, rotate it, and then clean the history using the GitHub sensitive-data removal guidance. Confirm the repository again afterwards.

Add the local settings file to a global exclude so it is not committed by another client:

**/.claude/settings.local.json

After you confirm that the local file contains no secret, remove it from the index with git rm --cached .claude/settings.local.json. The file stays in the working tree, but it is no longer tracked by Git.

Prevent the next saved credential

Claude Code offers a safer pattern for storing credentials. The AskUserQuestion tool supports password and other types, which are stored in the session transcript's secret store. Check the transcript secret-store guide for the details, and review the broader Claude Code security guide before adding new automation.

This is a design rule for teams: avoid writing credentials into any configuration file or command that can be saved as a permission rule. For a database client, prefer a connection service, environment variables or $DATABASE_URL. Do not approve a command that contains a live password in its text, even when the command itself is legitimate.

Review your team's Claude Code security controls.

Read the original article at ReclaimLLM.