The durable part of “yes”
In GitHub searches covering November 1–3, 2026, security company Apiiro found 1,122 of 104,185 public .claude/settings.local.json files contained something it classified as a real secret. Its broader sweep counted 2,539 secrets across 1,994 repositories. Apiiro did not test credentials: “real” meant a value matched a known credential format or appeared beside a public host; one organization confirmed a key had been live. In the same corpus, Gitleaks and TruffleHog both missed 215 files, often because a secret was a password embedded in a command rather than a recognizable key format. These are Apiiro’s findings, not a general scanner benchmark. S1
Claude Code’s permissions documentation confirms the persistence mechanism: on eligible prompts, “Yes, and don’t ask again” stores an allow rule in .claude/settings.local.json at the repository root. If a developer has typed a password into a shell command, that approval trail can retain a secret locally. This is not a model independently deciding to publish credentials; the risk is that convenience settings or command history become source-controlled or packaged. S2
The related Hacker News discussion includes a commenter identifying as a Claude Code team member, who said the product historically had no secret scrubbing and the team was looking into prevention. Treat that as a reported response—not a shipped fix or a timeline. S3
Audit more than source code
For a team, the practical fix starts with inventory. Search working trees and full Git history for local and shared agent settings; inspect permission rules and saved transcripts for literal passwords, tokens, and connection strings. Check both repository state and developer machines: “local” describes intended scope, not guaranteed containment.
When a credential appears, rotate it first. Then clean current files and history; deleting a file does not invalidate a token already exposed or erase forks and clones. Add .claude/settings.local.json to project .gitignore and organization templates instead of trusting a machine-local global exclude.
Make approvals secret-aware
Stop putting credential values in commands: pull them from a secret manager or environment variable so the reusable rule contains $DB_URL, not the password. Prefer narrow command patterns to saving secret-bearing one-offs. Extend pre-commit and CI scans to inspect agent config, transcripts, Git history, and shell-shaped secrets such as PGPASSWORD=; conventional key-pattern detectors will not catch every plain-text password. Keep agent credentials scoped and give them only the access the task needs.
Sources and editorial method
This AI-assisted report synthesizes the sources below. Automated source checking is not independent human verification; follow the original reporting for context and updates.
Common questions
Does deleting a leaked agent settings file revoke exposed credentials?
No. Rotate or revoke credentials first, then clean current files and repository history; copies and forks may persist.
What should secret scanners check in agent projects?
Check agent settings, saved transcripts, Git history, and command strings that may contain passwords or connection strings.


