Claude Code's 'Don't Ask Again' Exposed 2,539 Secrets on GitHub

When Claude Code asks permission before running a shell command and the developer clicks "Yes, and don't ask again," the tool saves an allow rule to .claude/settings.local.json in the project folder. If the command contains a secret — a password, an API key, an SSH login — that secret gets written into the JSON file in plain text. Security firm Apiiro published the findings on November 8 after scanning public GitHub for exposed copies of this file.

The results were stark: 104,185 copies of the settings file across 103,617 repositories. Of those, 1,122 files held at least one real secret — 1,379 distinct secrets total. When Apiiro included older file versions, shared settings, and chat transcripts, the count rose to 2,539 secrets across 1,994 repositories.

The exposed secrets paint a picture of production credentials left in public view. Anthropic's head of Claude Code, Boris Cherny, addressed the issue on:¹ Apiiro found 379 database passwords, 122 Supabase service‑role keys, 43 SSH logins (some with root access), 42 GitHub, GitLab, and npm tokens, and 23 AWS keys. As Apiiro detailed in its report, the haul included a database vendor's own cloud API key with management access, a software agency's production Square token, and the owner password for a medical‑records app's cloud database.

"More than one third opened a database directly," Apiiro noted. The firm did not test whether the credentials were still active, but one notified organization confirmed its key was live. Most affected files belonged to individual developers, but 63 organizations were also impacted, from student groups to established vendors.

Anthropic's Boris Cherny pointed out on ¹ that Claude Code gitignores the settings file on creation, suggesting the exposed copies were manually created and checked in. But Apiiro's data tells a more complicated story: in 539 of the 1,105 repositories with a real secret that Apiiro traced, a commit co‑authored by Claude changed the file, as Apiiro found. As one Apiiro researcher noted on,¹ "Often Claude commits the file itself."

This means the agent that created the problem is sometimes also the agent that committed the evidence to GitHub. Developers who rely on Claude Code's gitignore as a safety net should not assume it will catch every exposure — especially when Claude itself is making commits as part of a coding workflow.

Conventional secret‑scanning tools offered patchy protection. Of the 1,122 files with a secret, gitleaks flagged 564 and TruffleHog flagged 643, but 215 files slipped past both tools. This gap means developers who rely on standard CI/CD scanning may have a false sense of security about their Claude Code settings files.

The risk extends beyond public GitHub. Malware has already hunted for these files: the Shai‑Hulud npm worm ran TruffleHog over victims' files in September 2025, as iTnews reported. In April 2026, Check Point‑owned Lakera found credentials in 33 such files across 30 npm packages, showing the exposure vector has been known — and exploitable — for months.

Anthropic is exploring several mitigations,:¹ prototyping an auto mode to catch commands with embedded secrets, and building basic secret scanning into Claude Code. Cherny acknowledged on ¹ that these may not fully solve the problem. When a reader pointed out the same exposure could occur in auto mode, Cherny wrote on:¹ "Yeah good catch."

The core issue is architectural: Claude Code stores approved commands as literal strings in a project file. Any fix that doesn't change this — by, for example, hashing commands or storing only wildcard patterns — will leave a residual risk. For now, the safest approach is to never type secrets into Claude Code commands. Use environment variables, approve patterns not literal commands, and ensure .claude/ is in your global gitignore. And rotate any credentials that ever touched a settings.local.json file.