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

This is worth treating as an approval-integrity bug, not just a Windows focus quirk.

For permission prompts, the UI should be able to distinguish at least three input sources:

window_activation_click
explicit_pointer_selection
explicit_keyboard_selection

Only the latter two should be allowed to resolve the prompt. A focus click that arrives while the window is inactive should be consumed and logged as activation-only, even if its coordinates overlap a button.

The accidental grant direction is the highest-risk case, but accidental denial is also meaningful in orchestrated sessions because the agent may interpret it as user intent and alter the run. That means the approval event should probably carry provenance in the transcript/audit record: input type, focused-before-event boolean, prompt id, selected option, and prompt age.

One more edge case from the "typed digit landed on the wrong prompt" note: prompt responses should bind to a stable prompt id, not only to the currently visible prompt. If the visible permission prompt changes while keyboard input is buffered or the UI is lagging, stale input should be discarded rather than applied to the next prompt.

Additional manifestation from the same session: after clicking into the window and typing 1 on a permission prompt, the user reports the decision 'doesn't seem to have been recorded.' The approval DID take effect (the tool call executed), but the interaction is disorienting in combination with the click-through: the focus click can consume/dismiss the visible prompt, so the subsequent keystroke's target is ambiguous to the user, and allow-once answers leave no visible trace afterward. Suggested UX hardening alongside the focus fix: after any permission answer, echo a one-line confirmation of what was decided ('Allowed once: Bash(...)') so users can verify which prompt their input landed on.

"The accidental grant direction is the highest-risk case"

It appears to have also done this.

Third manifestation, and the most safety-relevant: a focus click just landed on the PERSISTENT approval option ('always allow' / don't-ask-again), not a rejection. Observed live: with a Bash permission prompt pending, the user clicked once on the window purely to give it focus; the click silently selected the persistent option and wrote allow rules to settings.local.json (the command pattern's segments appeared as new 'allow' entries; the store grew from ~329 to 349 rules over a session dominated by these prompts). Earlier phantoms in the same session registered as rejections — so the outcome depends on which dialog button happens to sit under the incoming click position / default focus. Net: the same click-through defect can silently grant standing permissions, deny wanted actions, or approve one-shots, with no confirmation trace either way. This strengthens the case for (a) consuming the window-activating click entirely, and (b) never binding the persistent-grant option to a bare pointer click at the default cursor/button position — require a deliberate keystroke for any 'always allow'.

I'm here to confirm that this is also an issue on macOS using iTerm2.

Also on Alacritty + Ubuntu 22.04.5 LTS

Title: Mouse click to regain window focus auto-answers an open confirmation prompt (mouse mode)

Severity: Safety — a focus-regain click can silently confirm a destructive/irreversible action the user never intended to approve.

Env: Claude Code CLI, mouse-enabled terminal mode; [Alacritty + Ubuntu 22.04.5 LTS].

Repro: 1) A yes/no (or multi-option) confirmation prompt is open and awaiting input. 2) Focus is in another window. 3) Click into the Claude Code window to regain focus. Actual: the click is consumed as an answer, selected by proximity to whichever option sits under the cursor — no Enter/carriage return required. Expected: the first click only restores window focus (focus-regain should be swallowed, not routed to the prompt); the selection should require a deliberate click/Enter while focused.

Impact: silent, unintended answers to confirmations — including destructive/irreversible ones. A focus-regaining click should never double as consent.

This is a real issue in some cases, I'm aware of it now and try to click in the text part of the window, but sometimes I still activate an option by accident. I'm on the verge of disabling the mouse input, but I now finally have proper multiline copy/pasting without indentations, so I really don't want to.