Add configurable mouse interaction levels for interactive prompts (AskUserQuestion / permission dialogs) — clicks currently select AND submit in one action

Bug: Refocus clicks are interpreted as option selection in interactive prompts (AskUserQuestion / permission dialogs)

Summary

Clicking on the terminal window to give it focus — not to select anything — is being interpreted as a click on whatever UI element happens to be under the cursor, including option choices in interactive prompts (e.g. the AskUserQuestion picker). This causes an option to be silently selected/submitted without the user ever pressing Enter or intending to make a choice.

Steps to reproduce

1. Trigger an interactive prompt with clickable options (e.g. a question with multiple-choice answers, or a permission "Yes/No" prompt).
2. Switch focus away from the terminal (e.g. to a browser window that visually overlaps/covers the terminal).
3. Click back on the terminal to refocus it, with the click landing on the coordinates of one of the option rows.
4. Observe: the option under the cursor is selected/submitted, even though the intent of the click was only to refocus the window, not to choose an answer.

This also reproduces in tmux: clicking a different pane to shift keyboard focus to it can be interpreted as a click on a UI element inside that pane, again without any Enter keypress.

Actual behavior

The click is treated as direct user intent to both select AND advance/submit — the mouse handler currently lets a single click do what normally takes arrow-keys/Tab (move selection) plus Enter (confirm) combined. There's no way to get only the "move selection" half, let alone opt out of mouse interaction with the UI entirely.

Why this matters

Terminal windows are very commonly partially or fully covered by other windows (browsers, docs, chat apps) during normal multi-window workflows, and are brought back to front with a click. Similarly, tmux users routinely click between panes purely to move keyboard focus. In neither case does the user intend to interact with whatever happens to be rendered at that screen location. Because the current mouse handler conflates "select" and "submit" into one click, an incidental focus-click can silently choose and confirm an answer with no way for the user to notice until after the fact.

Note: distinguishing "this click is meant to refocus the window" from "this click is meant to interact with the app" is not reliably solvable in-app — a terminal generally can't tell those apart. So the fix isn't trying to detect intent; it's giving users control over how much the mouse is allowed to do.

Requested fix: configurable mouse interaction levels

Add a setting controlling how much the mouse can do in interactive prompts (AskUserQuestion, permission dialogs, any other clickable list UI), independent of keyboard behavior. Suggested levels:

1. Full (current behavior) — click moves selection and advances/submits, equivalent to arrow-keys + Enter combined.
2. Select only — click moves the current selection (like arrow keys / Tab) but never advances/submits; Enter is still required to confirm.
3. Text selection only — mouse is used only for copy/text-selection; it has no effect on which option is highlighted or submitted.
4. Disabled — mouse input is entirely ignored by the interactive UI (still fine for terminal-level focus/copy handled outside the app).

This would let users who work with overlapping windows or tmux choose a mode where an incidental click can't ever submit a choice on their behalf.

Environment

• Claude Code version: 2.1.206
• Terminal emulator: Alacritty
• tmux: yes
• OS: NixOS, Linux 6.12.92 x86_64