[Feature Request] Add granular mouse control options to disable click-selection while preserving scroll

+1 for this. Concrete use case: on Windows (cmd/conhost, v2.1.191) the mouse wheel is the natural way to scroll back through the conversation. The only workaround for accidental click-accept in dialogs (permission/confirmation prompts and the option selector) is CLAUDE_CODE_DISABLE_MOUSE=1, but that is all-or-nothing — it also kills wheel scrolling, forcing PageUp/PageDown. A granular toggle (e.g. CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 or mouse.clickSelect: false) that disables click-selection while preserving wheel scroll would solve this cleanly. Related: #70539.

Strong +1 on this. My exact use case: I click in the terminal the normal way to move focus and select text so I can type, and the CLI captures those clicks and selects an option on the interactive prompts (AskUserQuestion menus, permission dialogs). A stray click submits an answer I never meant to pick, so I have to interrupt, cancel the wrong answer, and get the question re-asked. Net result is slower than no mouse support at all.

The one part I do want to keep is click-to-position-cursor in the input line (saves deleting whole sentences or arrow-keying across). Today the only off-switch is CLAUDE_CODE_DISABLE_MOUSE=1, which is all-or-nothing and takes that away too. A granular mode (e.g. CLAUDE_CODE_MOUSE_MODE=cursor-only: keep cursor positioning, disable click-selection on menus) would fix it. At minimum, a mouse-selected decision should require a confirm rather than firing on first click.

Strong +1 on this as well. I'm on a mac, not that it matters, but clicking back to select the terminal in focus so i can use my keyboard sometimes select's an option I DO NOT WANT, wasting tokens. Clicking to select from a menu in a terminal is really bad UX.

Please please fix this! I have already accidentally allowed SSH * and that is not what I want on production environments... And disable the CLAUDE_CODE_DISABLE_MOUSE=1 don't allow me to copy from my terminal anymore.

annoying

mouse click support to select menus was a stupid feature in the first place.

+1 for this. It is way to easy too click in a terminal to bring it to the foreground and accidentally select a random option from a list. As stated above, this could lead to production issues.

Help! Please give us more granular mouse settings. I'm constantly focusing the terminal window with a click and errantly selecting a choice.

+1, and I'd like to widen this from the menu-click angle to plain text
selection/copy, which hits the same all-or-nothing wall.

On kitty (Linux, v2.1.205) the fullscreen renderer's mouse capture means a
normal click-drag no longer selects text in my terminal — I have to hold
Shift, which in kitty grabs full-width lines rather than the logical
selection. CLAUDE_CODE_DISABLE_MOUSE=1 restores native selection, but as this
issue says it's all-or-nothing: it also kills wheel scrolling, and
CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 keeps the wheel but still forces Shift-drag
to select. There is currently no combination that gives native, no-Shift text
selection AND wheel scrolling at the same time.

This is worse across many sessions: hopping between them via agent view /
claude attach forces the fullscreen renderer regardless of tui: "default",
so the classic-renderer escape hatch isn't available there either. (The
v2.1.203 fix making CLAUDE_CODE_DISABLE_MOUSE honored in attached sessions
helps only by turning the mouse off entirely — back to the same trade-off.)

Request: independent mouse flags (e.g. separate mouse.scroll,
mouse.clickSelect, mouse.textSelect), or at minimum a mode that keeps wheel
scrolling while leaving native terminal text selection working without Shift.
Text selection is fundamental; it shouldn't be mutually exclusive with
scrolling.

+1, please fix this, it is really annoying

This is also an issue in MacOS terminal.app. The theme here is that the click-to-select-menu-item "feature" should be ring-fenced as its own configurable flag.That way a user can choose to avoid inadvertently approving commands with a mouse click when that user is simply trying to bring focus to a terminal window.

+1 on this for exactly the reason stated - I want to give focus to the terminal, but Claude interprets it as a selection of some answer. Also, I'm on Mac, so it is not just a Linux problem.

And, as also requested in previous replies, I still want to be able to select text for copy/paste with my mouse and use the scroll wheel.

Do people who use terminal to interact with code really want a "feature" to click their mouse button over a choice? Who designed this...? Keep the mouse stuff in the app version. No place in the terminal.