Claude Code's "Don't Ask Again" Option Can Save Plaintext Secrets That End Up on GitHub

AI coding agents that generate code, resolve dependencies, and even run shell commands in the terminal have significantly reduced developers' workloads. However, it has come to light that a feature meant to streamline work, skipping confirmation prompts, is leading to unintended information leaks.

According to a research report published by security firm Apiiro on November 5, 2026, local settings files for Anthropic's development tool Claude Code were found in more than 100,000 public GitHub repositories, and 1,122 of them contained secrets such as API tokens and database passwords. The underlying issue is a design problem: when Claude Code remembers permission to run a command, it saves credentials in plaintext and relies on Git exclusion settings to protect them.

How "Don't Ask Again" Ends Up Storing Secrets

When Claude Code runs shell commands such as Bash in a developer's local environment, it asks the user for permission as needed. One of the options shown is "Yes, and don't ask again." If you choose it, Claude Code records a permission rule in the permissions.allow array of .claude/settings.local.json in the project so that it can skip confirmation from then on.

The problem is that the command string used at runtime can be saved as is. For example, suppose you use the following command to access an API.

curl -H "Authorization: Bearer sk-ant-api03-xxxx..." https://api.example.com/data

If you grant ongoing permission for this command and it meets the conditions under which the full command is saved, the API key in the Authorization header is also left in plaintext in the JSON file. The same applies to passwords embedded in database connection strings and to login credentials for servers.

However, a secret being stored in a local settings file does not by itself constitute an external leak. Before it becomes public on GitHub, it has to pass through the following three stages.

1. Command approval: The developer selects "Yes, and don't ask again" for a command containing credentials.
2. Plaintext storage of secrets: The full command is recorded as a permission rule, and the string containing the credentials is saved in .claude/settings.local.json.
3. Leak to a public repository: With Git exclusion not working, the file is committed and pushed to a public GitHub repository.

This problem had been reported before. On August 11, 2025, it was filed as Issue #5544 in Anthropic's official GitHub repository. The reporter confirmed on macOS 14.5 that commands containing credentials were saved as is in permission rules, and provided reproduction steps. However, the specific affected versions of Claude Code were not identified.

1,122 Settings Files Confirmed by Apiiro and the Limits of Scanner Detection

Apiiro surveyed public GitHub repositories and found 104,185 .claude/settings.local.json files. Of these, 1,122 files contained strings identified as secrets, totaling 1,379 secrets. In other words, 1,122 is not the number of credentials themselves but the number of settings files that contained secrets.

The investigation confirmed secrets tied to 63 organizations. They ranged widely, including cloud service API tokens, database passwords for production and development environments, SSH-related credentials, private keys, and login information for servers' root accounts. The problem extends beyond individual developers to the development environments of companies and open-source projects.

Particularly noteworthy is the failure of existing secret scanners to detect these files. When Apiiro scanned the target files with the widely used open-source tools Gitleaks and TruffleHog, 215 of the 1,122 files containing secrets were detected by neither tool. That works out to roughly one in five slipping past both tools.

Typical secret scanners rely on cues such as known API key formats and string randomness to detect secrets. However, custom-format tokens embedded in shell command arguments, or database passwords made from ordinary words, are hard to find with these methods. Detection can be especially difficult when credentials are inside complex commands, JSON, or URL-encoded strings.

However, these results reflect how the two tools performed on the files Apiiro examined, and are not an evaluation of every secret scanner. Nor did Apiiro verify the validity of the detected credentials by actually connecting to the services. It therefore cannot be confirmed whether all of them are still valid or whether attackers have abused any of them.

Git Exclusion Settings Failed to Prevent the Leaks

Why did so many settings files that should have stayed local end up in public repositories? Boris Cherny, who works on Claude Code's development, explained this point in a Hacker News discussion. According to him, Claude Code has a mechanism that automatically registers settings files in Git's exclusion settings when it creates them, and .claude/settings.local.json is intended to be kept out of source control.

However, this mechanism has an important limitation. When Claude Code creates a settings file, it uses Git exclusion settings that apply to the developer's local environment, not the .gitignore shared within the repository. Those settings are not carried over to clones on other machines, CI/CD environments, or containers. In addition, if a folder where Claude Code was used is later turned into a repository with git init, the exclusion settings may not work properly.

In such environments, the settings file is treated as an ordinary untracked file, so it risks being committed by bulk additions such as git add . or git add -A. Furthermore, once a file has become tracked by Git, adding an exclusion setting afterward does not automatically untrack it.

Indeed, Issue #13106, filed on December 4, 2025, reports a case in which the .claude directory was not properly excluded and a settings file containing a plaintext API token was committed to a public repository. Cherny pointed out the possibility that the exposed files were created manually or committed explicitly. On the other hand, Apiiro's investigation also found examples in which commits recording Claude Code as a co-author included changes to the settings file, so not every leak path can be explained by manual human action alone.

