Bug: fullscreen TUI hover-to-jump-to-previous-prompt affordance stopped working after v2.1.246 (onMouseMove handlers removed in v2.1.251)

Description

The fullscreen TUI (saved tui: fullscreen setting) has an undocumented mouse navigation affordance: when you scroll up in the transcript and hover the mouse over a previous user prompt (the highlighted user-message row), the row shows a hover background and a floating double-chevron-up indicator appears; left-clicking it jumps the viewport to the previous user prompt. It pairs with the "Jump to bottom (Ctrl+End)" pill that resumes auto-follow.

This affordance works in v2.1.246 and is broken in every release after it. It is not mentioned in the fullscreen docs, the changelog, or the keybindings list, so I am filing this to report the regression and ask for it to be restored (or its removal documented).

A/B reproduction (same machine, same terminal, binaries side-by-side from ~/.claude/local/share/claude/versions/)

1. Start Claude Code with at least 3 user prompts in the session, fullscreen renderer active.
2. Scroll up with the mouse wheel (auto-follow pauses, "Jump to bottom (Ctrl+End)" pill appears).
3. Move the mouse over a previous user prompt row.

Observed:

| Version | Hover highlight + chevron appears | Click jumps to previous prompt |
|---|---|---|
| 2.1.246 | ✅ yes | ✅ yes |
| 2.1.247 | ❌ no response | ❌ no |
| 2.1.248 | ❌ no response | ❌ no |
| 2.1.251 | ❌ no response | ❌ no |

• 2.1.246: verified visually on Windows 11 (native terminal) — recorded a screen capture of the working behavior.
• 2.1.247 / 2.1.248: verified broken on Windows 11 native terminal (during a sequential downgrade 251 → 248 → 247 → 246, the feature came back only at 246).
• 2.1.251: verified broken on WSL2 + Windows Terminal, and additionally with a scripted PTY harness (see below).

Supporting evidence: mouse handlers removed in 2.1.251

Binary analysis of the official Linux builds (same JS bundle ships to all platforms) — count of hover/mouse handler identifiers:

| Identifier | 2.1.246 | 2.1.248 | 2.1.251 |
|---|---|---|---|
| onMouseMove | 9 | 9 | 0 |
| onMouseEnter | 51 | 51 | 39 |
| onMouseLeave | 46 | 46 | 34 |
| onHover | 26 | 26 | 16 |

In 2.1.251 every onMouseMove handler is gone, so hover-driven affordances (including this one) cannot work there. The underlying jump machinery is still present in all three versions (the transcript viewport component still contains the "walk backwards to the message that has promptText" function plus scrollToIndex, trackStickyPrompt, and the userMessageBackgroundHover style), which is why this looks like an unintentional regression rather than an intentional removal.

PTY harness cross-check (2.1.251, WSL2)

To rule out terminal-side mouse issues, I ran each version under a Python PTY (120×40, TERM=xterm-256color) and injected SGR mouse events directly:

• Startup mouse-mode negotiation is identical in 2.1.246/248/251: ?1000h ?1002h ?1003h ?1004h ?1006h (SGR + button-event + any-motion all requested).
• Wheel-up events (ESC[<64;…M) produce identical, correct behavior in all three versions: auto-follow pauses and the "Jump to bottom" pill appears — so the injection path is valid.
• Any-motion events (ESC[<35;col;rowM) produce no hover response in any version in the synthetic PTY, including 2.1.246 — the harness apparently lacks whatever condition activates the hover UI (possibly feature-flag gated), so it cannot demonstrate the 246 working case headlessly. It does, however, confirm that 2.1.251 never responds to hover.

Suspected regression window

• 2.1.247 includes: "Fixed text like <35;150;7M being inserted into the prompt when a mouse report arrived split across reads right after the escape prefix" — a change to mouse-report parsing, right where no-button motion (35) reports are handled. Feature code is byte-identical between 246 and 248 at the token level, so a parsing regression there would explain why 247/248 behave like 251 on real terminals.
• 2.1.251 includes: "Improved CPU usage during turns in interactive sessions by cutting redundant UI re-renders" — plausibly where the onMouseMove handlers were dropped.

Expected behavior

Hovering a previous user prompt in the fullscreen transcript highlights it and shows the jump affordance; clicking jumps the viewport to that/previous user prompt, as in v2.1.246.

Actual behavior

No hover feedback and no click-to-jump on any version after 2.1.246.

Environment

• OS: Windows 11 (native terminal) and WSL2 (Linux …microsoft-standard-WSL2) + Windows Terminal
• Install method: native installer (claude install <version>, binaries compared side-by-side)
• Renderer: fullscreen (saved tui setting)
• Auto-update disabled; versions tested explicitly via claude install

Workaround

Keyboard navigation still works in all versions: Ctrl+O (transcript mode) → { / } to jump between prompts. But the mouse affordance is a meaningful accessibility/UX loss — happy to provide the screen recording of the 2.1.246 working behavior if useful.