Windows Terminal scroll, selection, and copy lock during streaming persists with no-alt-screen/raw-output/animations=false

Codex version

codex-cli 0.145.0

Environment

• Windows 11 Professional 10.0.26200
• Windows Terminal (CASCADIA_HOSTING_WINDOW_CLASS)
• PowerShell 7 and Windows PowerShell launch paths both reproduced

Problem

While Codex is actively generating/rendering, Windows Terminal cannot reliably scroll, maintain a text selection, or copy selected text. The three capabilities return together when active rendering stops. The window and process remain responsive throughout.

Reproduction

1. Configure:

[tui]
alternate_screen = "never"
raw_output_mode = true
animations = false

1. Launch a fresh process explicitly:

codex --no-alt-screen -c tui.animations=false

1. Ask for a long multi-paragraph response.
2. While output is active, attempt to scroll upward or drag-select/copy earlier text.

Result

The terminal continues to repaint/update and native scrolling/selection is disrupted until generation ends. This reproduces even though the process command line proves both --no-alt-screen and tui.animations=false were applied.

Instrumented evidence

A separate Win32/UIA observer sampled the exact Windows Terminal HWND without injecting input:

• no-alt-screen controlled run: 11 samples, 10 text-buffer transitions, 0 UIA failures;
• no-alt-screen + animations disabled controlled run: 11 samples, 7 transitions, 0 UIA failures;
• PrintWindow capture succeeded during the affected interval;
• user independently confirmed the scroll/selection/copy lockout on the freshly launched process.

This rules out an OS window hang and shows that disabling alternate-screen and animation does not eliminate active TUI buffer updates. Raw-output startup also did not restore reliable native interaction during generation.

Expected

With alternate screen disabled and raw output enabled, native Windows Terminal scrollback, selection, and copying should remain usable while a turn is streaming.

Notes

A static transcript overlay/companion is a workaround, not a fix. Related reports discuss alternate-screen and redraw behavior, but this reproduction specifically demonstrates persistence on Windows Terminal with all currently documented mitigation settings enabled together.