Claude Code's 'don't ask again' leaked 2,539 secrets to GitHub. A fix-it checklist

Every coding agent asks permission before running a shell command, and every agent offers a way to stop asking. In Claude Code that option is "Yes, and don't ask again." Research published by application-security firm Apiiro and reported by The Hacker News on November 7 shows that choosing it saves the approved command, verbatim, into a file called .claude/settings.local.json inside the project. If the command contained a database URL with a password, an API token or an SSH login, that secret is now sitting in a file next to the code.

Claude Code adds the file to the user's global git excludes, but not to the project's .gitignore, so the protection does not travel with the repository. On another machine, or for a teammate, nothing stops the file being committed.

The numbers

Apiiro searched public GitHub and found 104,185 copies of the file across 103,617 repositories. About 1.1%, or 1,122 files, contained at least one secret, for 1,379 distinct secrets. More than a third opened databases directly: 379 database passwords and 122 Supabase service-role keys. There were also 43 SSH logins to public servers, some with root passwords, 42 GitHub, GitLab and npm tokens and 23 AWS keys. Sixty-three organisations were among the owners; most were individual developers.

Adding older versions of the file still in git history, the shared team-level .claude/settings.json, and saved agent transcripts, the total rose to 2,539 secrets across 1,994 repositories. Apiiro did not test whether credentials were live, but one organisation it notified confirmed its key still worked. In half the affected repositories the secret had been on the default branch for at least 217 days.

Two details should worry security teams more than the headline count. First, standard scanners did not catch most of this: Gitleaks flagged 564 of the 1,122 files and TruffleHog 643, and 215 slipped past both, because a password typed inside a shell command does not match the key formats scanners look for. Second, of 16 coding agents Apiiro compared, Claude Code was the only one confirmed to persist the full approved command in a project file by default.

Anthropic's response

Users had filed GitHub issues about this since August 2025; four were closed by an inactivity bot, the latest on November 6, without a reply. After publication, Claude Code head Boris Cherny said on Hacker News that the company is looking into it, that the tool "has not done secret scrubbing" historically, and that options include having auto mode intercept such commands or adding basic secret scanning. He also noted the file is gitignored on creation and suggested the exposed copies were committed manually. That is probably true and also beside the point: the default produced a secret-bearing file that most users did not know existed.

What to do today

Search every repository in your organisation, including history, for .claude/settings.local.json and .claude/settings.json. Treat any credential they have ever contained as compromised and rotate it before cleaning up; deleting the file does nothing for forks and clones. Untrack the file with git rm --cached and add it to the project .gitignore and to your organisation's .gitignore templates. Then change habits: reference secrets as environment variables ($DB_URL) rather than typing them into commands, and approve command patterns such as Bash(npm run:*) instead of literal commands.

For security teams, the durable fix is scope. Agent folders (.claude/, .cursor/, .gemini/) and agent memory or transcript files are secret-bearing in the same way .env is. Put them in pre-commit hooks and CI scanning with history enabled, and add rules for passwords embedded in command strings, which is the pattern that beat both open-source scanners.

What to watch

Whether Anthropic ships a scrubbing or pattern-only default, and whether other agents quietly change theirs. Apiiro's comparison of 16 agents is a useful baseline; expect follow-up research on the other 15, because the broader lesson, that agent convenience features are also data-handling features, is not specific to one vendor.