Anthropic Responds After Apiiro Finds Suspected Credentials in 1,122 Public Claude Code Settings Files

Anthropic is investigating ways to prevent Claude Code from saving secrets in permission rules, following Apiiro’s research into credentials exposed in public GitHub files. Apiiro updated its research on November 8, 2026 with a November 7 response from Boris Cherny, Anthropic’s head of Claude Code. Cherny acknowledged that auto mode can also encounter the problem.

The study, originally published on November 5, suspected credentials in 1,122 of 104,185 public copies of .claude/settings.local.json. Counting git history, shared settings and saved agent transcripts, Apiiro reported 2,539 distinct suspected credentials in 1,994 repositories. The researchers did not test credential validity; these counts do not establish that the credentials were live or usable.

How an approval becomes a leak

Claude Code asks before it runs a shell command. When a developer asks it to check a staging database or call an API, the proposed command often carries a credential pulled from a local config file. If the developer picks “Yes, and don’t ask again”, Claude Code runs the command and saves a permission rule to .claude/settings.local.json in the project folder. Apiiro’s point is that the rule is the command string itself, so a password typed after PGPASSWORD=, sshpass -p or mysql -p is saved verbatim.

The file is meant to stay local. Apiiro says Claude Code adds it to the developer’s global git ignore list when it creates the file inside a repository, but never to the repository’s own .gitignore. That protection does not travel with the project. It misses clones on other machines and files someone already committed. Once a copy is tracked, Apiiro says, Claude Code’s debug log notes that gitignore rules no longer apply, but the user is not told and new approvals keep being appended.

The model often commits the file itself. In 539 of the 1,105 repositories with a suspected credential that Apiiro traced, a commit co-authored by Claude changed it. Apiiro says it reproduced the behavior with Opus 5.5 and Fable 5.1, and describes it as a property of the Claude Code tool, not of any one model.

What was exposed

Apiiro counts 1,379 distinct secrets in the current settings files: 636 provider keys and 743 passwords or tokens paired with public hosts. More than a third are database-access credentials, including 379 database passwords and 122 Supabase service-role keys. The list also includes 43 SSH logins, some of them root passwords, plus 23 AWS keys.

Most belong to individual developers, but 63 organizations are affected. Apiiro’s cases, which it does not name, include a database vendor’s own cloud API key with manage access, a production Azure Postgres password at a B2B startup, a Square production token at a software agency, and the owner password for a medical-records app’s database. Apiiro says it notified each organization on November 2 and 3, 2026.

Larger files leak more. Apiiro reports that one in ten settings files over 8 KB holds a suspected credential, against fewer than one in 500 under 500 bytes. Deleting the file does not help: earlier versions hold 734 secrets in 509 repositories that appear in no current copy, and 211 forks of 74 repositories carry the same secrets.

Why scanners miss it

Apiiro ran gitleaks and TruffleHog over all 104,185 files. Of the 1,122 with a suspected credential, gitleaks flagged 564 and TruffleHog 643, and 215 were flagged by neither. The gap, Apiiro says, is passwords inside ordinary command lines, which do not match the provider key formats the scanners look for. The same pattern turned up in the shared .claude/settings.json (298 files with secrets) and in agent transcripts and memory files.

Users have reported the mechanism in Claude Code GitHub issues since August 2025, starting with issue 5544. Apiiro notes that none got a reply from Anthropic and three were closed automatically.

Anthropic’s response and the fix list

On Hacker News on November 7, Cherny wrote that “Historically Claude Code has not done secret scrubbing,” adding that the team is “looking into what we can do to prevent this.” He named options it plans to prototype, including making auto mode catch the problem and building in basic secret scanning. He also said that, in his view, the exposed copies were likely created by hand and checked in, and recommended auto mode over permission rules plus host-side secret scanning, while acknowledging that auto mode can also encounter this problem.

Apiiro’s guidance for developers is to untrack the file with git rm --cached, add it to the repository’s own .gitignore, rotate every credential it has ever held, reference secrets as environment variables such as $DB_URL, and approve patterns like Bash(npm run:*) rather than literal commands. For security teams, it recommends treating .claude/, .cursor/, .gemini/ and similar agent folders like .env files, and tuning scanners to catch passwords inside commands.