A developer asks Claude Code to run a command. It may contain a database password or an API key, but instead of approving it every time, the developer selects Yes, and don't ask again.
It’s a convenient shortcut. But there’s an unexpected consequence, Claude Code can save the complete command, including any sensitive information it contains, in a local settings file and when that file makes its way into a public GitHub repository, credentials that were never meant to be shared can become visible to anyone.
Table of Contents
How a local settings file ended up on GitHub
When a developer selects Yes, and don’t ask again, Claude Code stores the approval as a rule in a file called .claude/settings.local.json. The rule can contain the original shell command, including any passwords or API keys passed along with it.
The file is intended to stay on the developer’s machine. Anthropic’s documentation says Claude Code adds it to the user’s global .gitignore file, which tells Git to leave it out of version control.
But there’s a catch. A global ignore rule doesn’t protect a file in every repository. If a project is cloned onto another machine or a folder becomes a Git repository later, that local protection may not be in place. The settings file can then be included in a commit and uploaded to GitHub.
In some cases, Apiiro’s researchers also found that Claude Code itself committed changes to the settings file without the developer explicitly doing so.
Researchers found thousands of exposed credentials
Apiiro’s investigation found more than 100,000 instances of Claude Code’s local settings file on public GitHub repositories. Among them, researchers identified around 1,100 files containing sensitive information, including API tokens, database passwords and private keys. The exposed credentials were linked to 63 different organizations.
A separate investigation by security firm GitGuardian found an even larger number. It identified 31,088 distinct secrets across 23,276 public GitHub repositories, of which 5,343 were still valid when detected.
blog.gitguardian.com+1
The two investigations used different methods. Apiiro examined files available in public repositories and their history, while GitGuardian continuously monitored public commits, allowing it to identify credentials that had since been deleted or removed from repositories. Its findings show that removing an exposed file doesn’t necessarily mean the credentials it contained are no longer accessible
You May Like: Open Source AI Tools for Creating, Coding and Getting More Done
What Anthropic says it’s doing about it
The issue has also been raised with Anthropic before. A Claude Code bug report dating back to August 2025 flagged the risk of sensitive settings files being exposed through Git. Other reports described cases where the file was not added to the global .gitignore or sensitive commands were saved elsewhere.
In a public Hacker News discussion, Claude Code creator Boris Cherny said the team was looking into ways to prevent the problem. He recommended using Claude Code’s auto mode and secret-scanning tools as safeguards, while acknowledging that sensitive commands could still end up in settings files.
He also suggested that developers use secret-scanning tools to detect exposed credentials before they reach public repositories. However, Apiiro’s research highlights a limitation: two popular scanners, Gitleaks and TruffleHog, failed to flag 215 of the roughly 1,100 secrets identified in the exposed Claude Code settings files.
That means relying on automated scanning alone may not be enough to catch every exposed credential.
AI coding tools create new places for secrets to leak
The incident is a reminder that AI coding tools can introduce security risks in places developers might not expect. A simple approval intended to save time can leave sensitive commands in a file that eventually becomes public. As AI tools take on more of the development workflow, their settings and permissions become part of the security equation, not just the code they help write.
