Claude Code Secret Exposure: Analyzing the .claude/settings.local.json Leak
The Mechanism of the Leak
Claude Code’s "Don't Ask Again" feature is designed to streamline developer workflows by caching permission rules for shell commands. When a user approves a command that includes sensitive information—such as a database password, API token, or cloud key—the agent saves the full command string into a .claude/settings.local.json file within the project directory. Because this file is located inside the project folder, it is often inadvertently committed to version control, making these secrets publicly accessible if the repository is pushed to a public GitHub host.
While Claude Code attempts to add this file to a global gitignore list, this protection fails in scenarios where a folder becomes a repository after the file is created, when the file is cloned to a new machine, or when a developer manually adds the file to the repository. Apiiro’s research indicates that in 539 of the 1,105 repositories containing real secrets, a commit co-authored by the agent itself included the file, effectively automating the exposure.
Scope and Impact
Apiiro identified 2,539 real secrets across 1,994 public GitHub repositories. These include high-value credentials such as production database passwords, cloud API keys, and SSH root logins. The impact spans 63 organizations, including startups, software agencies, and IT service firms. In one instance, a database vendor’s own admin-level cloud key was exposed.
Beyond GitHub, the risk extends to developer workstations. Because the .claude/settings.local.json file is stored in plain text, it is a prime target for malware. Security researchers have noted that existing credential-harvesting worms, such as the Shai-Hulud npm worm, have already begun scanning local environments for these types of configuration files.
Limitations of Current Secret Scanners
Standard secret-scanning tools like Gitleaks and TruffleHog often fail to detect these leaks because they are primarily tuned to identify specific key formats (e.g., provider-prefixed strings). Many of the secrets captured by Claude Code are passwords embedded directly into command-line arguments (e.g., PGPASSWORD=... or sshpass -p ...). These appear as ordinary text to traditional scanners, leading to a significant detection gap. Apiiro found that one in five of the compromised files were flagged by neither Gitleaks nor TruffleHog.
Mitigation and Best Practices
To secure environments against these leaks, developers and security teams should adopt the following practices:
- Untrack and Ignore: Immediately remove
.claude/settings.local.jsonfrom git tracking usinggit rm --cached .claude/settings.local.jsonand ensure it is added to the project's.gitignorefile. - Credential Rotation: If a file containing secrets has been committed, assume those credentials are compromised. Rotate all keys, tokens, and passwords found in the file history.
- Use Environment Variables: Never type secrets directly into commands. Reference them via environment variables (e.g.,
$DB_URL) so that the cached command string contains only the variable name rather than the raw secret. - Enhanced Scanning: Configure CI/CD pipelines and pre-commit hooks to scan for patterns beyond standard key formats, specifically looking for password-in-command patterns.
- Agent Sandboxing: Consider running agents in isolated environments or using API proxies that restrict the agent's ability to perform unauthorized write operations or access sensitive services.
Community Insights
Discussion among developers highlights that while the tool's behavior is a contributing factor, the root cause is often a lack of strict security hygiene. Commenters noted that:
"The root issue is not the button, it is that the allowlist stores the full command string... secrets go into commands only via env vars, and .claude/ lives in the machine-wide global gitignore, not in the repo."
Others emphasized that relying on automated tools without manual verification of what is being committed is a dangerous practice. As one user noted, "You need to take your own responsibility for and never rely on some bot automation... read things before you put them in a place where everyone can see them forever."
Sources
Related
- Dispatch
- Project
- Dispatch
- Project
- Project