Ambiguous click semantics in permission-prompt UI causes accidental wrong selections

Interface: Claude Code approval/permission prompts (numbered option list, option 1 = yes/allow)

Behavior observed:
There are three ways to submit a response: type the option number, press Enter while an option is highlighted, or click it. Arrow keys and clicking both move the highlighted selection.

The problem is click ambiguity. If the terminal/page doesn't currently have focus, the first click has to serve two purposes at once — regain focus, and (apparently) register as an interaction with whatever's under the cursor. That first click sometimes gets interpreted as an actual selection or submission, rather than only restoring focus. Given the options are laid out where option 1 ("yes") is often nearest a natural click target, a stray focus-recovery click frequently lands as an unintended "yes" (or otherwise wrong option) rather than being absorbed as a no-op focus event.

Impact: Frequent accidental wrong selections when clicking back into an unfocused window, including approvals the user didn't intend to grant.

Suggested fix: When the prompt/page did not have focus at the time of a click, treat that first click as focus-only — absorb it rather than also interpreting it as a select/submit action on the underlying option.