AI security researchers at Apiiro discovered over 100,000 instances where Claude Code’s local settings file was uploaded to public GitHub repositories. Of these exposures, approximately 1,100 files from 63 different organizations contained sensitive data such as public API tokens, database passwords, or private keys. The leak stems from how the tool handles user approval for automated shell commands. When a developer selects the "Yes, and don’t ask again" option, the system stores that choice in a local .claude/settings.local.json file. This rule often records the full command exactly as typed, embedding any embedded credentials directly into the configuration text.
How the exposure happens
Anthropic documentation states that this specific settings file is added to the global .gitignore list, which usually prevents accidental sharing. However, that protection does not apply at the repository level. If a project folder becomes a repo later or is cloned to another machine, the sensitive file can be committed without explicit user input. Apiiro reports that Claude Code itself frequently commits changes to this file automatically. Consequently, developers who believe their local machine is secure may unknowingly publish root logins and other critical access details to the internet. The gap between global ignore rules and repo-specific tracking creates a persistent blind spot for teams relying on automated workflows.
Persistent risks in forks
Even after original repositories remove the compromised files, the secrets persist in forks if users are not careful. Apiiro’s findings indicate that the sheer volume of exposed files makes manual cleanup nearly impossible for large organizations. Developers must audit every fork and branch to ensure no residual data remains. This situation highlights a clear failure in default security configurations for widely used development tools. The tool’s convenience features, while useful for productivity, create significant liability when paired with inadequate version control hygiene. Teams should immediately rotate all credentials found in public logs and enforce strict pre-commit hooks to block sensitive files. Relying solely on global gitignore settings is clearly insufficient for protecting production environments.
