[Bug] Mouse wheel dead in the TUI inside the VS Code integrated terminal since 1.105, root cause is xterm not opencode

[Xukun-Liu]

Description

The mouse wheel is dead in the TUI inside the VS Code integrated terminal. Arrow keys work, but scrolling the wheel does nothing. This started with VS Code 1.105.

The root cause is not opencode. The wheel events are silently swallowed by xterm.js, the terminal emulator bundled in VS Code, in the alt buffer. The regression was introduced in xterm 5.6.0-beta.119. I verified this with byte-level A/B testing between VS Code 1.104 (beta.118) and 1.105 (beta.119): a raw-mode pty listener plus CDP-injected wheel events. Pixel deltas under roughly 50px produce zero bytes on the pty, so the app never sees them. This affects trackpads, smooth wheels and low-sensitivity mice; fast-scrolling mice can pass the threshold, which is why it is so easy to miss.

Analysis and fix already submitted upstream:

• xterm.js issue with full evidence: [Bug] Wheel input is silently dropped in the alt buffer when consumeWheelEvent() rounds to zero lines xtermjs/xterm.js#6105
• xterm.js fix PR: fix: don't swallow wheel events in the alt buffer when consumeWheelEvent() returns 0 xtermjs/xterm.js#6104

Opening this here so opencode users hitting it in VS Code have a searchable reference, and a place to pick up the fix once VS Code ships a newer xterm.

Plugins

None

OpenCode version

Latest (dev build), run inside the VS Code integrated terminal

Steps to reproduce

1. VS Code 1.105 or later on Windows, open the integrated terminal
2. Start opencode (TUI)
3. Hover the list and scroll the mouse wheel
4. Trackpad / smooth wheel / low-sensitivity mouse: scroll does nothing

Screenshot and/or share link

Not applicable, see byte-level evidence in the linked xterm.js issue

Operating System

Windows 11

Terminal

VS Code integrated terminal (bundled xterm)

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The issue does not use one of the required issue templates (Bug Report, Feature Request, or Question). Please resubmit using the Bug Report template, which requires a Description field with content about the bug.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of or related to existing issues. Please check:

• tui.json "mouse": false causes mouse wheel to fall back to arrow keys, triggering prompt-history navigation instead of scrolling the message viewport #35295: Mouse wheel scroll behavior in TUI with mouse: false config — similar scroll/wheel issues in the TUI
• TUI: mouse wheel scrolls by message blocks - should scroll line-by-line #39763: TUI mouse wheel scroll behavior (scrolls by message blocks vs line-by-line)

If you believe this was flagged incorrectly, please let a maintainer know.

[Xukun-Liu]

Updated the body to follow the Bug Report template (added a Description section). Requesting re-check of the compliance label.

[github-actions]

Thanks for updating the issue to follow the Bug Report template! The issue now meets our contributing guidelines and the compliance flag has been removed. We appreciate the thorough investigation and upstream references.

[Xukun-Liu]

One more thing that makes this fix necessary in practice: my company's intranet only provides older VS Code builds (upgrades are controlled by IT/security policy), and this bug affects every version from 1.105 onward, including those. So anyone stuck on an older VS Code in a locked-down environment has no way to get around the dead wheel in the TUI, no matter how many updates are released upstream. A fix in xterm is the only way it reaches these setups.

[Xukun-Liu]

The xterm.js fix PR link above (#6104) died together with its head fork — it has been resubmitted as xtermjs/xterm.js#6118. Also reported directly to VS Code since the bundled xterm affects all integrated terminal users on 1.105+: microsoft/vscode#331756.