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

Security researchers at Apiiro found 1,122 public copies of Claude Code's `.claude/settings.local.json` containing secrets, after developers approved shell commands with inline credentials via the "Yes, and don't ask again" option, which persists the command text as a permission rule. Anthropic says Claude Code prevents the local settings file from being committed and excludes it by default, but the researchers note this depends on each installation's configuration. The guidance is to inspect saved approvals, rotate any exposed credentials before deleting files, and clean repository history.

Originally published at ReclaimLLM https://reclaimllm.com . Saved Claude Code approvals can contain inline credentials. Check local settings, prevent accidental commits, and rotate secrets that were exposed. 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 https://reclaimllm.com/solutions/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. 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 https://apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again , or the summaries by The Hacker News https://thehackernews.com/2026/11/claude-codes-dont-ask-again-file.html and GitLab https://about.gitlab.com/blog/prevent-leaks-from-claude-code-dont-ask-again-file/ . 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. 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 https://code.claude.com/docs/en/settings to confirm the current behaviour. Use the Git ignore documentation https://git-scm.com/docs/gitignore to confirm how global and local rules interact. 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. 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 https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository . 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. 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 https://reclaimllm.com/blogs/ai-coding-transcripts-secret-store for the details, and review the broader Claude Code security guide https://reclaimllm.com/blogs/claude-code-security-best-practices 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 https://reclaimllm.com/solutions/claude-code-security . Read the original article at ReclaimLLM https://reclaimllm.com/blogs/claude-code-settings-local-json-secrets .