How Claude Code's 'Don't Ask Again' Feature Exposed Thousands of Credentials on GitHub

Claude Code, Anthropic's AI-powered coding assistant, includes a feature that asks users to approve commands before execution. When developers select 'Yes, and don't ask again', the system stores the entire command, including any embedded secrets, in a local project settings file. This file is then committed to version control, and in 1,122 cases, pushed to public GitHub repositories where anyone can download and search the credentials.

The vulnerability isn't a hack or a zero-day; it's a design choice that treats developer credentials the same way as any other command parameter. Apiiro's discovery, published in November 2026, highlights how convenience features in development tools can silently create security debt when they interact with version control workflows.

The 'don't ask again' pattern is familiar to anyone using modern software. It reduces friction and saves time. For developers running deployment scripts, database migrations or API calls through Claude Code, saying 'yes' once seems logical. The problem is that most developers don't expect their approval action to be persisted as a literal copy of the command, secrets intact.

Many teams use shared repositories, CI/CD pipelines that clone those repos, or archive projects that sit in public repositories for years. A password typed into a Claude Code command today might be sitting in a searchable GitHub history long after the developer has moved teams or forgotten they approved it. The credential is no longer 'just' in memory; it's in a timestamped file that version control systems are designed never to forget.

Once credentials are on GitHub, attackers use automated scanning tools to find them. GitHub's own secret scanning can catch some patterns, but it relies on known formats and vendor participation. A database password or custom API key that doesn't match a recognized pattern slips through. Attackers also scan GitHub's public API directly or use tools that clone repositories by the thousands and search their contents offline.

Once found, a valid credential becomes a starting point for lateral movement, data exfiltration or further attacks on internal systems. A database password found in a public repo might unlock customer data. An AWS key might grant access to cloud infrastructure. The scope of damage depends on what permissions that credential holds and how long it remains active before the owner notices and rotates it.

If you use Claude Code or any IDE with approval features:

1. Never approve commands that contain passwords, API keys, tokens or database credentials
2. Instead, refactor the command to read secrets from environment variables, `.env` files (which should be in `.gitignore`), or a secrets manager
3. Search your GitHub account and any organizations you belong to for commits containing common patterns like 'password=', 'api_key=', 'token='
4. If you find exposed credentials, rotate them immediately, even if they were exposed months ago
5. Enable GitHub's secret scanning and push protection on all repositories, public and private
6. Audit your IDE and AI assistant settings to see where files are saved and what triggers persistence

This incident reveals a gap between how developers think about secrets (compartmentalized, temporary, never committed) and how modern tools treat them (as just another piece of text to remember). Anthropic and other vendors building into the developer workflow should treat any command containing a credential as a separate security domain: never persist it, never store it, and warn the user explicitly if they attempt to use inline secrets.

On the team side, enforce secret rotation schedules, require code reviews that catch suspicious patterns, and treat version control history as a security surface. Many organizations assume that once a repo is deleted or made private, the exposure ends. In reality, GitHub's caches, forks, and third-party archives mean sensitive data can persist for years.

The 1,122 repositories represent a breadth of organizations, from startups to enterprises. A credential leak doesn't always lead to a breach, but it lowers the barrier to one. An attacker may test thousands of keys before finding one that works, or may use the leaked credential to pivot into a target during a broader attack campaign. Detection of the misuse often comes too late, after the credential has already been used.

This pattern repeats across development tools: build systems that persist API calls, logging frameworks that capture full requests, and now AI assistants that remember everything they approve. Each feature solves a real problem. Each one also expands the surface area where secrets can hide in plain sight.

Developer credential leaks are preventable, but only if credentials never make the journey from your terminal to your repository. The lesson from Claude Code's 'don't ask again' feature is that convenience is not a substitute for design. Review your own approval patterns in IDEs and AI tools, audit any secrets already in your repositories, and rotate the ones you find. If you work on a team, raise this with your security or DevOps leads and discuss where secrets belong in your workflow. Modern tools are powerful; treating them as trustworthy enough to handle secrets unilaterally is not.

Can rotated credentials in old GitHub commits still be exploited? No, once a credential is rotated, the old value becomes worthless. Attackers may still find it during scanning, but it will fail when tested. This is why rotation speed matters and why you should rotate immediately upon discovery.

Does GitHub's secret scanning catch all of these leaks? No. GitHub's secret scanning relies on patterns and vendor integrations. Custom formats, older tools, and non-standard credential patterns often slip through. Always assume that public repositories can be read by anyone.

Should I delete the commit history if I find a secret in Git? Simply deleting the commit doesn't remove the secret from GitHub's archives or third-party forks. You must rotate the credential, and if the repo was public, assume the secret is compromised. For new code, use `git filter-repo` or similar tools to purge secrets from history, then force-push, but rotation is the priority.

How do I prevent this in Claude Code going forward? Never use inline secrets in commands. Pass credentials through environment variables, temporary files in `.gitignore`, or a secrets manager. If Claude Code prompts you to approve a command with a secret, edit the command first to remove the secret.

Can I trust other AI coding assistants with secrets? No. Any tool that offers to remember or persist your commands should be treated as potentially insecure for credentials. Assume all AI assistants, text editors, and IDE plugins are not suitable for storing secrets.

Source: The Hacker News