fix-mouse-wheel-2

Metadata

Description

## Description
Regression report 2026-04-29 evening. Mouse wheel scrolling in the wg TUI is now passing arrow-key events through to the inner app (claude / codex) instead of scrolling the outer scrollback. Claude itself is detecting this and emitting the warning:

> 'Scroll wheel is sending arrow keys · use PgUp/PgDn to scroll in claude code'

Symptoms:
- Affects BOTH claude and codex chat views
- Worse under tmux (where it previously worked with both touch AND wheel)
- Touch scroll behavior also degraded
- Worked correctly earlier today

User quote: 'getting this error now: Scroll wheel is sending arrow keys · use PgUp/PgDn to scroll in claude code... happens now in the tui in both claude code and codex chat views. and it worked before... also this happens in tmux but before i could scroll with finger and scroll wheel.'

## Likely culprit
`implement-tui-scroll` (commit bfb231c7e) shipped the keyboard scroll-mode toggle. It almost certainly wired wheel-to-key translation as the implementation mechanism for in-scroll-mode wheel scrolling, but failed to scope it correctly:
- Translating wheel events to arrows ALWAYS (not just in scroll mode)
- OR routing translated keys to the inner-app PTY (where claude sees them) instead of the outer-pane scrollback handler
- OR clobbering `fix-mouse-wheel` (commit 8ddeb9e42)'s direct wheel→scroll wiring

## Expected behavior (regression target)
- **Outside scroll mode**: mouse wheel scrolls the OUTER scrollback. Inner app sees nothing. (This is what fix-mouse-wheel shipped.)
- **Inside scroll mode**: mouse wheel scrolls the OUTER scrollback (same as outside). PgUp/Down/arrows from keyboard ALSO scroll the OUTER scrollback. Inner app sees nothing.
- **Outer scrollback only**: wheel events should NEVER be translated into arrow-key events forwarded to the inner app's PTY. That's the bug.

## Investigation
1. Inspect the wheel-event handling added/changed in implement-tui-scroll. Look for any translation from `MouseEventKind::ScrollUp/Down` to `KeyCode::Up/Down` being forwarded to the PTY's stdin instead of routed to the scrollback navigator.
2. Check whether scroll-mode's keymap implementation created a unified handler that handles wheel and key events the same way — that would explain why wheel events end up looking like keypresses.
3. Verify fix-mouse-wheel's wiring is still intact post-implement-tui-scroll. If it was rewritten / replaced, that's the regression.
4. Check tmux interaction: under tmux, mouse events route through tmux's mouse mode first. Tmux can be configured to translate wheel events to arrows for legacy apps. If our TUI is ALSO translating, the user gets double-translated arrows. The fix should make our TUI consume wheel events at the outer layer regardless of tmux mode.

## Validation
- [ ] Failing test or repro: open claude chat in wg TUI, mouse wheel up. Pre-fix: claude shows the 'arrow keys' warning. Post-fix: outer scrollback scrolls; claude sees nothing.
- [ ] Same for codex chat
- [ ] Test under tmux: same behavior — wheel scrolls OUTER, inner app sees nothing
- [ ] Test with touch scroll: behavior is identical to wheel (no asymmetry — both consumed at outer layer)
- [ ] No regression of fix-mouse-wheel original repro (wheel scrolls codex scrollback)
- [ ] No regression of implement-tui-scroll keyboard mode (toggle still works, PgUp/Down/arrows still scroll outer in scroll mode)
- [ ] cargo build + cargo test pass
- [ ] Permanent smoke scenario added: simulate ScrollUp event into the TUI, assert it does NOT produce a write of arrow-key bytes to any PTY child stdin, and DOES advance the active pane's scroll offset
- [ ] cargo install --path . was run before claiming done

## Process note
This is the kind of bug where 'cargo test passes' is meaningless — the bug is in event routing, which unit tests can't easily catch unless someone wrote them at the routing layer. The smoke scenario above (ScrollUp event → assertion on PTY stdin bytes) is the real test. Don't ship without that scenario passing.

Depends on

• done .assign-fix-mouse-wheel-2

Required by

• (none)

Log

