# Claude Code's 'Don't Ask Again' Leaked 1,122 Secrets

> Apiiro found Claude Code's 'Don't Ask Again' permission setting helped push secrets into 1,122 public GitHub files. Here's what happened, Anthropic's rebuttal, and how to lock your repo down today.

- Canonical: https://www.kunalganglani.com/blog/claude-code-dont-ask-again-secrets
- Author: Kunal Ganglani
- Published: 2026-11-08 · Updated: 2026-11-08
- Category: Cybersecurity · Tags: claude-code, secrets-leak, ai-agent-security, github-security, apiiro

## TL;DR

Security firm Apiiro found that a convenience setting in Claude Code, Anthropic's popular AI coding tool, helped push real passwords and API keys into 1,122 public GitHub repositories. The setting quietly saves your approvals to a local file that is supposed to stay off GitHub, but many developers committed it by accident. Anthropic says users should switch to a safer default mode and turn on GitHub's secret scanning, while critics call that passing the blame. The takeaway: don't commit the .claude settings file, turn on secret scanning with push protection, and rotate any key that ever landed in your git history.

If you have ever clicked "Don't Ask Again" in Claude Code to make the permission prompts stop, there is a real chance your API keys and passwords are already sitting in a public GitHub repository right now. On November 6, 2026, the AI application-security firm Apiiro published research showing that Claude Code's "Don't Ask Again" permission-bypass option helped push secrets into 1,122 public GitHub files. Within hours the story hit the front page of Hacker News with 188 points and 129 comments.

What makes this one worth reading past the headline is that the vendor fired back almost immediately. A member of the Claude Code team posted an on-the-record rebuttal on the same thread, and the developer community tore into it. This post covers all three: Apiiro's findings, Anthropic's defense, and the counter-argument. Then a concrete configuration guide you can apply before your next commit.

## What Is Claude Code's "Don't Ask Again" Feature?

Claude Code's "Don't Ask Again" option is a permission setting that tells Anthropic's coding agent to stop prompting you on a specific class of action and silently allow it from then on. When Claude Code wants to run a shell command, edit a file, or reach a network endpoint, it normally asks first. Click "Don't Ask Again" and that approval gets written into a local settings file, so the prompt never fires for that action again.

