Claude Code Leaked 2,539 Secrets to Public GitHub Repositories

By Nathan Brooks

Apiiro found 2,539 distinct real secrets across 1,994 public GitHub repositories, tracing the exposure to Anthropic's Claude Code developer tool and its “Yes, and don't ask again” approval prompt. Apiiro published the research on November 8 after scanning 104,185 public copies of .claude/settings.local.json across 103,617 repositories on GitHub's default branches as of November 2.

After Apiiro shared the research, Boris Cherny, Anthropic's Head of Claude Code, responded on Hacker News on November 7 and through the weekend. He acknowledged: “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.”

Cherny said the team planned to prototype “making sure auto mode catches this, building in basic secret scanning.” He also acknowledged that auto mode can present the same problem when it asks about a sensitive command.

How the secrets escaped

According to Apiiro, Claude Code proposes the full command, credential included, when a developer asks it to run a database migration or API call. If the developer selects “Yes, and don't ask again,” the tool saves that exact command as an allow rule in .claude/settings.local.json at the repository root.

Apiiro said Claude Code adds the file to the user's global gitignore when it creates it inside a Git repository. That protection does not travel with the project if the folder later becomes a repository, the code is cloned on another machine, or the file was already tracked.

In 539 of the 1,105 repositories Apiiro traced with secrets, a commit co-authored by Claude Code itself had modified the file. The finding placed the coding agent in the commit trail of nearly half of the traced secret-bearing repositories.

Scale and dwell time

• 1,122 files: Apiiro said 1,122 of the scanned files, or 1.1%, contained a real secret. They held 636 provider-formatted keys and 743 passwords or tokens paired with public hosts.
• 1,160 more secrets: Apiiro found them in Git history, shared settings.json files that teams committed intentionally, and agent chat transcripts saved in repositories.

Apiiro's research identified exposed credentials including:

• A database vendor's own admin-level cloud key with no expiry.
• A production Azure Postgres password.
• A Square production access token.
• The owner password for a medical-records database.

Apiiro said 63 organizations were affected, ranging from student groups to established vendors. In the median repository with a secret, the file had been committed 217 days earlier, while 118 repositories had committed it more than a year earlier.

Apiiro disclosed the findings to each affected organization on November 2-3. Anthropic received the disclosure through the company's disclosure channels.

Why scanners missed most files

Apiiro said standard secret scanners look for known key formats, including prefixes such as sk- or long random strings. Many exposed credentials instead sat inside command lines: PGPASSWORD=, sshpass -p, mysql -p, and bearer headers in curl calls.

Apiiro ran Gitleaks and TruffleHog over all 104,185 files. The results exposed a shared blind spot:

• Gitleaks flagged 564 of the 1,122 secret-bearing files.
• TruffleHog flagged 643.
• Neither tool caught 215 files.

The same pattern appeared in other agent-generated files. Apiiro found secrets in 298 shared settings.json files, 120 transcript files, nine memory files, 33 handoff notes, and nine Copilot settings files.

Prior warnings and Anthropic's rationale

Apiiro reported that GitHub issues describing the mechanism date to August 2025: #5544, #11982, #13106, and #91270. It said none received a reply from Anthropic, and three were closed automatically as inactive or duplicates.

Independent researchers ironPeak in February 2026 and Lakera in April 2026 also found credentials in Claude Code settings files inside npm packages and repositories. A separate GitHub issue, #87647, said more than 6,000 issues labeled “has repro” had auto-closed since March 2026, including security-relevant #13106, which led to the Apiiro disclosure.

Cherny argued that .claude/settings.local.json is designed to remain local and that exposed copies were manually created and checked in. He cited Anthropic documentation stating that the file is gitignored when created. He recommended using auto mode over permission rules and enabling secret scanning on GitHub and other hosts.

What should developers and security teams do now?

Apiiro's mitigation guidance focuses on finding, rotating and preventing embedded credentials:

• Search GitHub organizations for .claude/settings.local.json and .claude/settings.json, then check Git history for deleted copies.
• Rotate every credential those files have ever held.
• Replace secrets typed directly into commands with environment variables, so the allow rule records $DB_URL rather than the secret.
• Treat .claude/, .cursor/, .gemini/ and .specstory/ folders as secret-bearing, and add them to pre-commit and CI scanning with rules that catch passwords inside commands.
• Add .claude/settings.local.json to organizational gitignore templates.

For organizations using Claude Code, the practical change is that “don't ask again” must be handled like credential storage, not merely workflow automation. Until Anthropic prototypes the proposed safeguards, Apiiro's findings make history searches and credential rotation necessary because a global ignore cannot protect a tracked or cloned file.