Claude Code approvals can preserve secrets inside project settings

What the research found

Apiiro published the study on November 5, 2026 [1]. Researchers used read-only GitHub code and commit searches from November 1 to 3. They split searches by file size to work around GitHub result limits and downloaded 104,185 public local-settings files.

The researchers classified 1,379 distinct credentials in 1,122 current local-settings files. The set included provider keys, database passwords, service-role keys, package and source-control tokens, private keys and 43 SSH logins.[1]

Their wider count included secrets found only in Git history, shared settings and agent transcripts. Apiiro counted 2,539 credentials in 1,994 repositories and 63 organizations. One notified company confirmed that its key had been live.[1]

How a standing approval records a secret

Anthropic’s settings documentation [2] says that choosing ‘Yes, and don’t ask again’ for a Bash command saves an allow rule in .claude/settings.local.json. If a command contains a password, token or connection string, the stored rule can preserve that literal value.

Claude Code adds **/.claude/settings.local.json to the user’s global Git excludes when it creates the file in a repository.[2] This protects the usual untracked-file case on that machine. It does not add a rule to the repository itself, so the protection does not travel with a clone. It also cannot retroactively untrack a file.

A public bug report from August 2025 [3] reproduced plaintext credentials in the permissions allow list. A separate September 2026 report described the VS Code extension writing personal approvals into tracked shared settings in one Windows setup.[4] Anthropic now documents that the VS Code approval card lets the developer choose a destination file, including the shared project file, while the CLI writes approvals to the local file.[2] Both GitHub issues were closed by automation without a maintainer response or announced fix.[3][4]

Why ordinary secret scanning missed part of the set

Gitleaks flagged 564 of the 1,122 affected current files, while TruffleHog flagged 643. Apiiro reported that both tools missed 215 files.[1]

Provider keys often have recognizable prefixes, but a password after PGPASSWORD=, sshpass -p or mysql -p can look like an ordinary command argument. Teams need rules for credential-bearing command syntax as well as provider key formats.

Apiiro did not use any credential or contact any host. Its ‘real secret’ classification means that a value matched a provider format or appeared beside a public host after automated checks and masked-context review. Validity was not tested, so the total is evidence of exposure risk rather than proof that all 2,539 credentials still worked.[1]

Response checklist

• Search every repository for .claude/settings.local.json, .claude/settings.json and agent transcript, memory or handoff files.
• Inspect the default branch and full Git history. Check forks and published packages when an affected file was ever tracked.
• Rotate each credential before rewriting history or deleting files. Assume a public value may already exist in clones and caches.
• Review authentication, database, cloud and package-registry logs for use of the exposed identity, especially from the first commit date onward.
• Remove tracked local settings with git rm --cached, then add **/.claude/settings.local.json to the repository .gitignore.
• Replace literal credentials in commands with environment-variable references backed by a secret manager.
• Add pre-commit and CI checks for agent configuration and records. Detect passwords in command arguments as well as provider-formatted keys.
• Review shared allow rules and keep them narrow. In VS Code, check the destination file before saving an approval. Use managed policy, sandboxing and deny rules for boundaries that individual developers should not override.

Prevent the next exposure

Treat coding-agent state as sensitive developer data. Local settings, transcripts and memory can contain commands, paths, internal hosts and credentials even when application source looks clean.

A repository-level ignore rule gives every clone the same default. The global exclude that Claude Code configures remains useful, but teams should not rely on one developer machine to carry a project security rule.[1][2]

Do not paste a secret into a command that an agent may record. Load it from a secret manager or environment variable and approve the stable command shape. Prefer short, reviewed patterns over a growing list of one-off literal commands.

What remains uncertain

• Apiiro did not validate credentials, so the study does not establish how many remained active at publication time.[1]
• The researchers reported affected organizations privately and did not name them. Readers cannot independently check the individual cases.
• Anthropic’s current documentation describes the global-exclude protection and the VS Code destination choice, but no linked Anthropic advisory confirms the Apiiro totals or announces a product fix.[2] The two cited issues were closed by automation as not planned.[3][4]
• GitHub code search covers public repositories. The study does not estimate local-only files, private repositories, archives or container images.
• The findings center on Claude Code because it records complete approved commands in project-local settings. Teams should still inspect state written by every coding agent they use.[1]

Frequently asked questions

• Does this mean every Claude Code user leaked a secret? No. Apiiro found a credential in 1.1% of the public local-settings files it checked.[1]
• Is deleting the file enough? No. Rotate the credentials first, then inspect history, forks, clones and published artifacts.
• Should teams stop using standing approvals? They should avoid literal secrets, approve narrow stable patterns and review the resulting settings. Managed restrictions and sandboxing can reduce the impact of an overbroad rule.
• Why add a repository ignore rule if Claude Code uses a global exclude? The repository rule travels with every clone and protects folders that move between machines or become repositories later.[1][2]
• What should security scanners inspect? Include .claude, other agent configuration directories, transcripts, memory, handoff notes and Git history. Add patterns for passwords embedded in shell commands.