Claude Code's 'Don't Ask Again' and the 1,122-file password leak
A convenience toggle in Claude Code appears tied to credentials showing up in over a thousand public GitHub files, and it exposes a design tension every coding agent now shares between frictionless approval and accidental secret exposure.
TL;DR: A “Don’t Ask Again” permission toggle in Claude Code is being linked to credentials landing in 1,122 public GitHub files, and the lesson is not “Claude is unsafe” but “convenience switches in coding agents quietly turn one approval into a standing grant you forget you gave.”
The specific claim here comes from a Hacker News post titled “Claude Code’s ‘Don’t Ask Again’ exposes passwords in 1,122 public GitHub files.” I want to be precise about what that is and is not. It is a community report with a file count attached. It is not an Anthropic advisory, and I have not seen Anthropic confirm the mechanism or the number. So treat the 1,122 figure as reported, not audited. What makes it worth writing about anyway is that the failure mode is structurally obvious once you look at how these agents ask for permission.
What does “Don’t Ask Again” actually do?
Coding agents like Claude Code interrupt you before running commands that touch your system: writing files, running shell commands, reading environment variables, making network calls. That interruption is the safety layer. It is also annoying, because a real coding session triggers dozens of these prompts an hour. So the agent offers an escape hatch: approve this, and don’t ask again for things like it.
The problem is the scope of “like it.” A human reading “Don’t Ask Again” thinks they are approving this one command. What they are often approving is a category: all file writes, all reads of a certain path, all shell commands matching a pattern. The approval persists across the session, sometimes across sessions depending on where it is stored. One click becomes a standing grant.

Now connect that to secrets. Credentials live in .env files, config files, sometimes hardcoded in source during development. If an agent has a blanket approval to read and write files in a repo, and it is helping you refactor, generate a README, or set up CI, it can touch those files, copy their contents into examples, inline them into committed code, or stage them for a commit without a second prompt. The guardrail that would have caught it got waved off twenty commands ago.
How do real passwords end up in public repos?
The mechanism matters because it is not exotic. Credentials leak into public GitHub constantly, agent or no agent. GitHub’s own secret scanning exists precisely because this is a chronic problem. What a coding agent changes is the volume and the plausibility.
Volume, because an agent writes and commits faster than a human and does it across many files at once. If it templates a config, it can propagate a real secret into every copy. Plausibility, because the output looks clean and intentional. A human skimming an agent-generated commit sees well-formatted files and tends to trust them. The secret sitting in line 40 of a generated docker-compose.yml does not announce itself.
The 1,122 number, if it holds, is the kind of count you get from scanning public repos for a signature pattern: a specific config shape, a comment the agent tends to emit, a file layout. That is a search result, not a controlled study. It tells you the pattern exists at scale. It does not tell you that “Don’t Ask Again” is the sole cause, or that every one of those files was agent-written. Correlation at this stage, and I would want to see the query before calling it causation.
Is this Claude Code’s fault or the whole category’s?
It is the category’s. Every agent that can run commands faces the same tradeoff: ask too often and nobody uses it, ask too rarely and you hand out blanket permissions. Claude Code gets named here because it is popular and because its toggle has a memorable label. Codex, Cursor’s agent mode, Gemini’s CLI, the open-source agents: all of them have some version of “stop interrupting me.” The design question is identical across the board.

Where I think the real fix lives is not in removing the toggle but in scoping it tighter and making secrets a special case. A few things that would actually move the needle:
- Secret-aware refusal. The agent should refuse to read, echo, or commit anything that matches a credential pattern regardless of what permission you granted. “Don’t Ask Again” should never silently cover secrets.
- Time-boxed or command-boxed grants. Approval that expires when the session ends, or that covers only the exact command shape you saw, not a whole category.
- Commit-time interception. A hard stop before the agent stages a file that contains a detected secret, separate from the general permission flow.
None of this is novel. Secret scanning and pre-commit hooks have done versions of it for years. The gap is that the agent’s permission model and the secret-detection layer are not wired together, so a blanket approval in one bypasses the protection in the other.
What should I actually do about it this week?

If you run any coding agent against repos that hold credentials, the practical moves are boring and effective. Enable GitHub secret scanning and push protection on every repo, so a secret cannot reach a public branch even if the agent tries. Add a pre-commit hook that runs a detector like gitleaks or trufflehog, which catches the leak locally before it is a public problem. Keep real secrets out of the files the agent can see: use a secrets manager or local-only .env files that are gitignored and never templated. And audit what you have already approved. If your agent stored a “don’t ask again” grant, find where it lives and clear the ones you do not remember giving.
The catch most people miss: the danger is not the moment you click the toggle, it is every session afterward when you have forgotten it is on. A blanket grant feels free because the cost shows up later, in a public repo, found by someone running the same scan that produced this 1,122 number. The convenience is real and I use these agents daily. But treat “Don’t Ask Again” like a standing door key, not a one-time pass, and put the secret-detection layer underneath it so the agent’s worst case is a blocked commit instead of a public password. Until the vendors wire permissions and secret scanning together, that layer is yours to build.