How Claude Code's 'Don't Ask Again' Feature Leaked 1,122 Sets of Credentials on GitHub

AnthropiC's Claude Code extension for supported IDEs includes a feature that asks permission before executing terminal commands it suggests. When a developer clicks 'Yes, and don't ask again,' the assistant stores that approval decision alongside the full command text in a `.claude.json` or similar project-level configuration file. The problem: this file gets committed to version control, and if the repository is public on GitHub, anyone with internet access can read it.

Apiiro's research team, announced on November 7, found 1,122 public repositories containing this settings file with saved commands. Inside those commands were plaintext passwords, database connection strings, API keys for AWS, Google Cloud, GitHub, npm and other services, OAuth tokens, and database credentials. None of this was encrypted or redacted. The file contents were indexed by GitHub's search engine, making them discoverable by automated credential scanning tools.

Once a real API key or database password is public, an attacker's work is half done. They no longer need to guess or brute-force credentials; they have valid ones. With a GitHub token, for example, an attacker can push code to repositories under that account, delete branches, access private repositories, or extract intellectual property. With an AWS key, they can spin up expensive compute resources, access S3 buckets, or modify infrastructure. With a database password, they can exfiltrate entire datasets.

The risk multiplies because most developers reuse credentials across environments. A password that works for staging often works for production. A service account key that accesses one S3 bucket might have permissions for others. An attacker who finds even a single exposed credential can often use it to pivot into more sensitive systems. The 1,122 repositories represent at least 1,122 separate incidents of a developer either not knowing about this behavior or not thinking it was risky.

Claude Code's approval mechanism is designed to prevent the assistant from running arbitrary commands without the developer's explicit consent. That is a good security practice. However, Anthropic conflated the approval decision with the command itself, storing both in a persistent file. Here is the rough sequence:

1. Claude Code suggests a terminal command that includes credentials (e.g., `curl -H "Authorization: Bearer sk-abc123" https://api.example.com/data`)
2. The developer sees the command, trusts Claude, and clicks 'Yes, and don't ask again'
3. Claude executes the command and also saves it to the project's settings file
4. That settings file is already tracked in .gitignore by some frameworks, but not all
5. The developer commits the file without realizing it contains secrets
6. The repository is public, or made public later
7. Credentials sit exposed indefinitely until the developer rotates them or deletes the commit history

This pattern reflects a common flaw in approval-caching systems: developers often approve actions assuming the decision alone will be stored, not the full payload.

In theory, once Apiiro published their findings, every affected developer should immediately rotate their credentials and delete the exposed files from git history. In practice, many did not, or did not know about it. Some repositories may be abandoned or maintained by developers who no longer work on the project. Others belong to small teams without formal security processes. The Tor Project's documentation on security incident response notes that credential rotation at scale is slow: even with automation, detecting which services are actually compromised takes days, and verifying that new credentials are in place takes weeks.

Because GitHub keeps records of deleted commits in pull request history and other places, simply deleting a file from a public repository does not guarantee that the credential has been removed from the internet. Search engines, security researchers, and automated scanners may have already indexed and cached the secret. The only true remediation is immediate credential rotation across every service that was exposed.

If you use Claude Code or any other AI coding assistant, check your local repositories now:

1. Open the root of any project you work on and look for `.claude.json`, `claude.json`, `.claude`, or similar configuration files created by the IDE extension
2. If such a file exists, open it in a text editor and search for any strings that look like credentials: keys starting with `sk-`, `AKIA`, `ghp_`, `Basic `, bearer tokens, or database URIs with passwords
3. If you find any credentials, treat them as compromised: log into each service (AWS, GitHub, npm, your database host, etc.) and regenerate or revoke that credential immediately
4. Use `git log --full-history --all -- <filename>` to check if the settings file was ever committed, even in a deleted or old branch
5. If it was committed, run `git filter-branch` or use a tool like `git-filter-repo` to remove it from the entire history, then force-push to delete it from the remote repository
6. Do not add the settings file again without explicitly adding it to `.gitignore` with a high-visibility comment

If you are not familiar with git history rewriting, ask a colleague or consult GitHub's official guide before attempting it. A mistake can cause data loss or workflow disruption.

This leak reveals a recurring pattern in how AI coding tools handle permissions. When a human approves an action, the tool saves that approval to avoid re-prompting. This is meant to reduce friction and save time. However, developers and tool builders often assume that saving the approval decision is safe, when in fact saving the full command or payload alongside it creates a permanent record of secrets.

A related pattern: many git configuration tools and IDE extensions also auto-save credentials in plaintext inside `.config`, `.vscode`, or project-local files. VSCode, for example, stores environment variables in `settings.json` by default. Developers often treat these files as local-only and assume they will never be committed. They are wrong often enough that security vendors now scan GitHub specifically for these files.

The Tor Project's general security guidance states that developers should never store active credentials in any configuration file that might be committed to version control, regardless of whether the file is in a .gitignore. This principle applies to all tools. Claude Code's mistake was assuming the developer would know this and actively prevent it, rather than baking that prevention into the default behavior.

AnthropiC has acknowledged the issue and released a patch that no longer saves the full command to the settings file; instead, it saves only a hash or identifier that allows the tool to remember that this command was approved, without storing the sensitive text. If you use Claude Code, updating to the latest version is essential.

For developers using any AI assistant in a terminal or IDE, adopt these habits:

• Never paste passwords, API keys, or tokens directly into prompts or command suggestions. Instead, reference environment variables or secret management systems and let Claude or other tools generate commands that use those variables
• Enable credential scanning on your repositories (GitHub's native feature, or third-party tools like TruffleHog or GitGuardian) to catch leaks before they spread
• Review any `.gitignore` file to ensure sensitive configuration directories are excluded
• Assume that any file in a public repository, even if accidentally committed, will be found and exploited
• Rotate credentials regularly, not just after suspected leaks

The Claude Code leak is a reminder that convenience features in developer tools often hide security costs. A single click to save time can expose credentials that took months of careful work to earn and protect. The time to act is now: search your repositories for configuration files, verify you are running the patched version of Claude Code, and rotate any credentials that may have been exposed. If you work in a team, start this conversation with your security or DevOps lead today. The fix takes an hour. The cleanup after credential theft can take weeks.