[Feature Request] Add scroll-only mouse mode to disable clicks while preserving wheel scrolling

I've been clicking back to the window to re-focus and hitting buttons accidentally. 'No' is frustrating. 'Yes' is potentially disastrous.

Yes, this is highly irritating for me too (Claude Code CLI on Windows Terminal). I'll click on the terminal window to give it focus so I can answer the question and it randomly picks an option for me, and its not even always obvious what I accidentally picked. Seems to be a recent problem. I can see that clickable choices might be nice, but there at least ought to be a mouse-over hover highlight to make it really obvious what's going to happen.

<img width="1036" height="204" alt="Image" src="https://github.com/user-attachments/assets/6dfa5ab0-c169-4546-ae02-366d89c4031a" />

Looks like the latest version includes this! Tested and working. I think this can be closed :)

Running v2.1.195 on Windows Terminal. The new CLAUDE_CODE_DISABLE_MOUSE_CLICKS env var partially addresses this, but it also disables clicking to expand/collapse tool output (e.g. "Ran 2 shell commands"), which is useful UX.

My specific pain point: clicking the terminal window to ensure focus before using arrow keys accidentally accepts or denies permission prompts, requiring me to re-prompt Claude to retry the action. A granular option to disable clicks only on interactive prompt elements (yes/no dialogs, menu selections) while preserving clicks on collapsible output would solve this cleanly.

<img alt="Image" width="1036" height="204" src="https://private-user-images.githubusercontent.com/46447406/614013870-6dfa5ab0-c169-4546-ae02-366d89c4031a.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODI2Mzg1OTEsIm5iZiI6MTc4MjYzODI5MSwicGF0aCI6Ii80NjQ0NzQwNi82MTQwMTM4NzAtNmRmYTVhYjAtYzE2OS00NTQ2LWFlMDItMzY2ZDg5YzQwMzFhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA2MjglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNjI4VDA5MTgxMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTA1YmQ3NjdlZjUzN2I2NDhkOGU4OWI2ZjVmZjkyOTgxNzIzODRmNWE4OWUzNjA4ZjRiOGFhYjdiNDQ1OWJlY2QmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.pArfcstAI-a6xWBHjZ93DzGc6RsAeb1jZDF3hM1cChM"> Looks like the latest version includes this! Tested and working. I think this can be closed :)

Doesn't work for me correctly. Mouse clicks are disabled, but also text selection.

Same here.

IMO the option should just be to just disable picking options by mouseclick. All other mouse actions should be preserved.

Or submitting a security prompt option could require two clicks: one to select and a second to submit.

The current behavior is definitely somewhere on the scale from annoying to disastrous.

The mouse-click behavior is proving increasingly frustrating and dangerous.
If I click anywhere in the window (to focus) claude 'accepts' one of the options and proceeds.

I agree with gijsbeijer; don't treat a mouse click like hitting enter key to 'confirm an option'. I'd much rather click to focus, then hit enter key.

How annoying this feature is. I also was accidentally selecting answers in AskUserQuestion prompts, so I searched and found CLAUDE_CODE_DISABLE_MOUSE_CLICKS. Except now I cant select text to copy it! How are those the same thing???

Another data point: macOS + Ghostty, fullscreen TUI.

Tried both existing knobs and neither combination works:

• CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 — stops the accidental prompt clicks, but the mouse is still captured, so native drag-to-select is dead (Shift+drag only). Unusable for copy-heavy workflows.
• CLAUDE_CODE_DISABLE_MOUSE=1 — native selection works again, but now the wheel does nothing: no scrollback in the alt screen, so the only way through history is PgUp/PgDn (fn+arrows on a Mac keyboard).

So today it's pick-two-of-three between wheel scroll, native selection, and click safety. One possible zero-config fix: when mouse reporting is off, terminals with alternate-scroll (xterm alternateScroll, Ghostty supports it) translate wheel events to Up/Down arrows in the alt screen — if the fullscreen viewport treated those as scroll, CLAUDE_CODE_DISABLE_MOUSE=1 would get wheel scrolling back for free, no new mode needed.

@J-Swift Have found that shift + click and drag will highlight text for copying with CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1

The scroll-only mode requested here shipped as CLAUDE_CODE_DISABLE_MOUSE_CLICKS (v2.1.195), and it does keep the wheel — but it comes with a side effect worth flagging on this thread: it does not give the terminal its text selection back.

Measured on 2.1.220 by capturing the raw stream of the fullscreen TUI in a pty:

• CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 → the TUI still emits ?1000h ?1006h
• CLAUDE_CODE_DISABLE_MOUSE=1 → emits nothing at all

?1000h is what makes the terminal hand mousedown to the application, so with the scroll-only mode a plain drag still selects nothing. The clicks stop reaching the TUI's own widgets — which is what this issue asked for — but the terminal remains in mouse-reporting mode. Anyone who came here for "no accidental clicks and I can still copy text with the mouse" only gets the first half.

If the goal is to preserve both wheel scrolling and native selection, the terminal has to stop reporting button presses; with the DEC modes alone there is no way to report only the wheel, since ?1000h covers all buttons including wheel buttons 64/65. A practical alternative is to leave that arbitration to the terminal — xterm.js has a mouseEventsRequireAlt option that keeps tracking armed but only while a modifier is held, so selection stays available by default (it is simply not exposed as a VS Code setting today).

Worth knowing meanwhile: Shift + drag forces a local selection in xterm/xterm.js regardless of what the application armed.