![Lines of colorful JavaScript code displayed on a dark screen](https://cdn.sanity.io/images/vzekdneq/production/6216624054880c722ab8ee371ce8dc4259699d83-1200x675.webp)

That file is `.claude/settings.local.json`. By design it is supposed to stay on your machine. Claude Code automatically adds it to `.gitignore` when the agent itself creates the file, which is the built-in safeguard meant to keep your personal permission list out of version control. The trouble starts the moment that file ends up tracked in git anyway, because it can accumulate not just permission rules but the fragments of commands, tokens, and environment values those rules were approving.

Permissions in Claude Code span three layers. A committed project file (`.claude/settings.json`) for shared team rules, the per-developer `.claude/settings.local.json` for personal overrides, and runtime prompts for anything not yet decided. "Don't Ask Again" writes to the middle layer. The one that is personal, local, and never meant to travel off your laptop.

So should `.claude/settings.local.json` be committed to git? No, never. It is per-developer local state, not shared project config. If you want team-wide rules, those belong in the committed `.claude/settings.json`, and even then they should carry allow/deny patterns, never secrets.

## What Happened: Timeline of the Claude Code "Don't Ask Again" Secrets Leak

Apiiro's research team scanned public GitHub and found 1,122 files where credentials had leaked through the permission-settings path tied to Claude Code's "Don't Ask Again" behavior. These are not theoretical foot-guns. They are real, countable, already-public files containing passwords and keys.

![monitor displaying index.html codes](https://cdn.sanity.io/images/vzekdneq/production/a904127178e36dcc70c49be87f7c683ebfd5d504-1200x675.webp)

The scale matters because of the install base behind it. The official `anthropics/claude-code` CLI repository sits at 154,914 GitHub stars and 25,602 forks, with 16,799 open issues and pull requests, barely a year and a half after its February 22, 2025 creation. The latest release, v2.1.319, shipped November 6, 2026. When a permission default sits inside a tool that popular, a leak path measured in four digits is the floor, not the ceiling, because Apiiro could only count what was already public.

Here is the official demo of the exact mechanism, if you want to watch the leak play out:

[Watch: Claude Code Users End up Exposing Keys on Github](https://www.youtube.com/watch?v=_BCQ7qbFXGA)

What turns this from an isolated bug into a pattern is the timing. That same week, a separate Claude Code privacy issue was fixed in v2.1.317: the tool had been putting the user's account email address into the HTTP `User-Agent` header on every outbound web request, and embedding that same email in the system prompt of every session. That one sat open for roughly five months before the fix. Two telemetry-and-permission disclosures in seven days is not bad luck. It is what happens when an [agentic AI](/blog/ai-security-complete-guide) tool ships fast and treats data-handling defaults as someone else's problem.

## Why Coding Agents Like Claude Code Leak Credentials

The root cause is not a single bug. It is the structural tension between agent convenience and secret hygiene. Coding agents exist to kill friction, and every approval prompt is friction, so every agent offers a way to make the prompts stop. "Don't Ask Again" is that escape hatch, and the escape hatch has to persist its decision somewhere on disk.

![JavaScript code displayed on a dark screen with colorful syntax highlighting](https://cdn.sanity.io/images/vzekdneq/production/1b98f11a4dc52f48e669aa24dbd26367ad92d7a2-1200x675.webp)

Once a permission decision lives in a file, three things conspire against you. The file captures more context than you intended. Developers routinely commit config directories without reading every line. And Claude Code, by Anthropic's own admission, does not scan for secrets before it writes or commits. Does Claude Code scan for secrets before committing code? No. It defers that entirely to third-party and platform tools.

This is the same trust-everything failure mode that drives [prompt injection](/blog/indirect-prompt-injection-ai-agents) in agents more broadly. [Simon Willison](https://simonwillison.net/tags/prompt-injection/) has made the point repeatedly: agents treat the content they read and the actions they are told to take with far more trust than any security model should allow. A permission file that silently records bypassed approvals is just another expression of that same over-trust.

Then there is the cultural piece. The "[vibe coding](/pillars/developer-tools-workflow)" workflow that [Andrej Karpathy](https://x.com/karpathy/status/1886192184808149383) named conditions developers to hand diligence to the tool. If the agent handles the plumbing, you stop scanning diffs for a stray `.claude` directory. One Hacker News commenter put it well: these toolchains "condition developers to offload much of that diligence to the tooling itself, which makes catching mistakes harder." The [attack surface](/blog/ai-agent-tool-use-security-attack-surface-checklist) of a coding agent is not just its tools. It is every default that quietly writes state to disk.

And this is not a Claude-only concern. Enterprise security teams have been naming the pattern out loud for a while. At the MCP Dev Summit in Toronto, Michael Forrester of Accenture described an employee who simply routed around an agent's tool restrictions to get the behavior they wanted, a story later recounted by developer Ben Greenberg. Permission and policy bypass across coding and MCP agents is a recognized industry failure class, not a one-off Claude Code bug.

Across the 261+ posts this site publishes through an automated agent pipeline I built, every secret lives in environment variables the agents cannot echo, and nothing an agent generates is committed without a deterministic gate running first. That design choice came straight out of this lesson: deterministic checks before a model acts catch more than a smarter model does after the fact.

## Anthropic's Rebuttal and the Developer Pushback

Within four hours of the story breaking, [Boris Cherny](https://news.ycombinator.com/item?id=50407882) from the Claude Code team responded directly on Hacker News. His argument had three parts.

First, on the file itself: "`.claude/settings.local.json` is meant to stay local. This is not a file you should check into source control. We automatically gitignore it when Claude creates the file, so in this case the files were manually created and checked in." Translation: the built-in safeguard worked, and the 1,122 leaks came from users manually creating and committing the file themselves.

Second, on permissions generally: "Permission rules are old hat. Everyone should be using auto mode instead. It is safer and also does not require manually maintaining finicky allow/deny lists. Auto mode is enabled by default and is included for free in all plans."

Third, on scanning: "Regardless of what agent you use, you should have secret scanning enabled. GitHub and other source control hosts offer it."

The community did not buy the framing. The top reply called it "some unsavory buck passing," arguing that because the `.claude` directory "gets created on the fly when it is needed," a developer who never personally asked Claude to scaffold the project could leak passwords without ever knowing the file existed. The commenter's sharpest point: with 1,122 confirmed impacted repos, "whether it is standard or not is irrelevant, it is part of existing functionality and entirely foreseeable. I'd expect any company worth the opportunity for trust to clearly own the mistake."

Here is the uncomfortable part: both sides are partly right. Committing a secrets file is a developer error. But shipping a feature whose foreseeable failure mode is credential exposure and then pointing at the user is the kind of defense that ages badly. If you run [Claude Code](/blog/claude-code-security-2026) on a team, you cannot assume every engineer knows the `.claude` directory exists, let alone that it needs gitignoring.

## How to Check If Your Repo Leaked Secrets and Lock It Down

Is Claude Code safe to use with API keys and passwords? Only if you configure it to be. The default behavior is the risk. Here is the fix, in order.

### Auto mode vs. manual permission lists

Anthropic's own recommendation is to stop maintaining allow/deny lists and switch to auto mode. The honest trade-off:

| Approach | How it handles approvals | Secret-leak risk |
| --- | --- | --- |
| Manual allow/deny ("Don't Ask Again") | Persists your bypassed approvals into `.claude/settings.local.json` | Higher — the file accumulates state and can be committed by mistake |
| Auto mode (default on all plans) | Decides approvals at runtime without a growing local allow-list to commit | Lower — no finicky list to leak, but still not a secret scanner |

Auto mode removes the file that caused this specific leak. It does not scan for secrets, so it is necessary but not sufficient.

### The checklist to secure your AI coding agent today

1. **Grep your history for the file.** Run `git log --all --full-history -- '**/.claude/settings.local.json'` and search your tree for any committed `.claude` directory. If it is tracked, the credentials in it are compromised and must be rotated, not just deleted.
1. **Enforce the gitignore.** Add `.claude/settings.local.json` (and `.claude/` if you keep no shared config there) to your `.gitignore` explicitly. Do not rely on Claude Code having done it for you. That safeguard only fires when the agent creates the file.
1. **Switch to auto mode.** Follow Anthropic's guidance and move off manual allow/deny rules so there is no persistent permission file to leak in the first place.
1. **Turn on GitHub secret scanning and push protection.** Enable [GitHub's native secret scanning](https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning) with push protection so a committed key is blocked before it ever reaches a public branch. This is the single highest-leverage control, and it works no matter which agent you use.
1. **Rotate anything that ever touched a tracked file.** A deleted secret still lives in git history and in GitHub's cache. Rotate the key at the provider. Do not just remove the line.
1. **Add a redaction layer to your own tooling.** If you build internal agents, strip secrets before they get written anywhere. I wrote up the pattern for how to [redact secrets in an AI coding CLI](/blog/redact-secrets-ai-cli), and it is the same principle behind the small [developer tools I maintain](/tools) for this site: a model never gets to write a raw credential to disk.
For teams, back this with human-in-the-loop controls. The [tool approval patterns](/blog/tool-approval-patterns-ai-agents) I use put a deterministic check between an agent and anything irreversible, which is exactly where "Don't Ask Again" removed the guardrail. In the automated pipeline I run for this site, nothing a model generates reaches a live commit until a deterministic gate clears it, a discipline I adopted after a single bad automated run rewrote live slugs and cost 907,000 search impressions of link equity in one incident. Secrets deserve the same treatment: a gate that runs before the agent writes, not an apology after it ships. No single setting saves you here. Defense in depth does.

This incident will not be the last of its kind, and the honest prediction is that it gets worse before it gets better. Every coding agent racing for adoption, from [GitHub Copilot vs Claude Code](/blog/github-copilot-vs-claude-code) to [Aider vs Claude Code](/blog/aider-vs-claude-code), faces the same pressure to trade friction for safety and the same temptation to call credential leaks a user error. The teams that earn trust will be the ones that treat secret handling as a default they own, not a checkbox they point at. Until then, assume your [AI agents](/pillars/ai-agents) will leak whatever you let them touch, and configure accordingly.

Photo by Lazar Stankovic on Unsplash.