The Pulse

Apiiro Finds Claude Code Approval Files Leaking Secrets on GitHub

Apiiro says 1,122 public copies of Claude Code's local settings file on GitHub hold real secrets, 1,379 in all, saved when developers chose "don't ask again". Boris of Anthropic's Claude Code team says the team is looking at fixes; the two

AI.info Team · Written with AI · fact-checked · 2026-11-09

Security company Apiiro says it found 1,122 public copies of a Claude Code settings file on GitHub that contain at least one real secret, adding up to 1,379 distinct passwords, keys and tokens. The file, .claude/settings.local.json, is where Anthropic's coding agent records the commands a developer has allowed it to run without asking again. When the approved command had a password typed into it, the password was stored with it in plain text.

The research was written by Apiiro's Shmulik Cohen and Matan Giladi. The company says it did not try any of the credentials, so it cannot say how many still work. One organisation it warned before publication told the researchers that its exposed key had been live.

How an Approval Becomes a Stored Password

Anthropic's own documentation describes the mechanism. A developer who picks "Yes, and don't ask again" at a shell-command prompt gets an allow rule recorded in .claude/settings.local.json, a file kept in the repository's top-level folder, and the rule then applies to later sessions in that project. As Apiiro describes it, the saved rule is sometimes a pattern such as a test command with a wildcard, and sometimes the exact command line, and in that case anything typed into it, a database password after PGPASSWORD= for instance, ends up in the file.

The documentation also says the file is meant to stay on the developer's machine. The first time Claude Code writes it in a repository that does not already ignore it, the tool adds a matching entry to the user's global git excludes file, and a developer who creates the file by hand is told to add it to .gitignore themselves.

Apiiro's argument, as reported by The Hacker News and iTWire, is that this protection lives in one person's git configuration on one computer. It does not travel with the repository to a fresh clone or a second machine, and it does nothing for a copy that git already tracks. The researchers say they reproduced the behaviour with Opus 5.5 and Fable 5.1, Anthropic's current models.

What the Scan Counted

Apiiro searched public GitHub between November 1 and 3, according to iTWire. The figures below are the company's, as the outlets that read its write-up report them:

• 104,185 copies of the local settings file, spread over 103,617 repositories;
• 1,122 of those copies, about 1.1%, holding at least one secret, for 1,379 distinct values;
• 379 database passwords, 43 SSH logins for public servers, 23 AWS keys and 42 tokens for GitHub, GitLab and npm among them;
• 2,539 distinct secrets across 1,994 repositories once older versions of the file, the shared .claude/settings.json that teams commit on purpose, and saved agent chat transcripts are added.

Deleting the file does not end the exposure. Earlier versions in git history held 734 secrets that no current copy contains. Apiiro counts 63 organisations among the owners, mostly software companies, including a database vendor whose own administrative cloud key was in one of them.

Apiiro's test for a secret was a value in a recognised key format, or a password or token placed beside a public server's address; an AI reviewer then had to confirm each one. iTWire, which notes that Apiiro sells application and agent security products, stresses that the totals are the company's findings and show an exposure, not a demonstrated breach.

Who Committed the Files

The two sides disagree over how the files reached GitHub. Boris of Anthropic’s Claude Code team, who posts as bcherny, replied in the Hacker News discussion of the research that the file is gitignored automatically when Claude creates it, and concluded that the exposed copies had been created by hand and checked in.

Apiiro's data points the other way for about half of the cases it traced. In 539 of the 1,105 repositories with a real secret that the researchers followed back, a commit that lists Claude as co-author changed the file. iTWire adds a caution of its own: that count does not prove Claude introduced or pushed every exposed credential.

The problem was not new to Claude Code's issue tracker. A bug report filed in August 2025 described approved commands with API keys and tokens being stored word for word in the local permissions list. According to The Hacker News, an automated bot closed it as "not planned" in January 2026 after 60 days without activity; iTWire cautions that the closing does not show the bug was ever fixed.

Anthropic's Response So Far

Anthropic's public reply came in his comments under the Hacker News post about the research. He opened with this:

Historically Claude Code has not done secret scrubbing (there are many good tools for that), but we are looking into what we can do to prevent this.

Boris (bcherny), Claude Code team, Anthropic, on Hacker News

In the same thread he said the team would prototype several approaches before shipping one, among them making auto mode catch such commands and adding basic secret scanning to the tool. He also urged users to switch from permission rules to auto mode, which he described as safer, on by default and free in all plans, and to turn on the secret scanning that GitHub and other code hosts offer. When another commenter pointed out that auto mode can also save an "always allow" approval, he replied: "Yeah good catch."

Auto mode relies on a classifier to judge which commands Claude Code may run without a prompt; AI.info covered the September release that made the server-side classifier the default for Claude API and Enterprise users and cloud deployments. The leak adds to a run of security stories around the tool, among them a tampered Claude Code extension on Cursor's marketplace.

Why Scanners Missed Many of the Files

Standard secret scanners caught only part of the problem. Run over the 1,122 files without their verification step, gitleaks flagged 564 and TruffleHog 643, and 215 slipped past both. Most of the misses were passwords embedded in ordinary command lines, after PGPASSWORD=, sshpass -p or mysql -p, which carry none of the vendor prefixes that scanners look for.

Apiiro also warns that the file is plain JSON on the developer's own disk, where malware can read it even if it never reaches GitHub. The Hacker News recalls that the Shai-Hulud worm ran TruffleHog over infected machines in September 2025.

The researchers' first recommendation is to rotate every credential the file has ever held before cleaning anything up, because forks, clones and git history keep old copies. After that: stop tracking the file with git rm --cached, list it in each repository's own .gitignore, refer to secrets through variables from a secrets manager instead of typing them into commands, and approve command patterns rather than single literal commands.