Fullscreen mouse capture degrades scroll and clobbers clipboard on macOS Terminal.app — three separable fixes
Summary
Recent fullscreen/mouse-capture rendering improves in-REPL cursor navigation, but on macOS Terminal.app it introduces three regressions that are worth separating, because they have different root causes and different fixes. Prior requests (#21386, #23581, #62294) got closed as "not planned" or duplicate, I think partly because they framed the ask as "let clicks work without capturing the wheel" — which isn't achievable at the terminal-protocol level. Below is a framing that avoids that dead end.
The protocol constraint (why the naive ask can't work)
Terminal mouse reporting multiplexes clicks and wheel onto one channel — the wheel is reported as buttons 4/5. Once DECSET 1000/1002/1006 is on to get click-to-position, the terminal streams all button events (wheel included) to the app and suspends native scrollback. There is no mode that reports clicks while leaving the wheel to the terminal. So "surgically report clicks only" is off the table, and asking for it just gets closed. The achievable improvements are elsewhere:
Three separable, achievable asks
1. Scroll emulation quality — and a fractional-accumulator bug. With capture on, CC emulates scroll from the wheel bytes, moving in whole text rows. The /scroll-speed runtime command and wheelScrollAccelerationEnabled: false already exist, but both are coarse (see #62294). Worse, fractional speeds are buggy: at e.g. 0.25 lines/notch the sub-line remainder accumulates, so the first few notches show nothing (a dead-zone), then one notch crosses the whole-line threshold and jumps — and the banked remainder appears to be reset on redraw (new output silently drops the accumulated fraction). Net effect: notches are inconsistently eaten, then fire in a burst or vanish. Repro: /scroll-speed 0.25, then make slow fine wheel/trackpad drags while output is streaming. Ask: (a) preserve the fractional accumulator across redraws so notches are never dropped, and (b) make /scroll-speed momentum-aware rather than a single linear knob, so captured-mouse scroll isn't strictly worse than native.
2. Auto-copy-on-select is coupled to mouse capture. Selecting text auto-copies, which clobbers the user's clipboard mid-workflow, and there's no toggle for just this — the only escape is disabling the whole mouse layer via CLAUDE_CODE_DISABLE_MOUSE=1. This is a genuinely separable behavior and should have its own setting (e.g. mouseAutoCopyOnSelect: false), independent of capture.
3. Fullscreen's alternate screen buffer defeats native scrollback entirely. Terminal.app's modifier-bypass (Fn/Shift held) does trigger native scroll even with capture on — but in fullscreen mode it reveals nothing, because fullscreen draws on the alternate screen buffer (like vim/htop). The whole REPL just scrolls off with an empty scrollback; the session history was never written to Terminal's scrollback at all. So the escape hatch that works in normal rendering is structurally dead in fullscreen. This is arguably the deepest issue: fullscreen and native scrollback are fundamentally at odds, and users aren't warned that opting into flicker-free rendering means giving up the terminal's own scrollback of the session. Ask: document this tradeoff explicitly at the /tui fullscreen opt-in, and consider whether visible session content could be mirrored to the main buffer on exit so history isn't lost.
Why this framing
Each of these is real, independently shippable, and none requires violating the mouse-reporting protocol. Splitting them lets the impossible part (clicks-without-wheel) stay closed while the achievable parts move.
Environment
- Claude Code 2.1.206
- macOS, Terminal.app (Apple Terminal)
- Fullscreen / flicker-free rendering enabled