Claude Code's "Don't Ask Again" Feature Caused 2,539 Secrets to Flow into Public GitHub Repositories

On November 5, 2026, software security company Apiiro released a research report confirming that Anthropic's AI coding assistant Claude Code has a systemic credential leakage path: when a developer selects "Yes, and don't ask again" in the permission prompt pop-up, that approval writes the complete shell command—including database passwords, API keys, or authentication tokens embedded in the command—in plaintext into the .claude/settings.local.json file in the project directory. Once that file is pushed with code to a public GitHub repository, anyone can read the credentials in it. After scanning 104,185 copies of such files on GitHub, Apiiro researchers found at least one real secret in 1,122 copies, totaling 1,379 independent credentials; after further merging Git historical commits, shared configuration files, and agent conversation logs, the total leakage rose to 2,539 credentials, involving 1,994 repositories and 63 organizations.

The leaked credentials cover a wide range: according to Apiiro's statistics, 379 database passwords and 122 Supabase service role keys form the largest category; there are also 43 SSH login credentials (some containing server root passwords), 42 GitHub/GitLab/npm tokens, 23 AWS keys, as well as cloud platform credentials and private keys. Typical cases cited by Apiiro include a database vendor's own admin-level cloud key, a production Azure PostgreSQL password, a Square production token, and the owner password of a medical records database. When researchers notified the relevant organizations, at least one company confirmed that its key was valid at the time of discovery.

How a Normal Action Became a Public Leak

To understand this leak, one must first understand the original intent of Claude Code's permission design. As a terminal-driven AI coding agent, Claude Code asks developers for confirmation before executing commands that may modify the system or involve sensitive resources—this confirmation layer is meant to be a security guardrail. But to reduce the disruption of repeated pop-ups to workflows, the tool provides a "don't ask again" option: once selected, the complete string of that command is recorded as an "allow rule," and it can be executed directly in the future without confirmation again.

The problem lies in the words "complete string." If a developer asks Claude Code to test a database connection, debug API authentication, or troubleshoot a login failure, the commands Claude generates often directly contain credentials read from configuration files—for example, a JDBC connection string with a password, a curl request carrying a Bearer token, or an environment variable assignment containing an API key. When the developer clicks "don't ask again," this command containing the key falls unchanged into settings.local.json. After that, an ordinary git add and git push is enough to publish it to the whole world.

Apiiro used Claude models Opus 5.5 and Fable 5.1 to reproduce the above behavior and confirmed that it is repeatable. This path does not involve any attack technique or account hijacking—it occurs entirely within the normal development approval flow and is a product of the interaction between the tool's design behavior and developer habits.

Why Built-in Protections Failed

According to Anthropic's design, when the tool first writes settings.local.json inside a Git repository, Claude Code adds that file path to the user's global git excludes, so that all repositories on that machine ignore this file. This is a real protection measure, but its coverage has three key gaps.

First, the global exclusion rule exists only on the machine where the file was written and is not passed along with the project directory to other collaborators or CI/CD systems. Second, Claude Code does not add an exclusion entry to the project's own .gitignore file, meaning that after cloning the project on another machine, the file is no longer protected. Third, for files already tracked by Git, the global exclusion rule has no effect—once a file is in the repository, subsequent modifications are still committed. Among the 1,105 affected repositories tracked by Apiiro, 539 had commits co-authored by "Claude" that modified this file, suggesting that in many cases it was the Claude agent itself that committed the file into version history.

The persistence of the leak is also more counterintuitive than expected. Apiiro found that 211 fork copies of 74 repositories carried exactly the same keys as the original repositories; another 509 repositories had 734 additional keys in historical commits, mostly because someone deleted the current file but did not clean up Git history. This means that removing a file from a repository does not eliminate the risk; historical snapshots and derivative copies will continue to retain that credential.

Standard scanning tools do not fully detect this type of leak. Of the 1,122 files containing keys, the mainstream secret detection tool Gitleaks flagged only 564, a detection rate of about 50%. Another tool, TruffleHog, had different coverage, but neither identified all of them. Part of the reason is that command strings stored in "allow rules" have diverse formats, and secrets do not necessarily appear in common regex patterns but are hidden in the full shell command context.

What Deeper Problems Does This Finding Reveal

For ordinary developers, the core risk lies in a cognitive blind spot. "Don't ask again" is a usability feature that reduces friction, and its use scenario is precisely when developers are most focused and least inclined to review side effects—a click in flow may go unnoticed for weeks afterward. Many developers do not proactively check what is actually written into configuration files.

For enterprise security teams, this report presents a new category of attack surface: configuration file leakage from AI coding agents. Traditional secret scanning tools are designed for hard-coded credentials in code files and have incomplete coverage of JSON-format "allow rule" command strings. Existing enterprise development standards—such as requiring .gitignore to include specific paths—need to be updated to cover local configuration files generated by AI tools.

For Anthropic, as early as August 2025, a user reported the issue of plaintext credential storage in Claude Code's GitHub issue tracker, and reportedly received no response from Anthropic. That means about 15 months passed between the community's first report and a security firm's large-scale scanning confirmation.

For the entire AI coding tool sector, Apiiro compared the documentation of 16 coding agent tools and found that this type of credential persistence problem is not unique to Claude Code—but Claude Code's user scale and market visibility made the impact and public reaction of this exposure more significant. This finding effectively constitutes a test for the entire industry: as increasingly autonomous AI agents can read and write file systems and execute commands, how credentials flow, where they land, and who is responsible for oversight are questions every tool must answer clearly.

Historical Context: The Structural Chronic Problem of Secret Leaks on GitHub

Accidentally committing secrets to code repositories is a problem that has persisted for more than a decade. GitHub has continuously strengthened secret scanning and push protection since the 2020s, and partner coverage has kept expanding. However, these mechanisms rest on a premise: secrets appear in code files in identifiable formats.

The Claude Code case represents a new variant: secrets are not manually pasted by developers into code, but fall into configuration files as shell command strings through the AI assistant's permission-recording mechanism. The source of the leak has shifted from "human operational error" to "tool design decisions." This change requires secret scanning tools, enterprise audit rules, and even developers' mental models to adjust accordingly—because the responsible subject has changed from a single person to the interaction chain between person and tool.

What May Happen Next

Anthropic is highly likely to adjust the write mechanism for settings.local.json in the short term. The most direct options include stripping parameter values from commands when storing allow rules (keeping only command patterns rather than full command strings), triggering an active warning when writing high-entropy strings, or forcing simultaneous addition of exclusion entries to the project's .gitignore rather than relying only on global configuration.

GitHub and other code hosting platforms may expand the file scope of secret scanning to include AI tool configuration files. Apiiro's report has explicitly pointed out coverage gaps in tools such as Gitleaks, and such reports usually prompt toolchains to follow up with updates.

This incident may accelerate the pace at which enterprise security teams conduct adoption reviews for AI coding tools. In heavily regulated industries such as healthcare and finance, the compliance consequences triggered by a production database password appearing in a public repository far exceed the cost of technical remediation. For enterprises among the 63 affected organizations that have not yet rotated keys, each additional day of delay continues to expand the potential exposure window—at least one organization has confirmed that its key was valid when discovered.