[BUG] Mouse wheel does not scroll in CLI TUI — both main view and Ctrl+T overlay (Windows, v0.146.0)

[BladeDancer743]

Environment

• Codex CLI: v0.146.0 (npm install)
• OS: Windows 11 10.0.22631
• Terminal: Windows Terminal + pwsh 7.4
• Config tested:

toml [tui] alternate_screen = "auto" scroll_wheel_lines = 3 scroll_trackpad_lines = 1

Verified with --strict-config — all fields recognized. No effect.

Repro Steps

1. Run codex in Windows Terminal
2. Have a conversation that exceeds one screen of output
3. Try to scroll up with mouse wheel to see previous content
4. Also try Ctrl+T to open transcript overlay, then mouse wheel

Expected

Mouse wheel scrolls the conversation view up/down, like Claude Code or any normal terminal app.

Actual

• Main view: mouse wheel does nothing at all
• Ctrl+T overlay: keyboard navigation works but mouse wheel does nothing
• The only way to see previous content is keyboard (PgUp/PgDn/Ctrl+T + arrows)

Root Cause Analysis

The ui.scroll_wheel_lines config exists but the TUI views (main chatwidget, transcript overlay) don't bind Event::Mouse(ScrollUp/ScrollDown). The config knob exists without the wiring.

Related Closed Issues (no real fix)

• 🐛 Mouse / scroll in zellij doesn’t let me view earlier TUI conversation (alt-screen interaction) #2836 (closed as duplicate of Codex client output truncated when scrolling in Zellij #2558)
• Codex client output truncated when scrolling in Zellij #2558 (closed with PR fix: add tui.alternate_screen config and --no-alt-screen CLI flag for Zellij scrollback #8555)
• Mouse mode scrolling is not smooth #1502 (closed, no fix)
• Text clipped when scrolling in TUI #7733 (closed)

None resulted in functional mouse wheel scrolling in the CLI TUI.

Context

This is NOT the Desktop app scrollbar issue (#20886). This is about the CLI TUI specifically. Claude Code handles this correctly — users expect the same from Codex CLI.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Windows Codex CLI loses terminal scrollback history after long responses #35335

Powered by Codex Action

[rbudnar]

Additional Linux/Zellij reproduction of this issue:

• Codex CLI: 0.146.0
• OS: Ubuntu 24.04, Linux x86_64
• Terminal: Ghostty 1.3.1 (TERM=xterm-ghostty)
• Multiplexer: Zellij 0.44.3
• Codex config already uses:

[tui]
alternate_screen = "never"

Mouse-wheel scrolling intermittently stops working specifically in Codex panes; other agent TUIs in adjacent Zellij panes continue to scroll normally. Resizing the terminal or toggling the pane/window fullscreen sometimes forces a repaint and temporarily changes the behavior, but is not reliable. The same failure can affect multiple Codex panes in one Zellij session.

Ctrl+T followed by keyboard navigation (PageUp/PageDown, arrows, or j/k) is a usable workaround for viewing the transcript, but it does not restore normal mouse-wheel scrolling. Zellij's own scroll mode is also not a complete workaround because Codex's inline renderer can redraw in place instead of accumulating the full transcript in pane scrollback.

This suggests the missing Event::Mouse(ScrollUp/ScrollDown) handling described in the issue is cross-platform and still reproduces with Zellij's 0.44.x Codex scroll-region mitigation and Codex's no-alt-screen mode.

[trevi00]

Additional Windows reproduction and source-path note:

Environment

• Windows 11 (10.0.26200)
• Codex CLI: 0.145.0+harness.mcp-postcompact.1
• PowerShell host

This is a custom build, so I am reporting it as corroborating behavior rather than claiming a clean stock-version regression. The local PostCompact change does not touch the TUI or message-history files discussed below.

Observed behavior

In the main TUI, wheel input can do more than fail to scroll: it can replace the composer contents with previously submitted prompts while the transcript remains stationary. Scrolling therefore mutates the draft prompt instead of navigating the conversation.

This matches the user-visible symptom reported in #36158 and appears to be another presentation of the same input-routing problem tracked here.

Plausible source path

A source inspection shows a concrete mechanism that can produce this behavior:

1. Tui::enter_alt_screen() enables Crossterm EnableAlternateScroll, with an inline comment that terminals may translate wheel input into arrow keys.
2. The composer handles Up/Down at history-navigation boundaries by calling history.navigate_up() / history.navigate_down().
3. That history is backed by the global prompt history (~/.codex/history.jsonl), not the current thread transcript.

This explains why affected environments can present either a no-op wheel or prompt-history cycling, depending on how the terminal or multiplexer translates and routes wheel input.

Expected contract

Wheel input intended for transcript navigation should never mutate composer text. Transcript scrolling should consume the input when the transcript is the target, while prompt-history navigation should remain an explicit composer action.

I hope this additional symptom and code-path detail helps narrow the fix without opening another duplicate issue.