Mouse wheel scrolling doesn't work in legacy Windows console (conhost.exe) due to alternate screen buffer

[TripQi]

What version of Codex CLI is running?

0.104

What subscription do you have?

pro

Which model were you using?

any model

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What terminal emulator and version are you using (if applicable)?

vscode、windows terminal、git bash

What issue are you seeing?

When Codex CLI output exceeds one screen, mouse wheel scrolling does not work in legacy Windows console host
(conhost.exe). Content is rendered in an overwriting/overlay fashion with no way to scroll back. The same scenario
works correctly in Windows Terminal.

What steps can reproduce the bug?

1. Open PowerShell or Git Bash outside of Windows Terminal (i.e., using the legacy conhost.exe console host)
2. Run codex and submit a prompt that generates a long response (exceeding one screen)
3. Try to scroll up with the mouse wheel to view earlier content

What is the expected behavior?

Expected Behavior

The user should be able to scroll up/down through the full response content using the mouse wheel.

Actual Behavior

• The output cannot be scrolled with the mouse wheel
• Content appears to be rendered in an "overlay" fashion — new content overwrites previous content in the same screen
  area
• The same operation in Windows Terminal works correctly (scrollable)

Additional information

Title: Mouse wheel scrolling doesn't work in legacy Windows console (conhost.exe) due to alternate screen buffer

Description:

Bug Report

Summary

When Codex CLI output exceeds one screen, mouse wheel scrolling does not work in legacy Windows console host
(conhost.exe). Content is rendered in an overwriting/overlay fashion with no way to scroll back. The same scenario
works correctly in Windows Terminal.

Environment

• OS: Windows 10 Pro (10.0.19045)
• Terminals tested:
  • PowerShell (conhost.exe) — bug present
  • Git Bash (conhost.exe) — bug present
  • VSCode （pwsh）— bug present
  • Windows Terminal — works correctly

Steps to Reproduce

1. Open PowerShell or Git Bash outside of Windows Terminal (i.e., using the legacy conhost.exe console host)
2. Run codex and submit a prompt that generates a long response (exceeding one screen)
3. Try to scroll up with the mouse wheel to view earlier content

Expected Behavior

The user should be able to scroll up/down through the full response content using the mouse wheel.

Actual Behavior

• The output cannot be scrolled with the mouse wheel
• Content appears to be rendered in an "overlay" fashion — new content overwrites previous content in the same screen
  area
• The same operation in Windows Terminal works correctly (scrollable)

Root Cause Analysis （I guess）

Codex CLI uses Ink (React for terminal) which renders in fullscreen mode by default, activating the alternate screen
buffer (\x1b[?1049h).

The alternate screen buffer has no scrollback history by design. Scrolling within the alternate screen buffer relies
on the application receiving mouse wheel events (via VT mouse tracking sequences) and handling the scrolling
internally.

• Windows Terminal correctly forwards mouse wheel events as VT sequences to the application, allowing Ink to handle
  scrolling
• conhost.exe (the legacy Windows 10 console host used by standalone PowerShell and Git Bash) does not properly
  forward mouse wheel events to the application when in alternate screen buffer mode

For comparison, Claude Code CLI does not use the alternate screen buffer — it outputs content directly to the normal
buffer with scrollback, so mouse wheel scrolling works natively in all terminal environments.

Possible Solutions

1. Detect when running under conhost.exe (e.g., check for absence of WT_SESSION env var) and fall back to
   non-fullscreen rendering mode
2. Provide a CLI flag (e.g., --no-alternate-screen or --scroll-mode) to disable alternate screen buffer usage
3. Use Ink's fullscreen: false option when the terminal doesn't support proper mouse event forwarding