Claude Code's 'Don't Ask Again' Feature Exposed Thousands of Passwords and API Keys on GitHub

In November, security researchers at Apiiro published findings showing that 1,122 public GitHub repositories contained credentials exposed through Anthropic's Claude Code assistant. The vulnerability stems from how the tool handles the 'Don't Ask Again' checkbox. When a developer approves a command execution and selects this option, Claude Code saves the entire command in a configuration or settings file within the project. If that command includes an API key, database password, AWS credential, or any other secret, it gets written to disk.

The problem compounds when developers commit their project directory to GitHub without realizing that configuration files now contain those secrets. Unlike a .env file that many developers know to exclude, the settings file Claude Code creates is not automatically added to .gitignore patterns. By the time researchers discovered this pattern, over a thousand public repositories had already exposed credentials this way.

Claude Code works by asking for permission before executing terminal or shell commands. This is a reasonable safety feature: instead of running commands silently, the assistant shows the command to the user and waits for approval. When a user selects 'Yes' alone, the command executes once. But when they select 'Yes, and don't ask again,' the assistant saves that command to a project configuration file so it will not prompt again the next time the same command is needed.

The intent is to reduce friction during repeated workflows. However, no filtering happens during the save. A command like `export AWS_SECRET_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE && terraform apply` gets stored exactly as typed. Developers who paste credentials directly into commands, rather than sourcing them from environment variables or secrets managers, end up committing those credentials to version control.

Exposed API keys and passwords in public repositories represent immediate, searchable risk. Attackers and automated scanning tools scan GitHub for leaked credentials every day. A stolen AWS key can be used to spin up compute resources and rack up bills, or to access data in S3 buckets. A database password can lead to data theft or destruction. Even if a key is rotated quickly, the lag between exposure and discovery means attackers may have already used it.

The real danger is that developers trust their IDE and automation tools not to create hidden credential files. Claude Code's behavior violates that assumption. A developer might reasonably assume that clicking 'Yes, and don't ask again' means the assistant will remember their approval, not that it will store the command forever in a file that might get committed.

GitHub's native search engine is one vector, but more dangerous are automated scanners that index repositories for patterns. Tools like Trufflehog, GitLeaks, and commercial secret management platforms run continuous scans looking for API key patterns, private key formats, and common credential structures. Once a repository is public, anyone can clone it, and once credentials are in the git history, they remain there even if a developer later deletes the file and commits a new version. Removing secrets from git history requires force-pushing or rewriting the repository history, which is disruptive and often skipped.

If you work with Claude Code, take these steps to protect your workflow:

1. Never paste credentials directly into commands that Claude Code will execute.
2. Source secrets from environment variables set outside your project, or use a secrets manager like 1Password, HashiCorp Vault, or AWS Secrets Manager.
3. Add Claude Code's configuration files to your .gitignore before you make any commits.
4. If you have already used 'Don't Ask Again' with credential-containing commands, assume those commands are saved locally.
5. Search your project directory for any configuration files created by Claude Code and review their contents before committing.
6. If you have already pushed a repository that may contain exposed keys, rotate those credentials immediately and consider the repository compromised.

Accidental credential exposure in version control is not new, but AI coding assistants amplify the risk. The Tor Project and open-source security communities have long documented that developers often conflate convenience with safety. When a tool offers 'remember this decision' workflows, users naturally assume the tool has thought through the security implications. In this case, Claude Code's developers did not implement filtering or validation before saving commands.

Second, the explosion of API-driven development means developers now manage far more secrets than they did ten years ago. Each microservice, third-party integration, and cloud provider adds another credential to juggle. The cognitive load increases, and when an AI assistant promises to remember workflows, the temptation to use it for sensitive operations grows.

Third, GitHub's public repository indexing and searching by tools like Shodan, Censys, and specialized secret scanners means that almost nothing stays hidden for long. A credential exposed in a public repo is effectively public within days or hours. This is not a matter of privacy; it is a matter of immediate compromise risk.

Developers who rely on AI coding assistants should adopt a strict rule: never paste credentials into any tool, AI or otherwise. Instead, structure commands to read secrets from environment files or vault APIs. For repeated command execution, use shell aliases, Makefile targets, or CI/CD pipelines rather than asking an AI assistant to remember workflows.

Anthropically, the vendor, should implement secret filtering in Claude Code so that commands containing patterns matching common credential formats (AWS keys, bearer tokens, database URIs) are not saved without explicit warning. This is a fundamental security control that should apply regardless of user choice.

If you have repositories on GitHub that may contain exposed credentials, audit them now. Use a tool like GitLeaks locally on your repository to scan git history for secrets. Rotate any credentials that were exposed, and consider the repository's access logs and any actions taken by unknown users. Finally, adopt a policy that credentials are never stored in code, configuration files, or commands. This is the only reliable long-term defense.

Source: The Hacker News