Claude Code’s Silent Permission Click on Windows

Claude Code’s permission system is one of the stronger safety layers among agentic coding tools: deny first, then ask, then allow; rules evaluated by the runtime, not the model. That design fails closed by default. A reported Windows TUI bug punches a hole through it that has nothing to do with rules or classifiers.

Issue #76743, filed against Claude Code on Windows 11 and labeled bug, has repro, area:tui, and area:permissions, describes a classic click-through failure. When a permission dialog is pending and the terminal window lacks focus, the first click meant only to activate the window is delivered to whatever control sits under the cursor. Approve, reject, or “always allow” can fire without a deliberate keystroke. If you run long sessions, leave prompts up, or step away from autonomous jobs, that is worth checking today.

The failure mode

The sequence is simple enough to reproduce:

1. Start work that triggers a permission prompt (for example a Bash tool call that needs approval).
2. Alt+Tab so Claude Code loses focus while the prompt is still open.
3. Click once anywhere on the Claude Code window to bring it back.

That click lands on the dialog. The session records a decision you never made. The original report describes this happening repeatedly in a long-running orchestration session: returning from idle, focusing the window, and having pending prompts answered by the focus click. Rejections were treated as deliberate “stop” signals and paused overnight runs multiple times. A related latency case in the same session: rapid input intended for one prompt applied to a different one after the UI had moved on.

This is not exotic. Windows delivers the activating click to the control under the pointer. Native Win32 apps often suppress that first click after WM_ACTIVATE. Claude Code’s UI is a TUI over a terminal/ConPTY surface, so it has to implement click-through suppression itself. Until it does, the permission overlay remains a live target for focus clicks.

The issue is filed for Windows 11. macOS and Linux are not known to share the same mouse-delivery behavior for this surface. Treat that as platform-specific until proven otherwise.

Why accidental approve is the real problem

Permission prompts exist because agentic tools are exposed to prompt injection, over-eager problem-solving, and honest blast-radius mistakes. Official docs spell out the tiers: read-only work inside configured directories can proceed without ceremony; Bash, file writes, and similar actions prompt unless pre-allowed. Deny, ask, and allow rules are evaluated in that order. Modes range from default (manual) through acceptEdits and the newer AI-classifier auto mode up to bypassPermissions, which is meant for isolated containers and still keeps circuit breakers for things like rm -rf /.

That whole stack assumes a human decision when a prompt appears. Click-through breaks the assumption at the input layer. An unintended reject mostly wastes time (paused overnight jobs, false “user stop”). An unintended approve or “always allow” is worse: a file write, network call, or shell command can proceed under the appearance of consent. The report flags accidental grants as the more concerning direction for safety. That matches how these systems fail in production: not usually a clever jailbreak, but a trusted channel that silently lies about user intent.

If you already use broad allow rules or bypassPermissions, this bug is less about the dialog and more about whether you still believe the audit trail. If you rely on prompts as the primary gate, the bug turns that gate into a coin flip based on cursor position.

What to do on your machine

Check history first. Look for permission decisions you do not remember:

claude log --recent

For autonomous or overnight Windows runs, also check whether unexpected “user stop” style rejections interrupted work you thought was unattended.

Work around the click path until a patch lands. Practical mitigations from the report:

• Give focus via the title bar or a non-interactive region before touching the dialog.
• Prefer keyboard answers (1 / 2 / 3 or Enter) over mouse clicks; those are not described as affected by this click-through path.
• Clear or decide pending prompts before walking away.
• For long unattended jobs, prefer a background mode with no interactive TUI to click into.

There was no official fix at the time of the report (filed 11 July 2026). The durable product fix is standard: consume the first post-activation click as focus-only, require an explicit keypress for permissions, or debounce input briefly after window activation.

Reduce how often the dialog appears at all. That is configuration, not a patch, but it shrinks the attack surface of accidental UI events. Project-local rules in .claude/settings.local.json (and team-shared .claude/settings.json) let you allow narrow tool patterns and deny dangerous ones. Rules look like Bash(npm run build), Read(./.env) as deny, or path-scoped read/edit globs. Evaluation order is deny → ask → allow; a broad deny wins over a narrower allow. Use /permissions to see which file each rule came from.

A sane Windows workstation posture for agent work:

• Keep default or acceptEdits for interactive coding; reserve bypassPermissions for throwaway VMs.
• Allow only the Bash/WebFetch patterns you actually need; deny secrets paths and destructive globs explicitly.
• Do not leave “always allow” decisions to a focus click. If you meant permanent allow, set it in settings where it is reviewable in git or local config.

Example shape (paths and commands must match your tree):

{
  "permissions": {
    "allow": [
      "Read(~/src/**)",
      "Edit(~/src/**)",
      "Bash(git *)",
      "Bash(npm test *)"
    ],
    "deny": [
      "Read(~/src/**/.env*)",
      "Bash(rm -rf *)"
    ]
  }
}

That does not fix click-through. It means fewer live prompts sitting under the cursor when you Alt+Tab back.

Production readiness and who feels this

This is a genuine safety regression for a specific setup: Claude Code on Windows 11, sessions that raise permission UI, and any workflow that loses and regains window focus with a prompt open. It is not “Claude ignores permissions.” The runtime still enforces rules; the TUI can mis-attribute human input.

Who should treat it as urgent:

• Windows users running multi-hour or overnight agent loops with prompts enabled.
• Anyone who treats the session log as proof of human approval for shell or network side effects.
• Teams that standardized on Claude Code with shared allowlists but still expect interactive confirmation for the residual ask set.

Who can deprioritize:

• macOS/Linux users until evidence appears on those platforms.
• Fully non-interactive setups where permissions are pre-declared and no TUI prompt is in play.
• Environments already sandboxed so a mistaken approve cannot reach production credentials or the host filesystem.

The broader lesson is familiar from browser UI and UAC history: authorization UX is part of the security boundary. Agentic coding tools add long-running sessions, overlays inside terminals, and “always allow” memory. Those amplify click-through and latency bugs. Pattern-based allowlists and auto mode classifiers help throughput; they do not replace a trustworthy yes/no channel.

Until Anthropic ships click-through suppression (or moves permission confirmation off accidental pointer targets), assume that on Windows a focus click can be a decision. Audit claude log --recent, tighten rules so fewer prompts idle on screen, and answer remaining ones from the keyboard. The permission model is still worth using. The mouse path currently is not.