Claude Code secrets: check and rotate exposed credentials

#1. Introduction

A Claude Code approval can leave a password or API key in a project file, and deleting that file later may not remove it from Git history or forks. On November 7, 2026, The Hacker News reported Apiiro’s finding that 1,122 public copies of Claude Code settings files contained at least one secret.

The immediate response is to identify every affected repository and rotate exposed credentials before cleaning up files or rewriting Git history. Apiiro said it found 1,379 distinct secrets in those files; it did not establish whether every secret was still valid or had been used.

#How it works

Claude Code asks for approval before running many shell commands. When a developer chooses “Yes, and don’t ask again,” Claude Code can save an allow rule in .claude/settings.local.json, so a matching command can run without prompting in later sessions.

The risk is that an exact command can contain a credential. If the command includes a password or token, saving it word-for-word also saves that value in plain text. Apiiro said it reproduced this behavior with the latest models it tested, Opus 5.5 and Fable 5.1.

Claude Code’s local Git protection does not make the file safe to commit. According to its documentation, Claude Code adds the file to the user’s global Git excludes, which affects Git behavior for that user on that computer. It does not add a rule to the project’s .gitignore, and it cannot prevent a file that has already been committed from appearing in repository history.

That distinction matters when teams share projects across different machines. A file may be ignored locally on one developer’s laptop and still be committed by another contributor, or included in a package, container image, archive, or synced folder.

The exposure extends beyond the local settings file. Apiiro also found secrets in committed .claude/settings.json files, older versions of settings files, and saved agent chat logs. The researchers said common secret scanners missed many examples, particularly passwords embedded in commands rather than values matching familiar key formats.

#Am I affected?

Check every repository in your GitHub organization for both settings files, including repositories where the files no longer exist on the default branch. Apiiro reported that half of the repositories with a secret had contained it for at least 217 days, so a recent clean working tree is not enough.

Start with a repository-wide search using GitHub’s code search, or inspect a local checkout:

git ls-files '.claude/settings.local.json' '.claude/settings.json'

Then check commit history across local refs. This lists file changes without printing file contents:

git log --all --name-status -- \
  .claude/settings.local.json .claude/settings.json

A clean result in one checkout does not prove the repository is clean. Make sure you have the relevant branches and tags, and check forks and archived repositories where your team has access. Review agent chat logs and other agent-specific folders as well, especially if they were committed or included in build artifacts.

Inspect any matching files in a controlled environment. Don’t paste their contents into tickets, chat, or a public scanner. Treat any credential that may have appeared in a public repository or distributed artifact as exposed, even if it has since been removed.

#How to fix or mitigate it

Prioritize response in this order:

1. Rotate credentials first. Change every password, token, and key that appeared in the files or their history. Start with credentials paired with public servers and access to databases or cloud services. Removing a string from Git does not make the credential unusable.

2. Stop tracking the local settings file. If it is in the repository index, remove it from tracking while keeping the local copy:

   BashCopy

   git rm --cached --ignore-unmatch .claude/settings.local.json
   

   Add a project-level ignore rule so the protection applies to everyone working in the repository:

   .gitignoregitignoreCopy

   .claude/settings.local.json
   

   Check the rule with git check-ignore -v .claude/settings.local.json. The shared .claude/settings.json may contain intentional team configuration, so inspect it for secrets rather than ignoring it automatically.

3. Remove secrets from files and history. Delete secret-bearing rules from local files and committed settings. If you rewrite repository history, coordinate with contributors and account for forks and other copies. History cleanup reduces further exposure; it does not replace credential rotation or remove copies that already left the repository.

4. Keep credentials out of approved commands. Use environment variables or a secrets manager instead of typing literal values into shell commands. For example, a saved command can refer to $DB_URL rather than embedding a database password. Make sure the variable itself is supplied securely and isn’t written to logs.

5. Review approval patterns. Where practical, approve a constrained command pattern, such as a test command, rather than repeatedly approving an exact command containing arguments. Patterns reduce the chance that a secret-bearing command is saved, but they are not a substitute for keeping secrets out of command text.

Finally, extend secret scanning to agent configuration files and Git history. Don’t rely only on scanners that recognize key formats: Apiiro reported that gitleaks and TruffleHog did not flag 215 of the 1,122 files it identified as containing secrets.

#Lessons for your team

AI coding agents create useful local state, but that state can cross the boundary between a developer’s machine and a shared repository. Treat agent configuration and memory files as potentially sensitive, much like .env files, and include them in repository templates, pre-commit checks, and CI scanning.

The approval prompt is also a security boundary. A convenient “don’t ask again” option can turn a one-time command into durable configuration, so teams should teach developers to check what will be saved and avoid putting credentials in command arguments.

The practical test is straightforward: can your team find and rotate a secret even after its file has been deleted from the current branch? If not, Git history and agent-generated files deserve a place in your incident-response process.

#Key takeaways