Claude Code can save a password in an approval rule. Check before you commit

You ask a coding assistant to check a connection. It proposes a command, you approve it and the task works. Before sharing the project, there is another question to answer: what did that approval leave in the folder?

Recent Claude Code research gives this question a concrete focus. A saved permission can contain a credential, such as a password or access token. This guide explains the findings, then uses a harmless Git exercise to show how a personal settings file can remain part of a project’s tracked changes.

What changed, and what remains uncertain

Apiiro’s research, published on 5 November 2026, identified likely credentials in 1,122 of 104,185 public copies of .claude/settings.local.json. The researchers did not test the credentials or contact the hosts. Their count is evidence of exposed credential material, rather than confirmation that every credential worked or that every system was breached.

An update dated 8 November adds Boris Cherny’s response on Hacker News. The head of Claude Code described possible prevention work, including secret scanning and changes to auto mode. These were approaches to investigate and prototype, not a release announcement. Switching modes alone is therefore not an established remedy for this finding.

Running a command and saving permission are separate decisions

A permission rule tells the tool what it may run in future. Claude Code’s permissions documentation says that a permanent Bash approval is saved in a local settings file. Apiiro reports cases where the saved command included the literal credential. This does not mean every approval includes a secret or automatically publishes one.

Anthropic documents an automatic Git exclusion when Claude Code first writes the local file in a repository. That protection belongs to the developer’s global Git configuration. The shared .claude/settings.json serves a different purpose and can deliberately carry team settings. Inspect their contents and roles separately.

For your review, follow three stages: what the command contains, what the approval records, and what your next commit includes. Completing one stage successfully does not answer the others.

A worked example with no real credentials

An example: you are learning how Git handles a local settings file. Use a new practice folder outside your real project. Do not connect it to a remote repository, run Claude Code, or use a password. Git is the version-control tool that records project changes; its index is the staging area for the next commit.

{
  "permissions": {
    "allow": ["Bash(echo DEMO_ONLY_NOT_A_PASSWORD)"]
  }
}

git add .claude/settings.local.json

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

The first command still prints .claude/settings.local.json. The second produces no output. That blank result is not a privacy guarantee. Git’s ignore documentation explains that ignore rules do not affect files already tracked. Your new rule does not undo the earlier staging step.

To complete this harmless exercise, remove the practice file from the index while keeping it on disk, then repeat the two checks. Use the command below only in your practice folder. No commit or remote upload is needed.

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

Now the tracked-file listing is empty and the ignore check identifies the rule in .gitignore. Neither result examines older commits or proves that every file in a real project is free of secrets.

Apply the distinction to a real project

Begin with an authorised repository and a private review environment. Inspect local settings, deliberately shared settings and saved transcripts. Keep credentials out of screenshots, issue comments and AI prompts. Record paths and findings without copying the values into another system.

If a credential has been exposed, GitHub recommends revoking or rotating it first. Involve whoever owns the affected service. Then stop further sharing, investigate the exposure and coordinate file and history cleanup. Rewriting history can disrupt collaborators and does not reach every existing copy.

For future work, use your organisation’s approved secret-handling method and inspect the resulting command and saved rule. A runtime reference can avoid placing a literal value in the command text; an inline assignment containing the actual password still contains that password. A reference also does not prevent a running tool from accessing the secret. Keep its permissions appropriate to the task.

A review brief you can reuse

Before your next commit, ask a colleague to explain the practice table back to you: which result shows tracking, which shows an ignore rule, and what remains unverified? Then inspect the staged changes in your own project. The useful habit is checking both the work and the record it leaves behind.