TUI re-emits entire conversation history into scrollback on Windows Server (no GPU, over RDP), causing visible "flooding"

Open 💬 2 comments Opened Aug 14, 2026 by RioWu

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.147.0 (latest stable as of 2026-08-13)

What platform is your computer?

Windows Server (dual Xeon E5 v4 / Broadwell-EP, no GPU, only BMC 2D display chip),
accessed via RDP. Windows version is older (no Windows Terminal available).

Which terminal emulator are you using?

Reproduced in both:

ConEmu (Cmder 1.3.25), software GDI rendering
bare conhost (plain cmd.exe / powershell.exe window)

What issue are you seeing?

During interactive TUI sessions, Codex periodically re-emits the whole prior
conversation into the terminal scrollback — previous messages appear again as
duplicated blocks, flooding the visible area. This happens not only when an
approval/permission dialog appears, but also spontaneously without any dialog
(possibly correlated with console resize events delivered when the RDP session
renegotiates display geometry).

On fast local terminals (e.g. Windows Terminal on a desktop), the same re-emit
presumably happens but is too fast to notice. On this software-rendered,
RDP-transported path, re-printing a long history takes seconds and makes the
TUI nearly unusable.

What steps can reproduce the bug?

On a GPU-less Windows Server over RDP, open cmd.exe (bare conhost).
Run codex, have a conversation long enough to exceed one screen.
Trigger a viewport change (approval prompt) or wait / interact; the previous

conversation is reprinted into scrollback.

What is the expected behavior?

Finalized history is written to scrollback exactly once. Viewport relayouts
(approval prompts, resizes) should be confined to the active viewport and must
not re-emit historical transcript into the primary scrollback.

What I already tried (none helped)

tui.alternate_screen = "always" and "never"
Raw output mode (Alt-R / /raw)
tui.animations = false, tui.show_tooltips = false
Fixed terminal window size; tab bar and scrollbar pinned in ConEmu
Bare conhost (no terminal emulator) — same flooding

Possibly related issues

#22936 (TUI stores finalized history in real scrollback)
#30745 (scrollback rows disappear after inline viewport height changes)
#36995 (TUI scrollback corruption in Windows Terminal)
#35335 (loses terminal scrollback history after long responses)

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 14 days ago

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

#37759
#37635

Powered by Codex Action

jdcodes1 · 10 days ago

This matches the resize-reflow replay traced in #38923's sibling, https://github.com/openai/codex/issues/38839#issuecomment-5313909518 — same mechanism, RDP flavor.

On resize (or a deferred resize consumed at the next draw/focus/keypress — your "spontaneously without any dialog" case), reflow_transcript_now clears the screen with an immediately-flushed CSI 2J/3J outside any synchronized update, then queues the entire reflowed transcript, which is flushed at the next draw (tui/src/app/resize_reflow.rs#L461-L487, custom_terminal.rs#L528-L545). The visible clear-then-replay is that gap; on a software-rendered RDP path the replay of thousands of rows takes seconds instead of milliseconds — you're seeing the same non-atomicity everyone has, just in slow motion. RDP geometry renegotiation is a prolific resize-event source, hence the periodicity.

Fix is the one proposed there: defer the clear into the same synchronized update that flushes the queued rows. Interim relief on your setup: the per-terminal reflow row cap (resize_reflow_cap.rs) bounds how much history is replayed — the config knob terminal_resize_reflow can reduce it.