enzosoler.comreviews 08bench 9 devices
Published

Claude Code's "don't ask again" file leaked 1,379 secrets on GitHub: rotate keys before you delete it

Illustration: a laptop on a dark desk beside a lamp and a mug, with a stream of small brass keys drifting from its keyboard out through an open window into the night
Image: AI-generated illustration (Google Gemini)

Apiiro says 1,122 public copies of Claude Code's .claude/settings.local.json hold at least one password, token or key, saved when a developer approved a command with "Yes, and don't ask again." If you use Claude Code, check that file in every repo, rotate anything it ever held, then remove it from git history.

If you use Claude Code, open .claude/settings.local.json in every project you have pushed to GitHub and read the allow list. When you approve a shell command with “Yes, and don’t ask again,” Claude Code can save that exact command in the file, including any password or token you typed into it. Security firm Apiiro says it found 1,122 public copies of the file holding at least one live-looking secret, according to The Hacker News. If yours holds one, rotate it first. Deleting the file does not remove it from git history or from forks.

What Anthropic’s docs confirm

The behavior itself is documented. Claude Code’s permissions page says “Yes, and don’t ask again” on a shell command saves the approval “permanently per repository and command.” The settings page says those local rules live in .claude/settings.local.json, and that Claude Code adds the file to your global git excludes the first time it writes it.

That protection lives in one person’s git config on one computer. It never goes into the project’s own .gitignore, so it does not travel with the repo, and it does nothing for a file that was already committed. A teammate on a fresh laptop, a CI job, or a manual git add -A can still commit it.

When the approval is a pattern such as npm test *, nothing sensitive is saved. When Claude Code offers the exact command, every character is saved in plain text, including PGPASSWORD=..., sshpass -p ... or an Authorization header.

What Apiiro found

These numbers come from Apiiro’s research as reported by The Hacker News. We could not open Apiiro’s own write-up, so treat them as the researchers’ figures:

  • 104,185 public copies of the file across 103,617 GitHub repositories.
  • 1,122 copies, about 1.1%, hold at least one secret, for 1,379 distinct secrets.
  • More than a third open a database directly, including 379 database passwords. Others include 43 SSH logins, 42 GitHub, GitLab and npm tokens, and 23 AWS keys.
  • 63 of the owners are organizations, mostly software companies.
  • Older versions of the file add 734 more secrets across 509 repos, and 211 forks carry the same secrets as the originals.
  • In 539 of 1,105 traced repos, a commit listing Claude as co-author changed the file.

Apiiro did not test whether the secrets still work. One company it notified this week confirmed its key had been live. Common scanners miss many of these: of the 1,122 files, gitleaks flagged 564 and TruffleHog 643, mostly because a password inside a command line doesn’t match a known key format.

Users have reported the behavior before. A GitHub issue from August 2025 described approved commands with API keys stored word for word in the file. Apiiro says that report and three related ones were closed by an automated bot, with no reply from Anthropic. We found no public response from Anthropic to the research as of November 7.

What to do this week

  1. Search your repos. On GitHub, search your organization for path:.claude/settings.local.json. Locally, run git log --all -- .claude/settings.local.json in each project to see whether the file was ever committed.
  2. Read the allow rules. Look for passwords, tokens, connection strings, -p flags and auth headers inside saved commands. Check .claude/settings.json too: teams commit it on purpose, and Apiiro found secrets in 298 copies.
  3. Rotate first. Change every credential the file has ever held, including ones in old commits. Treat a secret in a public repo as already copied.
  4. Then clean up. Remove the file, add .claude/settings.local.json to the project’s .gitignore, and purge it from history if the repo is public. Check forks you control, npm packages (npm pack --dry-run), Docker images and zip exports.
  5. Change the habit. Pass secrets through environment variables or a secrets manager so the approved command never contains them, and approve commands that carry credentials once instead of permanently.

If you manage a team on Claude Code, put the .gitignore line in your repo templates now. It costs one line and closes the gap the global exclude leaves open. For more on what leaked AI and cloud keys cost, see how stolen cloud keys ran up $1 million in AI bills and how Northflank asked customers to rotate AI API keys.

Teams that commit Claude’s changes by default carry the most risk

The co-author figure is the part that should worry engineering leads. If an agent stages and commits its own work, a file that one person’s git config would have ignored can land in a shared repo through another machine. A backdoored Claude Code extension in Cursor on October 30 pointed the same way: coding agents now touch credentials and commits directly, so code review has to cover the agent’s config files as well as the code it wrote.

One email when a review goes up. Unsubscribe from any of them.