A local settings file meant to remember approved commands can become a public security problem if it ends up in a GitHub repository. Researchers at Apiiro found more than 100,000 cases in which Claude Code’s local settings file appeared in public repositories, with about 1,100 files containing secrets such as API tokens, database passwords or private keys.
How approval choices can preserve sensitive commands
Claude Code lets users approve automated shell commands. If a user selects “Yes, and don’t ask again,” the approval is recorded as a rule in the local .claude/settings.local.json file. The rule may use a pattern, but the command itself is often saved as written.
That matters when a command includes sensitive information. In that case, the settings file can preserve the secret alongside the approval rule. The file is generally a local concern as long as it stays on the user’s computer, but its contents can travel if the file is shared.
Anthropic’s documentation says the settings file is added to the developer’s global .gitignore list. That protection can help prevent routine sharing, but it is not reflected at the repository level. A file can therefore be exposed if a repository is cloned to another machine or if a folder becomes a repository later.
Why a local safeguard may not be enough
A global ignore rule depends on the settings of a particular developer’s machine. Repository-level protection is absent, so the file may not be excluded in every situation where the project is tracked or transferred. Apiiro also writes that Claude Code itself will, in many cases, commit changes to the settings file without the user’s input.
The researchers found over 100,000 public GitHub cases involving the local settings file. About 1,100 of those contained secrets, and the affected repositories belonged to 63 different organizations. The figures show two different scales of exposure: many files were public, while a smaller subset contained credentials or keys.
Removing an exposed file from the original repository may not end the risk. The source reports that secrets can remain in forks of the project if they are not also addressed there. A credential discovered in public code may therefore need attention even after the visible file is removed.
Reports and responses point to open questions
The issue had been raised in a Claude Code bug report as far back as August of 2025. Other reports described cases where the settings file was not added to a user’s ignore list, or where Claude Code could save sensitive commands in another file that was not protected from Git sharing. The reports were closed without action after 60 days of inactivity.
In a Hacker News comment thread over the weekend, Claude Code’s Boris Cherny said the team is “looking into what we can do to prevent this.” He said these files should pretty much never be checked into source control and that cases appeared to arise when “the files were manually created and checked in.”
Cherny recommended Claude Code’s auto mode, which uses classifiers to route routine permission prompts without manually maintained allow and deny lists. But after a user pointed out that sensitive commands could still be saved to settings files in auto mode, Cherny called it a “good catch” and said the team was “thinking through what we can do to improve this.”
Secret scanning can help, but has limits
Cherny also recommended secret scanners that search files for sensitive information and scrub it out. The team was considering adding this kind of scanning directly to Claude Code in the future, according to the source.
Scanning did not catch every secret in Apiiro’s findings. The researchers reported that 215 of the roughly 1,100 public secrets were not flagged by two popular tools, gitleaks and TruffleHog. That means a clean scan from those tools alone cannot establish that a settings file contains no exposed credentials.
For teams using Claude Code, the practical issue is the route from an approved command to a saved rule, then from a local file to a public repository. The source describes secret scanning as a useful measure, while also showing why teams may need to review settings files and investigate credentials that have already been exposed.