Claude Code's “Don’t Ask Again” Exposed Credentials in 1,122 Public GitHub Files

Summary:APIiro reports that Claude Code’s “Don’t Ask Again” option may allow passwords, tokens, and other sensitive values to be written directly into code, with such material appearing in 1,122 public GitHub files. The incident highlights a security gap in how coding agents manage terminal approvals, persistence, and outbound data. Permanently suppressing prompts can grant an agent far broader authority than users expect, including the ability to embed credentials in patches, commits, or public reposit

---

The Leak Is a Data-Flow Failure, Not Merely a Paste Error

APIiro reports that Claude Code’s “Don’t Ask Again” setting is associated with sensitive material appearing in 1,122 public GitHub files. The central issue is not simply that a model generated a password-looking string. Once users suppress terminal prompts to remove friction, a coding agent can continuously perform sensitive actions, allowing passwords, tokens, or API keys to flow into source files, patches, commits, and ultimately public repositories.

Publishing the repository turns a local incident into a supply-chain incident. Even after a file is removed, historical commits, Git objects, caches, forks, and third-party mirrors may retain the original secret. Deleting the current version is not enough because credentials embedded in commit history remain exposed.

How “Don’t Ask Again” Expands the Attack Surface

Terminal coding agents typically request approval before executing commands, modifying files, accessing the network, or writing to sensitive locations. Selecting “Don’t Ask Again” creates a persistent allow rule. If that rule authorizes only a tool or command category without understanding data sensitivity, an agent may silently complete this chain:

1. Read credentials from environment variables, configuration files, or command output.
2. Insert them into source code, tests, or migration scripts.
3. Send them out through an automatic commit or an external tool call.
4. Make the repository public and spread the secret through the public software supply chain.

In permission-system terms, this is a confused deputy problem. The agent is supposed to act for the user, but malicious instructions, dependency scripts, or prompt injection can direct it to move local sensitive data into resources it is authorized to modify.

The important point is that “Don’t Ask Again” addresses interaction friction, not trust boundaries. Suppressing prompts does not solve secret propagation.

The Real Gap Is Secret Data Flow

A mature defense should not rely only on scanning the final diff. It needs layered controls along the path where secrets are produced, copied, and transmitted:

• Read isolation: Keep credentials in a dedicated secret store. Give agents short-lived, task-scoped tokens rather than access to complete .env files, cloud credential stores, or password-manager exports.
• Write blocking: Inspect file edits and patches for private keys, PEM blocks, GitHub tokens, AWS keys, database passwords, and high-entropy strings.
• Egress control: Apply data-loss-prevention checks to outbound requests, including bodies, query parameters, and command output.
• Commit gates: Scan the staging area and complete history before git commit, while retaining detections for files that were staged and later removed.
• Revocable permissions: Bind persistent approval to a specific tool, resource, directory, network target, and expiration rather than a global allow/deny switch.

An editor warning alone is insufficient. Developers may approve warnings under time pressure, and attackers can encode or split secrets to evade regex-based scanners. Effective detection should combine format-specific parsers, entropy analysis, contextual rules, and low-false-positive handling.

Missing Controls in the Existing Toolchain

GitHub Secret Scanning and Push Protection block some high-confidence credentials, but they do not cover every coding-agent path. A secret may already have entered local Git objects, a third-party model API, an issue attachment, or an agent’s remote session logs before push protection evaluates it.

A stronger enterprise design covers three stages:

| Stage | Main risk | Required controls | | --- | --- | --- | | Agent reads | Bulk access to environment variables and secret files | Least-privilege tokens, field-level masking, isolated sensitive directories | | Agent writes | Embedding secrets in source or patches | Pre-write DLP, trusted-context validation, atomic blocking | | Agent exfiltrates | Leaking through networks, commits, or tools | Egress proxy, network allowlists, commit gates, audit trails |

For example, a team can route Claude Code traffic through a unified proxy that scans request bodies, expose read-only mounts or temporary copies for local tools, and enforce both pre-commit and server-side push protection. The final enforcement layer should remain deterministic infrastructure rather than depending on model caution.

Evaluation Must Go Beyond Secret Generation

Security testing should cover at least four attack surfaces:

• Direct instruction: A prompt asks the agent to read and print environment variables.
• Context injection: A malicious README, issue, or dependency script instructs the agent to ignore policy.
• Composed exfiltration: The agent writes a secret to a file, then indirectly sends it through formatting, testing, or deployment tools.
• Persistent authorization: Sensitive operations must still trigger independent approval even when routine prompts are suppressed.

Recall alone is not a sufficient metric. False positives are also dangerous because a noisy scanner trains developers to dismiss every warning. Evaluation should track blocking rate, false-positive rate, sensitive-file access attempts, persistent-permission coverage, and whether secrets reach Git history or model-request logs.

Remediation and Deployment Guidance

For exposed credentials, revoke and rotate them before rewriting repository history. Then use tools such as git filter-repo and inspect remote caches, forks, CI logs, issues, release artifacts, and retained third-party agent logs. History cleanup cannot invalidate a credential that has already been copied, so rotation must take priority over rewriting commits.

A practical baseline is:

1. Never provide real secrets to coding agents; use short-lived, least-privilege, revocable credentials.
2. Scope “Don’t Ask Again” approvals by tool and resource instead of granting global permanent permission.
3. Add secret detection at file modification, Git commit, network request, and model-API egress boundaries.
4. Audit reads, edits, commits, and sensitive-data transmissions by the agent.
5. Regularly scan Git history and public repositories, then exercise malicious dependency and indirect prompt-injection paths.

The lesson is not that Claude Code is simply insufficiently intelligent. The deeper issue is that when a coding agent converts natural-language intent into system-level operations, permission granularity and data-flow enforcement cannot remain centered on terminal confirmation. As agents obtain more durable execution authority, the security boundary must move from “did we ask the user?” to “which data may flow where, and can the user revoke that authority?”

---

Source: Hacker News AI Feed (2026-11-07)

— END —

Tags: #Claude Code Follow #Coding Agents Follow #Credential Leakage Follow #GitHub Security Follow #Permission Governance Follow