A Claude Code configuration file appeared in 1,122 public copies on GitHub with at least one password, token, or key, according to Apiiro’s investigation. The assistant can literally save a shell command when the user selects “Yes, and don’t ask again”; if the command contains a credential and the file is published, that credential is exposed.
Apiiro identified 1,379 distinct secrets in those copies of .claude/settings.local.json. The company did not check whether they were all still working, but one organization it notified confirmed that its key was still active. The expanded count, which includes Git history, shared configuration files, and agent conversation logs, totals 2,539 secrets across 1,994 repositories.
What Claude Code saves when remembering a permission
Claude Code usually asks for authorization before running shell commands. By accepting “Yes, and don’t ask again,” the user creates a rule that allows matching commands to run again without asking. Claude Code’s documentation says this approval is stored in the project’s local file, .claude/settings.local.json.
The rule preserves what was approved. Sometimes it is a pattern, such as npm test *; other times, it is a specific command. In the latter case, if someone typed a password or token directly into the command, the value may be saved in plain text along with the rule. Apiiro researchers reproduced the behavior with the Opus 5.5 and Fable 5.1 models.
The file is intended for a project’s personal settings, not for sharing with the team. Claude Code tries to keep it out of Git: when it first creates the file inside a repository, it adds it to the user’s global Git exclusions file. This protection applies to that person’s repositories on that machine, but it is not added to the project’s configuration.
The global exclusion also does not remove files that have already been added to version control. Apiiro notes that Claude Code does not automatically add .claude/settings.local.json to the project’s .gitignore. As a result, the rule does not travel with the repository and does not protect other collaborators or teams. Anthropic’s documentation also states that if the user creates the file manually, they must add it to .gitignore themselves.
The distinction between a local file and a shared one matters: .claude/settings.json is the project configuration a team can deliberately version, while .claude/settings.local.json is intended for one person’s personal preferences for that project. Apiiro also found secrets in the shared file, but at a lower rate.
1,379 secrets in public copies
Apiiro located 104,185 copies of .claude/settings.local.json in 103,617 public GitHub repositories. Of these, 1,122—around 1.1%—contained at least one secret. To classify a value as a secret, the researchers checked whether it matched known key formats or whether a password or token appeared alongside a public server address. An AI-based reviewer also had to support the classification.
More than a third of the secrets provided direct access to databases. The set included 379 database passwords, 43 SSH credentials for public servers, 42 GitHub, GitLab, and npm tokens, and 23 AWS keys. Apiiro also highlighted particularly high-impact examples: a cloud key with administrator permissions belonging to a database provider and the proprietary password for a medical records database.
The files belonged to 63 organizations, mostly software companies of various sizes. According to Apiiro, on the day it counted them, all files containing secrets were still present in the default branch of their repositories. In half of those repositories, they had been there for at least 217 days.
Git history adds other exposures that no longer appear in the current version: Apiiro found 734 additional secrets in older versions of files from 509 repositories. Often, the file had already been deleted, but the secret remained in the history. It also found 211 forks of 74 repositories that retained the same secrets as the originals.
The broader count includes 298 copies of .claude/settings.json containing secrets, among 76,011 shared files. Apiiro also added older history and agent conversation logs to reach 2,539 secrets across 1,994 repositories.
The history of reports and the limits of the investigation
The exposure was not newly discovered behavior. A Claude Code bug report filed on August 11, 2025, had already warned that commands approved with API keys and tokens were saved verbatim in settings.local.json. A bot closed that report on January 3 after 60 days of inactivity. iTWire reports that the closure was an automated maintenance action, not a technical resolution.
Apiiro says the four related reports it cites were closed by the same bot; the most recent was closed the day before its investigation was published. According to the company, Anthropic did not respond to any of them. Separately, security firm ironPeak described in February 2026 how it had found approved commands containing database passwords and API keys in a Claude configuration file that had been committed to a repository. It also published a tool for searching for secrets in agent configuration files and their history.
Apiiro collected public GitHub data between November 1 and 3, according to iTWire. Its classification combines formats and context with an AI review; it is not an independent check that every credential is valid. The researchers also did not test the keys they found or determine whether anyone had used them. The company did report that it notified affected organizations on November 2 and 3, and that one of them confirmed its exposed key was still active.
In 539 of the 1,105 repositories Apiiro was able to trace, a commit that included Claude as a co-author modified the file. This does not prove that Claude introduced or published all the credentials; it does show that file modifications could be part of commits attributed to the assistant.
Apiiro compared the documentation for 16 coding agents and confirmed that Claude Code was the only one that, by default, saved the full approved command in a project file. This comparison refers to the documented behavior the researchers analyzed, not proof that the other agents cannot expose secrets in other ways.
Rotate credentials before cleaning up Git
Apiiro’s central recommendation is to change all passwords, tokens, and keys that appeared in these files first, and then deal with cleanup. Deleting the current file does not remove previous Git versions, forks, or copies downloaded by other people. Rotation reduces the risk of an exposed credential continuing to grant access while those copies are reviewed.
To locate the problem, Apiiro recommends searching for .claude/settings.local.json and .claude/settings.json across the entire organization, and reviewing each repository’s history even if the file is no longer present. It also advises untracking the local file with git rm --cached .claude/settings.local.json, adding it to the repository’s .gitignore, and removing any rule containing a secret from the local copy.
The company recommends not typing literal credentials into commands. A rule can refer to a variable such as $DB_URL instead of saving the secret value; it also suggests authorizing command patterns rather than one-off commands. iTWire warns that assigning the password literally within an inline variable assignment would still leave the value in the saved text.
The search should not be limited to GitHub. Apiiro notes that the file is unencrypted JSON and could end up inside an npm package, a Docker image, a ZIP file, or a synced folder. It also recommends treating agent directories such as .claude/, .cursor/, .gemini/, and .specstory/, along with their memory files, as potential containers for secrets on machines and in repositories.
Standard detection tools also failed to find every case. Apiiro ran gitleaks and TruffleHog on the copies without using the tools’ verification step. Gitleaks flagged 564 of the 1,122 files containing secrets, and TruffleHog flagged 643; neither detected 215. According to the researchers, many misses involved passwords embedded in commands: expressions such as PGPASSWORD=, sshpass -p, or mysql -p can look like ordinary text rather than a key with a recognizable format.
For security teams, Apiiro proposes including these files in pre-commit and CI secret scans, including Git history, and checking that the scanner detects passwords inside commands, not just keys with known formats. It also recommends adding Claude Code’s local file to organizational .gitignore templates and reviewing credentials associated with public servers first.
The Shai-Hulud worm incident shows why Apiiro calls for reviewing development machines too: in September 2025, the malware ran TruffleHog on infected computers, and the scanner flagged more than half of the files as secrets. The current investigation does not establish that Claude Code credentials have been used. It does document that, in at least one reported case, a key was still active.
Sources: The Hacker News, Claude Code Docs, iTWire, NEXSIGHT CYBER WIRE