• 2026-04-29T19:27:34.289662515+00:00 Task paused
• 2026-04-29T19:27:38.320655639+00:00 Task published
• 2026-04-29T19:27:57.005662697+00:00 Lightweight assignment: agent=Careful Programmer (f5143935), exec_mode=full, context_scope=task, reason=Careful Programmer is the only programmer agent; Careful tradeoff is ideal for a regression bug requiring precise event routing and comprehensive validation testing.
• 2026-04-29T19:27:58.851456354+00:00 Spawned by coordinator --executor claude --model opus
• 2026-04-29T19:28:13.482780510+00:00 Starting investigation. Inspecting commits bfb231c7e (implement-tui-scroll) and 8ddeb9e42 (fix-mouse-wheel) for the regression.
• 2026-04-29T19:28:20.982869657+00:00 USER CLARIFICATION 2026-04-29: regression timeline is more nuanced than original report. User quote: 'it was fine before in claude code and broken in codex. but now broke in both. still can't scroll codex lol.' Actual timeline: - BEFORE today's fixes: claude wheel scroll WORKED, codex wheel scroll did NOT - AFTER today's fixes (fix-mouse-wheel + implement-tui-scroll): claude is BROKEN (regressed from working) AND codex is STILL broken (didn't get fixed despite being the target) So fix-mouse-wheel didn't actually fix codex, AND introduced a claude regression. Net: WORSE than before in both panes. Implications for the fix: 1. Don't just 'restore the prior claude behavior' — that wasn't full coverage either (codex was broken). Need to make BOTH work consistently. 2. The pre-fix-mouse-wheel claude wheel-scroll path was probably accidental/incidental — wheel events bubbled through to the outer ratatui handler somewhere. fix-mouse-wheel may have inserted explicit handling that captured claude's wheel events and routed them somewhere else (translated to arrows? consumed without action?), AND its codex-targeted handling didn't actually achieve the scroll. 3. The right fix is to route ALL chat-tab wheel events (claude / codex / nex) through the SAME outer-scrollback path, regardless of which inner CLI is in the pane. UPDATED VALIDATION: - [ ] Test claude chat: wheel scroll works (verify the regression is fixed by comparing before / after) - [ ] Test codex chat: wheel scroll works (verify the original target is achieved — what fix-mouse-wheel was supposed to do) - [ ] Test nex chat: wheel scroll works (don't ship a fix that misses one of the three) - [ ] Test under tmux for all three - [ ] Touch scroll: still works for all three - [ ] Symmetry: paste the wheel-event handler code path side-by-side for chat tabs vs other panes; should be identical mechanism
• 2026-04-29T19:28:53.188944782+00:00 USER ADDITIONAL OBSERVATION 2026-04-29: PgUp/PgDn ALSO never worked, even in scroll mode. User hypothesis: 'maybe it's going to the pty client?' User instinct is correct. The bug is broader than wheel-scroll specifically — it's that the entire scroll-input event routing is flawed for chat panes. Every scroll input (wheel, PgUp/PgDn, arrows-in-scroll-mode, possibly even the scroll-mode toggle key) is being forwarded to the inner PTY child instead of intercepted by the outer pane. This means BOTH today's input-related fixes failed: - fix-mouse-wheel: wheel events leak through as arrow keys to inner app (claude warning fires) - implement-tui-scroll: PgUp/PgDn never reach the outer scrollback handler — they're consumed by the inner PTY Diagnosis: chat-pane input dispatch likely forwards to PTY child stdin BEFORE checking whether the event should be intercepted by the outer scroll handler. Order is inverted: should be 'intercept-then-forward', actually is 'forward-then-maybe-intercept' (or just forward, no intercept). REWRITE THE FIX SCOPE: The single root cause is event-routing order in the chat-pane input handler. The fix should: 1. Establish a clear 'outer scroll input' set: wheel events, scroll-mode-toggle key, and (if in scroll mode) PgUp/PgDn/arrows/Home/End/q/Esc 2. Intercept these BEFORE forwarding anything to the PTY child stdin 3. Forward to PTY child only events the outer layer doesn't claim 4. NEVER translate wheel to arrows for forwarding — wheel is consumed at outer layer or dropped, never re-emitted UPDATED VALIDATION (COMBINED scope): - [ ] Mouse wheel scrolls outer scrollback (claude / codex / nex chat panes) - [ ] Touch scroll same - [ ] Scroll-mode toggle key engages scroll mode (status bar updates) - [ ] In scroll mode: PgUp / PgDn / Up / Down / Home / End scroll outer scrollback - [ ] Esc / q exits scroll mode - [ ] Inner app (claude / codex / nex) NEVER sees any of the above events as keyboard input - [ ] Other keys outside scroll mode (typing into chat) STILL forward to inner app — don't break the typing path - [ ] Smoke scenario: deterministic event-injection test that asserts (a) outer scroll offset advances and (b) PTY child stdin receives zero bytes for the entire input sequence - [ ] Test all three handlers + tmux Both originally-filed fixes (fix-mouse-wheel commit 8ddeb9e42 and implement-tui-scroll commit bfb231c7e) failed at the same routing-order bug. Single fix here corrects the routing for all input paths simultaneously.
• 2026-04-29T19:29:39.162119080+00:00 USER NARROWING 2026-04-29: 'pgup/dn was never the way we scrolled' The user never expected PgUp/PgDn to be the scroll mechanism. Mouse + touch is the established UX. The keyboard scroll-mode (implement-tui-scroll) was a NEW feature that didn't land working, but it's not a regression because users weren't relying on it. REVISED SCOPE — narrow back to mouse + touch routing only: - [ ] Mouse wheel scrolls outer scrollback (claude / codex / nex) - [ ] Touch scroll scrolls outer scrollback (claude / codex / nex) - [ ] Inner app does NOT receive these events as keyboard input (no 'arrow keys' warning from claude) - [ ] Test under tmux for all three handlers - [ ] Smoke scenario: ScrollUp event → outer scroll advances + PTY child stdin receives zero bytes DROP from validation: - PgUp/PgDn behavior (separate concern; was never working, not a regression) - Scroll-mode toggle key behavior (separate concern, implement-tui-scroll's broken work) implement-tui-scroll's actual problem (keyboard mode doesn't work) is a separate task if/when the user actually wants keyboard scroll. For now, focus on restoring mouse + touch scroll across all handlers — that's the regression that matters.
• 2026-04-29T19:29:44.885529365+00:00 Plan: forward_chat_wheel was added by fix-mouse-wheel (8ddeb9e42) and forwards Up/Down arrow keys to the inner PTY when in vendor PTY focus mode. claude detects this and warns. Fix: remove the arrow-key forwarding entirely, always navigate the vt100 pane scrollback. Update the existing test to assert the new correct behavior. Add smoke scenario.
• 2026-04-29T19:41:33.177413596+00:00 Implemented fix: forward_chat_wheel now ALWAYS scrolls outer vt100 pane, never forwards arrow keys to PTY child stdin. Added input_bytes_written counter on PtyPane for byte-level test assertions. Updated test mouse_wheel_in_vendor_pty_mode_scrolls_outer_not_inner to assert (a) outer is scrolled, (b) zero bytes written to child stdin. Added smoke scenario tui_mouse_wheel_does_not_send_arrows.sh.
• 2026-04-29T19:41:33.202891751+00:00 Validated: cargo build clean. Mouse-wheel + scroll_mode + pty_pane tests all pass (3+10+55=68 relevant tests). cargo install --path . done. The one failing lib test (config::tests::test_global_config_path) is pre-existing on main — verified by checkout — and unrelated to this change.
• 2026-04-29T19:42:07.392432746+00:00 Committed: a7add925b — pushed to remote
• 2026-04-29T19:42:22.507440213+00:00 Task pending eval (agent reported done; awaiting `.evaluate-*` to score)
• 2026-04-29T19:44:23.596127420+00:00 PendingEval → Done (evaluator passed; downstream unblocks)
• 2026-04-29T20:00:58.452138789+00:00 diagnose-scroll-wheel byte-level finding: the regression was introduced by fix-mouse-wheel (commit 8ddeb9e42), NOT implement-tui-scroll (bfb231c7e). Live capture (wg nex chat tab, post-regression binary at 9de67a5e3): wheel-up notch wrote 9 bytes \x1b[A\x1b[A\x1b[A to child PTY stdin; pre-regression (15c6b2ac7) and post-fix-mouse-wheel-2 (HEAD 745243957) both wrote 0 bytes — confirming this fix correctly reverts the wheel→arrow translation. The implementation merged here passes the byte-level assertion; no rework needed. See diagnose-scroll-wheel logs for the full capture matrix and code citations.