Claude Code’s “Don’t Ask Again” Button Has Been Writing Passwords to Disk

Claude Code asks permission before it runs most shell commands. Pick “Yes, and don’t ask again” on one of those prompts and the tool writes an allow rule for that command into a file called .claude/settings.local.json, so it won’t ask you a second time. If the command you approved had a password or API token typed into it, as curl requests and database connection strings often do, that secret goes into the file too, in plain text, verbatim.

That mechanism is now responsible for one of the larger unforced credential leaks of the year. Application-security firm Apiiro searched public GitHub between November 1 and 3, 2026 and found 104,185 copies of .claude/settings.local.json sitting in 103,617 repositories, according to Apiiro’s research as reported by The Hacker News. Of those, 1,122 copies held at least one real secret, 1,379 distinct ones in the files as they currently stand. Widen the search to older file versions, the shared settings.json teams commit on purpose, and saved agent chat transcripts, and the count rises to 2,539 secrets spread across 1,994 repositories, as Ars Technica reported. Ars, drawing on the same research, put the number of secrets in the current files at “about 1,100” from 63 organizations, a rounder figure than Apiiro’s own 1,122/1,379 split but consistent with it.

Why the sandbox leaks #

Anthropic’s own documentation for Claude Code’s settings files spells out the intended protection: “The first time Claude Code writes the file in a git repository that doesn’t already ignore it, it adds **/.claude/settings.local.json to your global git excludes file, so the file stays out of your commits in every repository.” That’s a real safeguard, but it has two gaps. It’s keyed to the user’s machine, not the repository, so cloning a project to a second computer, or letting a teammate check out the same folder, carries no such protection with it. And it only applies once Claude Code itself has written to the file; if a developer creates .claude/settings.local.json by hand before that happens, nothing ignores it automatically. The docs say so explicitly: “If you created the file by hand and Claude Code hasn’t written to it yet, add it to .gitignore yourself.”

How a shell secret ends up on GitHub Apiiro's account of the leak path

Based on Apiiro, via The Hacker News Apiiro’s breakdown of the 1,379 current secrets: 379 database passwords, 122 Supabase service-role keys, 43 SSH logins (some with root access), 42 tokens for GitHub, GitLab or npm, and 23 AWS keys, among others, per The Hacker News. The firm says it did not systematically test whether the credentials still worked, but at least one notified organization confirmed an exposed key was still live. Among the examples it cites: a database vendor’s own admin-level cloud key, a production Azure Postgres password, a Square production token, and the owner password of a medical-records database.

Persistence makes the exposure worse than a snapshot count suggests. Every file with a secret that Apiiro found was still sitting on its repository’s default branch, not some abandoned feature branch, and in roughly half of the affected repositories the file had been there for at least 217 days. Deleting the file from the current tree doesn’t close the leak either: Apiiro found another 734 secrets in older, deleted versions of the file across 509 repositories, still readable in git history, plus 211 forks of 74 repositories carrying the same secrets copied straight from the originals they forked.

Not a model problem, a tool default #

Apiiro reproduced the same storage behavior on Anthropic’s current Opus 5.5 and on a competing model it calls Fable 5.1, concluding the leak is a property of how Claude Code manages permissions, not of the underlying language model making the call. The firm says it compared the documentation of 16 coding agents and found Claude Code to be the only one confirmed to write a fully approved shell command to a project file by default. That’s a narrower claim than it sounds: it describes default, documented behavior across competitors’ docs, not an independent test of what each agent actually writes to disk in practice.

Existing secret-scanning tools didn’t catch everything either. Of the roughly 1,100 files with secrets, gitleaks flagged 564 and TruffleHog flagged 643, per Apiiro’s count reported by The Hacker News; 215 secrets were missed by both. The two scanners mostly look for key formats specific to a cloud provider or token scheme; a database password inline in a shell command, with no distinctive prefix, is harder to pattern-match than an AWS key starting with “AKIA”.

The underlying behavior isn’t new. A GitHub issue filed on August 11, 2025 described the exact mechanism, a bash command with an API key or Jira token getting stored verbatim in the permissions.allow array, and asked Anthropic to redact credentials before saving the rule. No maintainer responded. A stale-issue bot flagged it after 30 days, auto-closed it “not planned” after 60, and the thread was locked on January 10, 2026. Apiiro says it found four such reports going back to August 2025 describing the same root cause.

.claude/settings.local.json is meant to stay local. This is not a file you should check into source control. We automatically gitignore it when Claude creates the file, so in this case the files were manually created and checked in.

That’s Boris Cherny, Anthropic’s head of Claude Code, responding on Hacker News after the research went public, as quoted by multiple outlets covering the thread including iTnews. Apiiro’s own data complicates the “manually created and checked in” framing: among the 1,105 repositories it traced with a real secret, 539 had a commit to the settings file co-authored by Claude itself, not a human pasting the file into git by hand. Cherny also said, “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,” and recommended developers switch to Claude Code’s auto permission mode and keep GitHub’s own secret scanning turned on regardless of which coding agent they use. When a commenter pointed out that auto mode can still save a command containing a secret to the settings file, Cherny replied, “Yeah good catch,” and said Anthropic is prototyping detection for that case along with basic built-in secret scanning, while cautioning neither is a complete fix.

Apiiro’s own remediation list, for anyone who finds the file in their history: rotate every credential it has ever held before cleaning anything up, since deleting the file leaves old secrets readable in git history, forks, and clones; run git rm --cached .claude/settings.local.json and add it to the repository’s own .gitignore, not just the global one; and prefer approving reusable patterns, like Bash(npm run:*), over approving one-off commands that happen to carry a secret inline. For security teams, it recommends treating agent configuration folders generally, .claude/, .cursor/, .gemini/, .specstory/, as sensitive as .env files in CI scanning, since the same inline-credential pattern isn’t unique to Claude Code’s settings file. The company says it disclosed the findings to Anthropic before publishing.

Apiiro’s write-up follows other recent findings about the fragility of Claude Code’s extension and plugin surface, including a backdoored Claude Code extension served through Cursor’s own store to up to 5,000 users. The common thread across both is that the tool’s convenience defaults, auto-approval here, a frictionless install path there, outrun the guardrails built to contain them. What isn’t yet public is how many of the 1,379 currently exposed credentials Apiiro or Anthropic has gotten organizations to rotate, or whether GitHub’s own secret-scanning partnership program, which some of these token formats should trigger automatically, caught any of them before Apiiro did.