Granular control over mouse click behavior in interactive menus (AskUserQuestion, select prompts)

Strong +1 with a concrete incident supporting this. Claude Code 2.1.205, macOS, VS Code integrated terminal: I clicked into the terminal window purely to restore OS focus, the click landed on an active Bash permission prompt, and it registered as a rejection — interrupting a long agent turn mid-task (details in anthropics/claude-code#77827).

The all-or-nothing controls don't help here: I want to keep wheel scroll and drag-select, and lose only single-click-confirms-an-option. Either of these would solve it:

1. A clickBehavior: highlight setting — click moves the selection highlight, Enter confirms (mirrors keyboard flow, keeps mouse useful).
2. At minimum, ignore the focus-restoring click — the click that transitions the window from unfocused to focused should never activate an option, which is how native macOS buttons behave.

Option 2 alone would eliminate the most common accidental path (returning to the terminal from another app while a prompt happens to be on screen).

Yeah, this is a crazy UX to have clicks to focus the window select options in the terminal.

By default, clicks in terminal CLIs should require some active user keyboard interaction, like holding down <kbd>cmd</kbd> or something.

And also a security risk, as mentioned over in another similar issue:

@mkobit in comment 4977260244: I see this also as a potential security risk. Accidentally approving some command in the _"Yes, and don't ask again"_

• https://github.com/anthropics/claude-code/issues/70622

Definitely needs a disable flag.

Adding another scenario backing up the need for this change:

I am working on creating a subagent and I was running through tests with the agent. I clicked to my terminal window to restore OS focus do decline a command and it accepted my click as approval of the command, which happened to be a destructive git command on a worktree that the agent did not own. This is of course during development work to isolate for commands like this, but there's a greater risk that accidentally clicking a window being taken as an approval cold potentially allow destructive commands to be run. This behavior really should be opt in only.

Similar to @brianespinosa I click the shell to restore focus, but the region for 'yes' or 'no' takes up the entire line, which I have accidentally clicked on more than a few times. Either an option to disable mouse confirmation, or to reduce the confirmation area to the characters it occupies (i.e. 3 characters for 'Yes') instead of the entire line would be ideal.

Another +1 from a daily CLI user. The framing that resonates for me: text copy/paste and scroll are expected behaviours in a terminal, so keeping them is table stakes — it's the click-to-answer on question/select prompts that's the genuinely surprising part, and the only thing I want to turn off. I also tried CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 and it disables selecting/copying text too, so it isn't a usable workaround. A granular flag like the proposed CLAUDE_CODE_DISABLE_MENU_CLICK_SELECT (keep copy + scroll + link-opening, disable only click-to-confirm) would be exactly right. Any update on whether this is on the roadmap?

Strong +1 here as well -- I want to be able to highlight and copy output to reason about or re-inject into the conversation, but I constantly have issues of attempting to re-focus the window and either miss the edge, hitting an user action in an obstructed window or clicking on the edge of an user action within the window I'm focusing, accepting/rejecting whatever Claude is proposing, which could be a security leak.

I need something more granular than disabling all mouse clicks so I can interact with the window content while still avoiding unintended actions.

Just pinging to make sure this isn't closed.

@claude any chance of this being picked up?

Another +1. I have also more than occasionally triggered the above "click to focus the CLI window, accidentally select the wrong (and not visible) option". Click to select, Enter to confirm seems ideal, or any of the other above proposals. Even when the window is on top, a hasty click can select the wrong choice, or even just mis-reading the line.

@claude Zzz

Spamming this thread so it doesn't get closed.