Claude Code's 'Don't Ask Again' leaked secrets into 1,122 public repos

What happened

Security firm Apiiro published research this week documenting 1,122 public GitHub repositories leaking secrets through Anthropic's Claude Code CLI. The leaked material includes AWS access keys, OpenAI and Anthropic API tokens, database connection strings with embedded passwords, GitHub personal access tokens, and in some cases full `.env` dumps pasted into command arguments.

The vulnerability isn't a bug in Claude Code — it's the interaction between a convenience feature and developer muscle memory around `git add .`. When Claude Code asks permission to run a shell command, users can click "Don't ask again" to permanently allow that command pattern. That approval, along with the exact command string that triggered it, gets written to `.claude/settings.local.json` and `.claude/history.jsonl` inside the project directory. Because those files sit next to the code and aren't in Anthropic's default `.gitignore` guidance, they ride along into commits and then into public remotes.

Apiiro's crawl of GitHub surfaced files containing commands like `curl -H "Authorization: Bearer sk-ant-..."`, `psql postgresql://admin:hunter2@prod-db...`, and `aws s3 cp --profile ` — all stored verbatim as the "approved" command the user had told Claude to stop asking about. In other words, the agent faithfully logged the exact secrets it had been handed.

Why it matters

This is the second high-profile secret-leak class tied to AI coding agents in the last six months, and the pattern is becoming predictable. Any tool that persists "trusted actions" on disk eventually persists the arguments to those actions — and arguments are where secrets live. Cursor had a similar episode with `.cursor/mcp.json` tokens earlier in the year. GitHub's own secret scanning now flags Claude Code artifacts, but only after push, and only if the token matches a known provider pattern — custom internal secrets slip through.

The HN comment thread on Apiiro's post splits roughly three ways. The largest camp is practitioners arguing this is a user-error story dressed up as a vendor story: `.env` files, SSH keys, and `~/.aws/credentials` have been one `git add .` away from disaster for twenty years, and no one is surprised when a new config file joins the list. The uncomfortable rebuttal, which a smaller but louder group makes well, is that agentic tools genuinely raise the blast radius: a human typing `curl -H "Authorization: Bearer ..."` usually does it once in a scratch shell; an agent asked to "test the API" will do it fifty times, each one logged, each one a durable artifact on disk. The third camp — mostly people who work on the agents themselves — points out that the fix is cheap: write to `~/.claude/` (user-level) instead of `./.claude/` (project-level), the same way `git config` distinguishes `--global` from `--local`.

Anthropic's current defaults don't do this. Project-local settings are preferred specifically so that per-repo trust decisions don't bleed across unrelated codebases, which is a defensible call. But the current implementation writes the triggering command into the same file as the trust decision, which conflates two very different things: *"I trust `npm install` in this repo"* and *"here is the exact `npm install` invocation, including a private registry token, that I trusted."* The first is a policy. The second is a secret.

What makes this worse is time-of-check versus time-of-commit. The developer sees the "Don't ask again" modal in the moment, approves, and moves on. The leak happens hours or days later, in a commit titled "wip" at 11pm, and surfaces publicly only after someone runs a scanner against the whole of GitHub. By then the token has been valid and exposed for however long it takes you to notice — which, per Apiiro, is often weeks.

What this means for your stack

If you or anyone on your team uses Claude Code, do three things today. First, add the following to your repo's `.gitignore` and to your global `~/.gitignore_global`:

``` .claude/settings.local.json .claude/history.jsonl .claude/*.log ```

Second, audit existing commits. GitHub's search is rate-limited and noisy, but `git log --all --full-history -- .claude/` inside each repo will tell you quickly whether you've already pushed these files. If you have, rotate every secret that could plausibly have been in a shell command you ran through the agent — not just the ones you remember. The `history.jsonl` files Apiiro analyzed averaged 412 commands each; no one remembers 412 commands.

Third, if you run your own tooling that wraps an LLM and persists approvals, separate the policy (allow `npm install`) from the invocation (the actual argv, which may include tokens). Hash or glob-match the command for trust purposes; never store the raw string. This is the same lesson that `sudoers` learned in the 1990s when it moved from "exact command match" to patterned commands with argument restrictions — the agent ecosystem is rediscovering it at speed.

For teams, this is also a prompt to look at your pre-receive hooks. GitHub's push protection catches provider-formatted tokens but will not catch an internal JWT, a hardcoded Postgres password, or an OAuth bearer against your own API. Trufflehog and Gitleaks in a pre-commit hook are a $0 upgrade that would have caught every single one of Apiiro's 1,122 repos before the push.

Looking ahead

The deeper issue is that coding agents have inherited the developer-tooling convention of storing config next to code, and that convention was designed in a world where config meant "indent width is 2." It now means "here is a durable transcript of every privileged command I was willing to run, including the secrets I passed to those commands." Expect Anthropic and the other agent vendors to quietly split these files — trust decisions user-global, command history ephemeral or redacted — over the next few releases. In the meantime, the fix is a two-line `.gitignore` and a healthy mistrust of any "Don't ask again" button that doesn't tell you where it's writing its memory.