Security firm Apiiro says it found passwords, API tokens and other credentials in Claude Code settings files published in public GitHub repositories. The research identifies an exposure pathway in which a saved shell-command approval preserves sensitive information that subsequently enters a public repository. (apiiro.com)
The findings concern exposed credentials, not a demonstrated breach of every associated system. Apiiro says it did not test the credentials or contact the associated hosts. Anthropic has publicly acknowledged the concern and discussed possible safeguards, but the materials reviewed for this article do not establish that a fix has shipped. (gbhackers.com)
How an approval can preserve a secret
Anthropic’s documentation confirms that choosing “Yes, and don’t ask again” for a shell command saves an approval rule in code>.claude/settings.local.json/code>. This is a project-local settings file intended for an individual developer’s preferences and permissions, rather than settings deliberately shared with everyone working on a project. (code.claude.com)
The problem arises when that rule retains the command itself, including an embedded password or token. As Ars Technica reported on November 9, rules can be patterns, but commands are also saved as written. A convenience designed to avoid repeated permission prompts can therefore create another stored copy of a credential. (arstechnica.com)
Saving the rule and publishing it are separate events. This GitHub exposure pathway requires the credential-bearing file to enter a public repository; selecting persistent approval does not, by itself, make the credential public. That distinction limits the finding: it is not evidence that every Claude Code installation exposes secrets online. (apiiro.com)
Anthropic’s documentation says Claude Code adds the local settings file to the developer’s global Git exclusions when it first writes it. Apiiro identifies a gap between that machine-level protection and the repository itself: the exclusion does not travel with the project, leaving room for accidental publication when development environments change. (code.claude.com)
What the numbers actually count
The investigation reportedly examined 104,185 public copies of the local settings file across 103,617 repositories. Of those files, 1,122 contained 1,379 distinct secrets. Those figures describe the researchers’ public-file collection and findings—not the number of repositories successfully attacked or the prevalence of exposure across all Claude Code users. (gbhackers.com)
A larger figure, 2,539 distinct secrets across 1,994 repositories, includes repository history, shared settings and saved agent transcripts. It should not be described as the local-settings-only total. The reported findings involved individual developers and 63 organizations; that organizational count likewise does not establish 63 confirmed breaches. (gbhackers.com)
The absence of credential testing is important when interpreting those totals. The research establishes that sensitive-looking authentication material was publicly accessible, not that every value remained usable. Nor does public availability alone demonstrate that an unauthorized person used a credential to enter a system or retrieve data. (gbhackers.com)
Anthropic’s response—and its limits
In a public Hacker News response, Claude Code lead Boris Cherny said the team was investigating prevention options. His comments distinguished the intended behavior—keeping local settings out of source control—from the exposed files described in the research. That response acknowledges the concern without resolving how every reported file became public. (news.ycombinator.com)
Cherny also described potential approaches, including basic secret scanning and improvements involving auto mode, and said the team would prototype options before shipping something. These are prospective safeguards, not verification that the reported exposure pathway has been eliminated. The distinction matters for teams deciding whether an update alone resolves their existing exposure. (news.ycombinator.com)
A broader credential-security problem
Separate industry work illustrates why detecting these values is difficult. In an October 7 post, GitHub explained that provider-issued tokens may have recognizable prefixes, while an internal database password may have no identifying pattern. Its secret-detection work therefore uses surrounding code to help distinguish sensitive values from ordinary text. (github.blog)
GitHub also described adding its classifier to Copilot’s security-review tools. That is a comparable effort to catch credentials within development workflows, not evidence that those tools would detect every value in Apiiro’s collection. The practical question extends beyond whether a scanner exists to whether it recognizes the kinds of secrets a workflow preserves. (github.blog)
In separate research published November 5, Microsoft reported attackers using agentic tooling to search public repositories for exposed secrets and conduct follow-on activity. That report is not evidence of exploitation in the Claude Code cases, but it demonstrates why publicly accessible authentication material warrants attention even without a confirmed misuse report. (microsoft.com)
Microsoft’s general remediation guidance distinguishes removing a public secret from invalidating it: organizations should rotate exposed credentials, because deleting the original disclosure does not make a still-valid credential unusable. For teams assessing these findings, preventing another settings-file publication and addressing credentials already exposed are therefore separate security tasks. (microsoft.com)
