Claude Code secret leak exposes thousands of GitHub secrets

Claude Code unintentionally exposed sensitive information on public GitHub repositories, according to Ars Technica. Researchers at Apiiro discovered thousands of secrets, including database passwords, API tokens and root logins, embedded in Claude Code settings files that were accidentally committed. The problem stems from how the tool stores user approval for automated shell commands in a local JSON file that can be pushed to a repository.

How the leak happened

Claude Code lets users approve automated shell commands with a “Yes, and don’t ask again” option. When a user selects that option, the approval is saved as a rule in a local file named .claude/settings.local.json. The rule often includes the full command text, which may contain secrets such as API keys or database credentials. Anthropic’s documentation says the file is added to a global .gitignore, which should keep it off public version control. However, the .gitignore entry is not enforced at the repository level, meaning the file can be uploaded if a developer later turns the folder into a Git repo or clones the repo onto another machine. Apiiro observed that Claude Code itself sometimes commits changes to the settings file without prompting the user, increasing the chance of accidental exposure.

Scale of the exposure

Apiiro’s scan uncovered more than 100,000 cases where the .claude/settings.local.json file appeared in a public GitHub repository. Of those, about 1,100 files from 63 organizations actually contained secrets. The secrets ranged from public API tokens to private keys and database passwords. Even after a file is removed from a repository, the data can linger in forks or cached copies, leaving the information exposed indefinitely if not carefully cleaned.

Why it matters to small businesses and nonprofits

Many small teams use AI‑assisted development tools like Claude Code to speed up scripting and automation. Those teams often lack dedicated security staff and may not be familiar with version‑control best practices. An exposed credential can give an attacker direct access to cloud services, databases or internal APIs, potentially leading to data breaches, service disruption or financial loss. Because the leaked files are publicly searchable on GitHub, a malicious actor can harvest them with automated tools and target multiple organizations at once.

Practical steps to protect your codebase

• Review .gitignore rules: Ensure that .claude/settings.local.json is listed in both the global and each repository’s .gitignore file.
• Run secret‑scanning tools: Use GitHub’s secret scanning feature or third‑party scanners (for example TruffleHog or GitGuardian) on all repositories, especially after adding new AI tools.
• Audit existing commits: Search your GitHub history for the filename "settings.local.json" and remove any occurrences that contain secrets. Use git filter‑repo to rewrite history if needed.
• Limit automated approvals: Avoid using the “Yes, and don’t ask again” option for commands that include credentials. Require manual confirmation for any command that accesses sensitive resources.
• Rotate compromised secrets: If a secret was exposed, treat it as compromised. Regenerate API keys, change database passwords and update any dependent services.
• Educate developers: Conduct a short briefing on how AI tools store configuration files and the importance of keeping those files out of version control.

Long‑term best practices

Embedding secrets directly in code or configuration files is a known anti‑pattern. Adopt a secret‑management solution such as HashiCorp Vault, AWS Secrets Manager or Azure Key Vault. Store references to secrets in environment variables or configuration services, and keep the actual values out of source control. When using AI‑assisted tools, configure them to write temporary files to a location that is automatically excluded from Git. Finally, regularly review third‑party tool documentation for any changes to how they handle sensitive data, and adjust your policies accordingly.

By taking these steps, small teams can continue to benefit from AI development assistants while reducing the risk of accidental credential exposure.