CLI TUI: mouse wheel does not scroll the transcript (mouse reporting is enabled but the main transcript view has no wheel handler)

Cline Surface

CLI

Cline Version

3.0.62

What happened?

In the CLI interactive TUI, the mouse wheel does not scroll the conversation/transcript output at all. Once the output grows past the viewport, scrolling the wheel over the transcript does nothing — neither Cline's own view scrolls nor the terminal's native scrollback (because Cline has captured the mouse). PageUp / PageDown do work.

Expected: the mouse wheel scrolls the transcript — up = toward older output, down = toward newer — the same way PageUp/PageDown already do. At minimum, Cline should not silently swallow the wheel so the terminal's own scrollback keeps working.

Net user-visible effect: over the transcript area, wheel input is captured by the TUI and then dropped, so the user cannot wheel-scroll at all.

Steps to reproduce

1. Run the interactive CLI (cline) — v3.0.62, installed via npm (the cline shim resolves to the native binary in @cline/[email protected]).
2. Run it inside a terminal that implements xterm mouse reporting. Reproduced here in Tabby 1.0.235 (xterm.js / WebGL renderer) on Windows 10; issue #11531 reports the same family of symptoms in VTE terminals (Ptyxis / GNOME Terminal) on Linux.
3. Send a prompt (or run a tool) that produces output longer than the viewport.
4. Scroll the mouse wheel over the transcript → nothing moves.
5. Press PageUp / PageDown → the transcript scrolls as expected.

A smaller secondary note: Shift+wheel also does nothing here (Tabby's xterm.js deliberately skips local scrolling when Shift is held), so there is no wheel-based escape hatch either.

Provider/Model

N/A — this is a pure UI/terminal issue and is reproducible before any model call.

Diagnostics

cline --version:

3.0.62

System Information

OS: Windows 10 Pro 22H2 (build 19045.6456)
Terminal: Tabby 1.0.235 (xterm.js / WebGL renderer)
Shell: cmd.exe + Clink
CPU: Intel Xeon W-2123
GPU: NVIDIA Quadro P1000 (4 GB)
RAM: 16 GB

Root cause (from inspecting the shipped binary)

I inspected the shipped cline.exe (@cline/[email protected], ~137 MB native binary using OpenTUI). The behaviour is explained by three things:

1. Mouse reporting is enabled unconditionally by default. The bundled OpenTUI renderer turns mouse reporting on with no user-facing toggle:

get useMouse(){return this._useMouse}
set useMouse($){if(this._useMouse===$)return;if(this._useMouse=$,$)this.enableMouse(),this.requestRender();else this.disableMouse()}
// ...
... this._useMouse=!0, this.lib.enableMouse(this.rendererPtr, this.enableMouseMovement)

So the TUI emits DECSET 1000/1002/1003/1006h on startup (all present in the binary) and the terminal begins forwarding wheel/mouse events to the app instead of scrolling its own buffer.

2. The only scroll handler belongs to the internal console panel, and it is bounds-gated. The sole mouse-wheel handler in the TUI is on the embedded console/debug panel, and it only fires when the pointer is inside that panel's rectangle:

handleMouse($){
  if(!this.isVisible) return !1;
  let Z = $.x - this.consoleX, Q = $.y - this.consoleY;
  if(Z < 0 || Z >= this.consoleWidth || Q < 0 || Q >= this.consoleHeight) return !1;
  if($.type === "scroll" && $.scroll){
    if($.scroll.direction === "up")   this.scrollUp();
    else if($.scroll.direction === "down") this.scrollDown();
    return !0
  }
  // ... drag-select / copy button handling ...
}

3. The main transcript view is only wired to keyboard actions — it has no mouse/scroll binding. The only transcript scroll bindings are the keyboard ones, which is exactly why PageUp/PageDown work:

var sX = {
  messages_page_up:   [{name:"pageup"}, {name:"b", ctrl:!0, meta:!0}],
  messages_page_down: [ /* ... */ ]
};
// ...
switch(O){
  case "messages_page_up":   W.scrollBy(-W.height/2); return;
  case "messages_page_down": W.scrollBy( W.height/2); return;
  // ...
}

4. There is no way to opt out. A string search of the binary for --no-mouse / a user-facing "disable mouse" setting finds only the internal disableMouse render API — there is no flag or config option for a user to turn mouse reporting off.

Conclusion: with the pointer over the transcript, the wheel event is captured by the TUI (mouse reporting is on) but consumed by no widget, and it is not passed back to the terminal. Result: neither Cline nor the terminal scrolls, while the keyboard scroll path works fine.

Suggested fix

• Primary: add a wheel/scroll handler to the main transcript scroll view, mapping scroll.direction → scrollBy(±N lines), mirroring the existing messages_page_up / messages_page_down handlers. This makes the wheel behave like PageUp/PageDown and fixes the issue for every terminal.
• Complementary: expose an escape hatch to disable mouse reporting (e.g. a --no-mouse flag or a useMouse config setting), so users who prefer their terminal's native scrollback are not blocked. This is the same request made in #11531 for the VTE drag-select / right-click symptoms — one switch would cover both reports.

Related

• #11531 — "CLI TUI: mouse right-click copy/paste and drag-select don't work in VTE terminals (Ptyxis/GNOME Terminal)". Same underlying cause (TUI enables xterm mouse reporting; the app handles only part of the mouse event space), different symptom and platform.