Windows: click-to-focus activates pending permission dialog option (click-through), submitting an unintended answer

Bug description

When Claude Code is running with a permission prompt pending and the window does not have focus, the user's first click on the window — intended only to give the window focus — lands on the permission dialog and submits an answer (approve/reject) without the user typing or intentionally choosing anything.

This happened repeatedly in one long-running session: each time the user returned to the machine and clicked into the window to interact, the pending permission question was answered by the focus click itself. The session (an orchestrated multi-agent run) interpreted the resulting rejections as deliberate user "stop" commands and paused work each time.

A related earlier incident in the same session: with UI latency, rapid clicks/keystrokes applied to a different prompt than the one visible when the input was made (user typed an answer meant for option 1, which landed as option 2 on a permission prompt).

Expected behavior

• The first click that gives the window focus should be consumed as focus-only (standard "click-through suppression"), never delivered to a button/option of a pending permission dialog.
• Alternatively, permission prompts could require an explicit keypress (1/2/3 or Enter) rather than accepting a possibly-accidental pointer click, or debounce input for a short interval after window activation.

Environment

• OS: Windows 11 Pro 10.0.26200
• Claude Code: background session (job runner), PowerShell primary shell; also reproduced during an interactive review session
• Model: Opus 4.8
• Session type: long-running orchestration with frequent permission prompts (git operations, background MATLAB suite runs)

Repro steps

1. Start a task that triggers a permission prompt (e.g., a Bash tool call needing approval).
2. While the prompt is pending, click away so the Claude Code window loses focus.
3. Click once anywhere on the Claude Code window to bring it back into focus.
4. Observe: the click is delivered to the permission dialog and an answer is registered (in our case, repeatedly a rejection), without any keyboard input.

Impact

Unintended permission grants/denials. In our session this (a) rejected in-flight tool calls the user wanted to allow, repeatedly pausing an autonomous overnight run, and (b) earlier caused an accidental "always allow"-style selection when a typed digit landed on the wrong prompt. Accidental grants via focus clicks are the more concerning direction for safety.

Filed by Claude Code on the user's behalf at their request.