Claude Code’s Secret-Leak Problem Puts AI Coding Agents on Trial

A developer tells Claude Code to run a command. The tool asks for permission. The developer selects “Yes, and don’t ask again,” expecting the approval to save time the next time a similar command is needed.

Instead, that decision can also preserve the command as an allow rule in a local configuration file. If the command contains a database password, an API token or a private key, the secret may be written into the project’s settings. If that file later enters a repository, a private credential can become a public one.

That chain of events is at the center of a growing dispute over Claude Code, Anthropic’s command-line coding assistant. Ars Technica reported that security company Apiiro found more than 100,000 Claude Code settings files in public GitHub repositories. Roughly 1,100 of those files reportedly contained sensitive credentials, including database passwords, API tokens and private keys.

The numbers do not show that every exposed secret was active, or that Claude Code independently discovered and published them. They do show how a small design choice can collide with ordinary developer behavior. A setting intended to prevent repetitive approval prompts can create a durable record of the commands that developers approved.

The disagreement is not simply about whether users should have committed local files. It is about whether a production-ready coding agent should make it easy for sensitive material to be stored in those files in the first place.

A permission that remembers

Anthropic’s own documentation describes the mechanism. In its explanation of settings files and precedence, Claude Code’s documentation says that selecting “Yes, and don’t ask again” saves the approved command as an allow rule in .claude/settings.local.json.

That file is designed for local settings. In practical terms, the feature gives the agent a memory of a user’s decision. Instead of asking repeatedly whether it may run a command, Claude Code can use the saved rule to proceed automatically when the command matches the approval.

The problem emerges when the command itself includes a secret. A shell command such as a database connection, a deployment instruction or a request to an external service may contain credentials directly in its text. Saving the permission can therefore save more than the fact that approval was granted. It can preserve the sensitive command line as well.

Anthropic’s documentation also describes a safeguard intended to keep local settings out of Git. The global Git-exclude configuration is meant to prevent files such as .claude/settings.local.json from appearing as untracked files that developers accidentally commit. The documentation explains, however, that the safeguard has limits. Repository-level workflows can behave differently, and protection based on local Git configuration does not guarantee that a file will never be copied, tracked or committed.

That distinction matters because modern coding work is not always conducted through a careful, manual sequence of local Git commands. Developers clone repositories, move files between environments, use automated workflows and ask agents to make commits. A protection that works in one developer’s global configuration may not follow a file into another repository or machine.

The result is a familiar security weakness in a new form. Developers may understand that secrets do not belong in source code, while failing to recognize that a configuration file recording an approved command can become a second path into the same repository.

The critical case: this is not just user error

A named reporter in a GitHub issue described credentials being stored in .claude/settings.local.json and argued that the project’s automatic ignore behavior did not reliably protect the file. The complaint is important because it challenges the framing that the exposure is merely the result of developers ignoring instructions.

The strongest version of that criticism is straightforward: if a coding agent can place credentials into a file as part of its normal approval workflow, then the product should provide stronger protection before the file reaches version control.

Telling users not to commit the file addresses only the final step. It does not prevent the secret from being written to disk. It does not ensure that every clone, copy or automation environment recognizes the file as private. It does not account for a developer who asks the agent to commit changes, or for a workflow in which an entire project directory is packaged and sent elsewhere.

That criticism becomes more forceful when the tool is marketed as an autonomous or semi-autonomous collaborator. The more responsibility users delegate to an agent, the less realistic it becomes to assume that every user will inspect each generated command and every modified settings file. An agent that remembers permissions is reducing friction by design. The security question is whether it is also remembering sensitive material without making that risk visible enough.

The public repository findings suggest that the distinction between “local configuration” and “project content” is not holding consistently in the real world. Even if the intended workflow is safe, a product used across thousands of developers must be evaluated against the workflows people actually use, including hurried commits and automated changes.

Anthropic’s response points to a shared responsibility

Boris Cherny, Claude Code’s lead, said in a discussion reported by Althacker that Anthropic was investigating ways to prevent the problem. He argued that settings.local.json should not be committed, recommended auto mode and secret scanning, and acknowledged that the team was considering additional safeguards.

That response places responsibility on both sides. Developers still need to avoid committing local settings and should use secret scanning. Anthropic, meanwhile, is considering whether the workflow needs product-level defenses rather than documentation alone.

Secret scanning can help detect known patterns after a credential has been written. It is less useful as the first line of defense when a token is valid, unusual or embedded in a command that does not resemble a standard secret format. Scanning can also identify a leak after the important event has already happened. A credential that reaches a public repository may need to be revoked, replaced and traced through systems that trusted it.

The more effective intervention may come earlier. The agent could warn when an approved command appears to contain a credential. It could refuse to store certain command patterns in a persistent allow rule. It could redact sensitive arguments before saving permission data. It could make the persistence decision more prominent, or separate permission memory from the raw command that received approval.

Each option involves tradeoffs. Aggressive detection can produce false positives and interrupt legitimate development. Redaction can break commands that need exact values. Refusing to remember commands may return developers to repetitive approval prompts, reducing one of the main benefits of an agent. But those costs are visible and immediate. A leaked private key can remain difficult to discover long after the original approval has been forgotten.

The production test is behavioral, not technical

The episode exposes a broader problem for AI coding tools. Their risk is not limited to the code they generate. It also comes from the operational shortcuts they introduce around files, permissions, shell commands and version control.

Traditional software generally waits for a human to decide what to execute and what to commit. Coding agents compress those steps. They can interpret an instruction, run commands, modify files and sometimes create commits in a single workflow. Each compression saves time, but it also removes opportunities for a person to notice that a private value has crossed into a persistent file.

That is why permission memory deserves more scrutiny than its modest interface suggests. A checkbox or approval button may look like a convenience feature, yet it defines what the agent is allowed to repeat later and what information is retained to make that possible.

Enterprise adoption will depend on whether vendors can make those boundaries dependable. Global ignore rules must work across the environments where teams actually build and deploy. Local configuration must remain clearly separate from repository content. Automated commits need safeguards that treat secrets as a distinct category of risk. Scanners must operate before publication, not only after a token has appeared in a public search result.

Anthropic’s documentation provides guidance, and the company’s lead says additional prevention is under consideration. The critical response from users is that guidance may not be enough when the product’s default experience encourages persistent permission and autonomous action.

That disagreement will shape the next phase of AI-assisted development. The central question is not whether developers can be reminded to behave more carefully. They have been told for years not to commit passwords. The question is whether coding agents can preserve that discipline while making software work faster.

Until they can, every saved permission carries a second meaning. It is not only a decision about what an agent may do next. It may also be a record of what the developer has accidentally trusted the repository to remember.