Challenges also remain in how past reports were handled. Issue #5544 was automatically closed on January 3, 2026, on the grounds that it had gone a certain period without updates, and related reports were similarly closed or closed as duplicates. However, an issue being closed does not mean the problem was fixed. No comprehensive official information has been provided on which version first had the problem or in which release it was addressed.

This problem is not simply a matter of inadequate Git exclusion settings. The fundamental issue is that commands containing credentials were stored in plaintext in the first place, with their protection depending on Git settings and developer vigilance. Even with proper exclusion settings, the secrets remain on the local disk, so other leak paths, such as unauthorized access to the machine or accidental file sharing, are also conceivable.

Anthropic's View and the Problems That Remain with Auto Mode

Cherny acknowledged on Hacker News that Claude Code has not so far automatically stripped secrets, and said countermeasures are under consideration. However, he did not announce when a fix would be released or which versions it would cover.

As an interim measure, he recommends Claude Code's "auto mode." According to Cherny, auto mode is available on all plans and is enabled by default. Unlike the conventional approach, in which a human approves each command execution, it uses a classifier to decide whether to run a command, reducing the "approval fatigue" caused by frequent confirmation dialogs. Anthropic cites static analysis, prompt injection defenses, and internal red-team testing as grounds for its safety.

However, a classifier's judgment differs in nature from explicitly defined allow and deny rules. On Hacker News, concerns were also raised about using machine learning model judgments in place of deterministic access control. In addition, one user pointed out that even in auto mode, commands containing sensitive information can be saved in the settings file. Cherny acknowledged this as "a fair point" and said he would look into improvements.

Cherny also mentioned the possibility of building secret-scanning functionality into Claude Code itself. However, while adding a scanner would help detect leaks, it would not resolve the underlying problem of storing secrets in plaintext.

Security Measures in Development Environments and the Remaining Risks

Development teams use multiple measures, including Git exclusion settings and secret scanning. However, when an AI agent automatically generates a settings file containing secrets, as in this case, no single measure is sufficient. The effects and limitations of the main defenses are as follows.

These measures target different stages of a leak. It is therefore important not to rely on a single mechanism, but to combine a design that keeps credentials out of commands, exclusion of settings files, and pre-commit inspection. In particular, because secrets that have been made public cannot be taken back from third parties even if deleted after detection, the risk needs to be reduced at the storage stage.

What Development Teams Should Do and How to Revoke Credentials

Developers and organizations using Claude Code need to check whether the problematic settings file is included in any public repositories. The targets of investigation include not only current files but also past commit history. This is because even if a file is deleted on GitHub, the information may remain in past commits, third-party forks, and external archives.

1. Prioritize Revoking and Reissuing Credentials

Treat any API keys, access tokens, database passwords, and similar credentials that may have been exposed as potentially obtained by third parties. Revoke the relevant credentials from each service's management console and replace (rotate) them with new ones. At the same time, check access logs and audit logs to investigate whether any suspicious authentication or operations have taken place.

This step has higher priority than deleting the file from the repository. If a third party has copied the credentials, deleting them from GitHub will not prevent unauthorized access.

2. Investigate Past Commit History

Use tools such as git log to check whether .claude/settings.local.json is included in past commits. You can also use secret scanners as needed, but a negative result does not prove that no secrets exist.

If a problematic file is found, preserve the evidence and then consider rewriting history with git-filter-repo or BFG Repo-Cleaner. This work requires force pushes and re-syncing history on collaborators' side, so coordination with those involved is essential. Also, it is not always possible to delete everything from forks and external archives, so consider consulting GitHub Support if necessary.

3. Don't Embed Credentials Directly in Commands

Avoid the practice of writing passwords or API tokens directly in shell command arguments, and move to a setup that retrieves them from environment variables or secrets management tools. For example, you can use 1Password CLI or AWS Secrets Manager to obtain the necessary credentials at runtime.

However, using environment variables does not make things safe in every case. You need to exclude .env files properly and take care that values are not expanded into command arguments or logs. It is also desirable for Claude Code's permission rules to retain references to environment variables rather than the credentials themselves.

4. Verify Settings Files and Git Exclusion Settings

Until Anthropic provides a fixed version and its behavior is confirmed, it is effective to test with dummy strings instead of real credentials. For example, approve a command such as curl -H "Authorization: Bearer test-dummy-token" and check whether that string is saved in .claude/settings.local.json.

At the same time, check whether the settings file is tracked by Git and whether it is excluded by the repository's own .gitignore. If it is already tracked, you can untrack it with a command such as git rm --cached .claude/settings.local.json. However, this operation does not remove the file from past commit history.

Autonomous AI agents reduce the effort of having developers check each individual operation and raise productivity. But if skipping confirmation means credentials are stored without the developer's knowledge, that convenience comes with a new security risk. This problem highlights that safety design is needed that covers not only an AI agent's execution privileges but also what the agent records and where it stores it. Going forward, a fundamental fix from Anthropic and action on credentials left in existing environments will both be required.