Claude Code Secrets Leak: 2,539 Credentials Found on Public GitHub

If you have ever clicked "Yes, and don't ask again" in Claude Code while running a command that held a password, that password may be sitting in a plain text file in your repository. Security firm Apiiro says that file has ended up on public GitHub thousands of times, and its research counts 2,539 exposed secrets across 1,994 repositories. The Claude Code secrets leak, first reported by The Hacker News on November 7, is not a breach of Anthropic's systems. It is a side effect of how the coding tool remembers your approvals, combined with how easily that memory gets committed.

Here is who is exposed, what is in those files, and the steps worth taking today.

How one approval click turns into a public password

Claude Code asks before it runs shell commands. When you pick the "don't ask again" option, it saves a permission rule so it can run the same command later without asking. According to the tool's own permissions documentation, those rules land in a file called .claude/settings.local.json at the root of your project.

The catch, per Apiiro's findings as reported by The Hacker News, is that the rule stores the full command exactly as it was approved. If that command was a database connection string with the password inline, or a curl call carrying an API token, the secret is saved word for word.

Claude Code does try to add the file to your global git excludes. It does not add it to the project's own .gitignore, according to the report. So on a new machine, in a CI runner, or for a teammate with a different git setup, the file can slip into a commit and then into a public repo.

What Apiiro found in public repositories

The researchers scanned public GitHub and reported these figures:

• 104,185 public copies of .claude/settings.local.json across 103,617 repositories
• 1,122 of those copies held at least one secret, adding up to 1,379 distinct secrets
• 734 more secrets sat in older versions of the file still visible in git history
• 298 secrets turned up in the shared .claude/settings.json file
• 379 were database passwords, 43 were SSH logins, 42 were tokens for GitHub, GitLab or npm, and 23 were AWS keys

More than a third of the exposed secrets open a database directly, the report says. Apiiro did not test whether the keys still worked, though one affected company confirmed its key was live.

Two details make this worse. Popular secret scanners missed a large share: gitleaks flagged 564 of the 1,122 files and TruffleHog flagged 643, while 215 were caught by neither. And many of these files had been public for a long time. Half of the affected repositories had held the exposed file for 217 days or more.

Why this went unfixed for over a year

Users raised the problem with Anthropic well before this research. A GitHub issue in the Claude Code repository, opened in August 2025, described secrets being written into the settings file. A bot closed it as "not planned" in January 2026 after a stretch of inactivity, and it was later locked. The Hacker News reports that four related reports met the same fate, the latest on November 6, without a reply from Anthropic. We found no Anthropic advisory or patched version at the time of writing.

It fits a pattern of AI developer tools becoming a soft target this fall, from the Northflank breach and other attacks on AI platforms to new controls like CrowdStrike's kill switch for rogue AI agents.

Who should check their repos first

You are most at risk if any of these apply:

• You use Claude Code in a repository that is public, or that might become public later
• You have ever approved a command that contained a password, token or connection string
• Your team shares repos across several machines or CI setups with different git configs
• You maintain an open source project where contributors use AI coding agents

Private repositories are safer but not safe. Anyone with read access, including a contractor or a compromised account, can read the file.

A cleanup checklist for Claude Code users

These steps follow the researchers' recommendations, in the order that limits damage fastest.

1. Rotate first. Treat any secret that ever appeared in a Claude Code settings file as exposed. Change the database password, revoke the token, issue a new key. Do this before you clean the repo, because deleting the file does not remove it from git history or from anyone who already copied it.
2. Search every repo. Look for .claude/settings.local.json and .claude/settings.json in all your organization's repositories, including their history, not just the current branch.
3. Stop tracking the local file. Run git rm --cached .claude/settings.local.json, then add that path to the project's .gitignore so it cannot come back.
4. Delete risky rules. Open the local settings file and remove any saved rule that contains a literal secret.
5. Keep secrets out of commands. Pass credentials through environment variables such as $DB_URL instead of typing them inline, so the saved rule only records the variable name.
6. Approve patterns, not exact commands. A rule like Bash(npm run:*) covers a family of commands without capturing their full text.

If a leaked token belonged to a GitHub or cloud account, also review that account's sign in history and turn on stronger login protection. Our guide to setting up an authenticator app walks through it.

For more coverage of AI tools and their risks, see our AI section. The quickest win today is step one: a rotated key is worthless to whoever found the old one.