A routine convenience feature in Claude Code, Anthropic’s AI coding assistant, has been quietly leaking passwords and API keys into public GitHub repositories, according to new research from Apiiro. The firm says it found 2,539 distinct secrets exposed across 1,994 public repositories, tracing the exposure back to a single approval option many developers click without a second thought: “Yes, and don’t ask again.”

How an ordinary approval becomes a public leak

The scenario Apiiro describes is mundane by design. A developer asks Claude Code to check a database connection, test an API endpoint, or debug a failed login. To do that, the assistant prepares a shell command that includes a credential pulled from a local configuration file, then asks the developer for permission before running it, standard behavior for an AI coding agent that respects user oversight.

The trouble starts when the developer selects “Yes, and don’t ask again” instead of a one-time approval. That choice saves the command, secret included, as a persistent allow rule inside a file called .claude/settings.local.json, so Claude Code can run the same command again later without prompting. The feature works exactly as intended from a usability standpoint. The problem is what happens if that local settings file ever gets committed to Git and pushed to a public repository: the credential goes with it.

A built-in safeguard that doesn’t always travel

Claude Code isn’t entirely unguarded against this. When it writes that settings file for the first time inside a Git repository, it adds an exclusion entry to the developer’s global Git ignore file, an attempt to keep the file out of version control by default. Apiiro’s research shows that protection has real gaps: it doesn’t carry over when a project is cloned or shared, it doesn’t cover files that are already tracked by Git before the exclusion is added, and it offers no protection if a plain folder is later turned into a new Git repository.

To measure the real-world impact, Apiiro scanned 104,185 public copies of .claude/settings.local.json found on GitHub. Genuine secrets turned up in 1,122 of those files, totaling 1,379 distinct credentials in the settings files alone. Expanding the search to earlier commits, shared settings files, and saved agent conversation transcripts brought the full count to 2,539 exposed secrets, collected between November 1 and 3, 2026, across 63 identified organizations, most of them software companies.

What was actually exposed

The exposed credentials weren’t limited to low-stakes test keys. Apiiro’s researchers say they found a database vendor’s admin-level cloud key, a production Azure PostgreSQL password, a Square production access token, and the owner password for a medical-records database among the live findings. At least one affected company confirmed to Apiiro that its exposed key had, in fact, been active at the time of discovery.

Databases accounted for the largest share of what leaked: 379 exposed database passwords and 122 Supabase service-role keys, according to the research. The rest of the haul spanned cloud provider credentials, private keys, package-registry tokens, and 43 exposed SSH logins, some of which included root passwords embedded directly in the saved commands.

Why standard secret scanners missed so much

Perhaps the most uncomfortable finding is how poorly existing secret-scanning tools performed against this exposure pattern. Of the 1,122 settings files Apiiro confirmed held real secrets, Gitleaks flagged only 564 and TruffleHog flagged 643, with 215 files missed by both tools entirely. The researchers attribute this to how the credentials appear in context: passwords embedded after patterns like PGPASSWORD= or sshpass -p, or buried inside request headers, don’t match the clearly recognizable formats that scanners are tuned to detect for major cloud providers.

Apiiro points out this exposure pattern is distinct from previously reported Claude Code vulnerabilities involving attackers actively manipulating project settings to steal keys. This issue requires no malicious prompt injection and no compromised account. It emerges purely from a legitimate developer following a normal, intended approval workflow.

Remediation steps for development teams

Apiiro’s guidance is direct: rotation comes before cleanup. Revoking exposed credentials should happen before anyone deletes a file or rewrites Git history, since the secret has already been publicly visible and should be treated as compromised regardless of what cleanup follows.

• Search current repositories and full Git history for any committed .claude/settings.local.json files, as well as shared .claude/settings.json files.
• Review every allow rule inside those files for embedded passwords, tokens, connection strings, or authorization headers, not just obvious API key formats.
• Rotate any credential found to have been exposed, even briefly, before removing the file from the repository.
• Untrack the local settings file with git rm --cached .claude/settings.local.json and confirm the path is listed in the repository’s .gitignore.
• Replace literal credentials in approved commands with references to a secrets manager rather than plaintext values.
• Security teams should extend scanning to agent memory files and saved conversation transcripts, where Apiiro also found exposed secrets beyond the settings files themselves.

The researchers also note that even organizations that never push these files to GitHub face a secondary risk: on a compromised laptop, malware capable of reading plaintext configuration files can extract the same credentials locally, a technique already demonstrated in supply-chain attacks like Shai-Hulud, which used tools such as TruffleHog to hunt developer machines for exactly this kind of exposed secret.