Claude Code exposes secrets when approved shell commands containing credentials are saved verbatim and the local permission file reaches a public repository. Apiiro found 1,122 current copies of the file on GitHub containing at least one real secret.

 

The November 5 disclosure separates the product behavior from the publication step: Claude Code writes the rule, while a developer or automated commit must add the file to Git. Anthropic says the file is intended to remain local and that its team is testing additional protections.

 

Apiiro's scan identified four immediate risks:

  • 1,379 distinct secrets in current public permission files.
  • Credentials in git history, transcripts and shared settings.
  • 215 affected files missed by two common scanners.
  • 63 organizations with a secret in a public allowlist.

 

Claude Code Exposes Secrets Through Permission Rules

Apiiro's research centers on Claude Code's permission workflow. When the coding agent proposes a shell command, a user can approve that run or choose not to be asked again. A persistent allow rule is then written to .claude/settings.local.json inside the project.

 

If the proposed command includes a password, API key or connection string, the literal credential can become part of that stored rule. Apiiro reproduced the behavior with Claude Opus 5.5 and Fable 5.1, concluding that it belongs to the Claude Code client rather than a particular language model.

 

The file does not become public merely because the user approves a command. Claude Code adds its path to the machine's global Git exclusions when it creates the file in a repository, which protects the common case. Exposure requires the file to be tracked and pushed, or copied through another publishing path.

 

That protection does not travel with the repository. Apiiro found gaps when a folder becomes a repository later, when a clone lands on another machine, or when the file is already tracked. In 539 of 1,105 traced repositories with a secret, a Claude-coauthored commit had changed the permission file.

 

Apiiro Finds 2,539 Credentials Across Agent Files

Apiiro counted 104,185 public copies of the local settings file across 103,617 GitHub repositories. Of those files, 1,122, or 1.1%, contained a credential matched to a known provider format or paired with a public host.

 

The current files held 1,379 distinct secrets: 636 provider keys and 743 passwords or tokens. The count included 379 database passwords, 122 Supabase service-role keys, 103 Supabase account tokens, 43 SSH credentials, 23 AWS keys and six private keys.

 

Every affected current file remained on its repository's default branch on November 2, according to Apiiro. In the median affected repository, the file had first been committed 217 days earlier. Seventy-four repositories had 211 forks carrying the same secrets.

 

The larger 2,539 figure includes credentials recovered from deleted-file history, shared Claude settings and saved agent transcripts. Those records spanned 1,994 repositories. Apiiro did not test whether every credential remained active, although one notified organization confirmed that its exposed key had been live.

 

Related Coverage

 

Anthropic Tests Protections as Scanner Gaps Persist

Apiiro updated its report on November 8 after Boris Cherny, Anthropic's head of Claude Code, responded publicly. The company is examining ways to prevent the behavior, including basic secret scanning and changes to auto mode, but no completed product fix was announced.

 

Traditional scanning did not catch the full dataset. Gitleaks flagged 564 of the 1,122 current files with a secret, while TruffleHog flagged 643. Both missed 215 because passwords embedded in ordinary command strings often lack the recognizable prefixes and random formats used by cloud keys.

 

The disclosure also connects with earlier public reports. Claude Code users had filed GitHub issues about credentials entering permission rules since August 2025. A separate 2026 issue documented permission approvals being written to a shared, tracked settings file instead of the intended local file in some VS Code extension sessions.

 

That issue was closed as a duplicate, and it does not establish how many of Apiiro's cases followed the same path. It does show that the boundary between local and shared agent configuration can vary with product state, repository history and the client being used.

 

Credential Rotation Must Precede Repository Cleanup

Deleting the visible file is insufficient after publication. Earlier versions remain in Git history, forks and clones, and cached credentials may still work. Apiiro recommends rotating every credential the file ever contained before removing tracked copies and cleaning repository history.

 

Developers can also inspect local and shared Claude settings for literal credentials, add the local file to each repository's own .gitignore, and use environment-variable references instead of typing secret values into commands. Pattern-based approvals reduce the chance that a full sensitive command becomes a permanent rule.

 

Security teams need a broader inventory than source files alone. Agent settings, transcripts, memory files, deployment notes and handoff documents can all preserve the commands an agent used. Pre-commit and continuous-integration checks should recognize passwords inside command syntax as well as conventional API-key formats.

 

The incident turns approval fatigue into a supply-chain problem. A convenience choice can produce durable machine-readable records, while ordinary repository workflows distribute them far beyond the laptop where the approval occurred. The most important control is keeping raw credentials out of agent-visible command text from the start.

 

Illustrative photograph: a laptop displaying source code in South Tangerang, Indonesia, photographed by Bayu Syaits and published May 7, 2026, under the Unsplash License. The image does not depict the affected repositories; it was cropped and resized.