[BUG] Fullscreen rendering: mouse-wheel scrolling stalls / drops frames in VS Code integrated terminal (Windows, v2.1.145) — keyboard scroll unaffected

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

In fullscreen rendering mode (/tui fullscreen), mouse-wheel scrolling through the conversation in the VS Code integrated terminal on Windows stalls and drops frames. Turning the wheel produces no visible movement for ~0.5-2 s at a time; the viewport then snaps forward in a single chunk. Pressing any key (e.g. PgDn, arrow) immediately unsticks the queued movement and triggers a redraw.

Diagnostic detail — input path matters:

| Input | Behavior |
|---|---|
| Mouse wheel | Stalls, drops frames, can be unstuck by any keypress |
| PgUp / PgDn | Smooth, no frame drops |
| Ctrl+Home / Ctrl+End | Smooth |

Since keyboard scroll actions exercise the same render path but go through a different input path, this points at the wheel-event handling / scroll-coalescing logic rather than rendering throughput itself.

What Should Happen?

Mouse-wheel scrolling should be as responsive as PgUp / PgDn, consistent with the fullscreen renderer's behavior in other terminal emulators (e.g. Windows Terminal, where wheel scrolling is smooth on the same machine).

Steps to Reproduce

1. Open the VS Code integrated terminal on Windows 11 (PowerShell)
2. Launch Claude Code: claude
3. Switch to fullscreen rendering: /tui fullscreen
4. Build up enough output to scroll (long conversation or any tool with multi-screen output)
5. Try to scroll back through the conversation with the mouse wheel — observe stalls
6. Use PgUp / PgDn instead — observe smooth scrolling

Claude Code Version

v2.1.145

Platform

Anthropic API

Operating System

Windows 11 (10.0.26200)

Terminal/Shell

VS Code integrated terminal (PowerShell)

Is this a regression?

I don't know

Additional Information

I previously filed #53699 against v2.1.119 with similar symptoms and closed it after a duplicate-detection bot pointed at #45366. In hindsight that was premature: #45366 is a macOS-flavored enhancement request rather than the same Windows bug, and my report was closed without any maintainer review.

This report describes the same class of issue still reproducing on v2.1.145 with a sharper diagnostic (the mouse-vs-keyboard input split above), so it may be a long-standing bug rather than a regression.

Fullscreen rendering itself works correctly (input box pinned to bottom, alt-screen behavior as documented). The bug is specific to mouse-wheel input handling. Setting CLAUDE_CODE_DISABLE_MOUSE=1 avoids it but loses click-to-expand and in-app selection, so it isn't equivalent to a fix.