Claude Code don't-ask-again rules left secrets in public settings files

Choosing "Yes, and don't ask again" in Claude Code can write a credential into a project settings file that later reaches public GitHub, including history and forks.

Apiiro researchers Shmulik Cohen and Matan Giladi reported on November 5, 2026 that the choice saves the approved command string, secret included, as an allow rule in .claude/settings.local.json inside the project folder. Nothing in the repository marks that file private, so a later commit can publish it with the rest of the code. The firm updated the post on November 8 with Anthropic's response. iTnews reported the same public counts on November 9.

Apiiro found 104,185 copies of the file across 103,617 repositories. Of those, 1,122 files, 1.1 percent, held a real secret: 1,379 distinct values in the current copies. Adding git history, the shared .claude/settings.json that teams commit on purpose, and agent chat transcripts saved in repositories, the total was 2,539 distinct secrets in 1,994 repositories.

In the current files, more than a third opened a database directly: 379 database passwords and 122 Supabase service-role keys. Apiiro also counted 103 Supabase account tokens, 43 SSH logins for public servers, 42 GitHub, GitLab, and npm tokens, 23 AWS keys, and 6 private keys. The 1,379 split into 636 provider-format keys and 743 passwords or tokens next to a public host.

The firm said it did not use or test any credential and did not contact hosts. In its count, a real secret matches a known provider format or sits on the same line as a public host. It is not a credential proven still valid. One organization Apiiro notified confirmed that an exposed key had been live.

How the allow rule is written

Claude Code asks before it runs a shell command. A developer who picks "Yes, and don't ask again" gets the command run and a permission rule written so the prompt does not come back. The rule is the command string itself. Apiiro said this is Claude Code's behavior, not the model's, and reproduced it with Opus 5.5 and Fable 5.1.

The file is meant to stay on the developer's machine. When Claude Code creates it inside a git repository, it adds the path to the developer's global git ignore list, not to the repository's own .gitignore. That covers the common case. It does not cover a folder that becomes a repository later, a clone on another machine, or a file someone has already committed.

If the file is already tracked, Claude Code treats the copy as repository-supplied. The user is not told, and the next approval is appended to the tracked file.

The agent often commits the file itself. In 539 of 1,105 repositories with a real secret that Apiiro traced, a commit co-authored by Claude changed the file. Those commits name models from Sonnet 4.5 through Opus 5.5. Claude Code's commit instructions tell the model not to commit .env or credentials.json. Its settings file is not on that list.

What stayed public

Most of the secrets belonged to individual developers. Sixty-three organizations also had a real secret in a public allow list, from student and hackathon groups to startups, software agencies, and established vendors. Cases checked at pinned commits included a database vendor's own cloud API key with manage access and no expiry claim, a production Azure Postgres password, a Square production access token, and the owner password for a medical-records application's cloud database. Some of the SSH entries were root passwords.

Every current copy with a real secret sat on its repository's default branch on November 2, 2026. In the median repository with a real secret, the file was first committed 217 days earlier. In 118 repositories, the first commit was more than a year before. Forks copied the exposure: 211 forks of 74 repositories carried the same secrets. Deleting the current file does not clear history. Earlier versions held 734 real secrets, in 509 repositories, that appear in no current copy.

Generic scanners missed a large share. Of the 1,122 files with a real secret, gitleaks flagged 564 and TruffleHog 643. Two hundred fifteen were flagged by neither. Apiiro said the gap is passwords inside commands, which lack a recognizable provider key format.

What Anthropic said

Apiiro said it shared the research with Anthropic before publication, and reported each organization case to its owner on November 2 and 3.

Boris Cherny, head of Claude Code, replied on Hacker News on November 7, according to Apiiro's November 8 update and to iTnews on November 9. This article did not open that thread, so the remarks are as those two reports quote them.

Cherny said that historically Claude Code "has not done secret scrubbing," because "there are many good tools for that," but that the team is "looking into what we can do to prevent this." He said the team would prototype approaches before shipping anything, including "making sure auto mode catches this" and "building in basic secret scanning."

When a reader noted that the same exposure can happen in auto mode, Cherny replied, "Yeah good catch." He also said Claude Code gitignores the file when it creates it, so in his view the exposed copies had been created manually and checked in. He recommended auto mode over permission rules, and the secret scanning that GitHub and other hosts offer. iTnews treated the auto-mode reply as a sign those approaches might not fully close the gap.

If the file is yours

Rotate any credential the file has ever held before cleaning up. Removing it does not clear git history, forks, or clones. If it is tracked, untrack it and add it to the repository's own .gitignore. Even if it was never committed, delete allow rules that contain a secret. Do not type secrets into commands the agent will record. Approve command patterns rather than literal command lines.

If you use Claude Code, check whether .claude/settings.local.json is tracked in repositories you control, and rotate anything that file has held. Apiiro's write-up has the full counts and the November 8 note on Cherny's reply. iTnews has the independent November 9 account of the same figures.