[Bug] TUI Text Disappearing / Screen Buffer Rendering Regression on Windows PowerShell (Introduced post-v0.130.0, present in v0.131.0)
What version of Codex CLI is running?
0.131.0
What subscription do you have?
pro
Which model were you using?
gpt-5.5
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
Windows Terminal (PowerShell)
Codex doctor report
What issue are you seeing?
<img width="593" height="295" alt="Image" src="https://github.com/user-attachments/assets/c272ef01-ad80-473a-a3e8-aac0b6a89b37" />
<img width="707" height="214" alt="Image" src="https://github.com/user-attachments/assets/2959c675-4f7a-4435-a023-3e0237d53250" />
What steps can reproduce the bug?
The issue is a terminal rendering regression introduced sometime after version v0.130.0 and is highly severe in v0.131.0. The Codex CLI's internal TUI layout engine fails to properly synchronize with the Windows console host (conhost.exe) or Windows Terminal virtual terminal sequences during text streaming, line wrapping (reflow), or scrolling. Downgrading the package to v0.130.0 completely eliminates the issue, confirming a regression in the recent UI updates.
What is the expected behavior?
_No response_
Additional information
_No response_
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Because this is Windows + PowerShell + post-0.130.0, I would look closely at the boundary between terminal repaint invalidation and wrapped-line width accounting.
When text disappears only after a rendering/update cycle, the bug is often not the text itself but stale buffer ownership: one layer thinks cells are still valid while another thinks the viewport needs a fresh paint. A tiny rendering receipt around resize/maximize/reflow events usually makes regressions like this much easier to pin down than screenshot-only reports.
This issue still persists in v0.132.0.
See screenshot below:
<img width="1104" height="428" alt="Image" src="https://github.com/user-attachments/assets/80ab3a4a-43ab-4998-bbec-495ee6874800" />
This smells like the renderer losing a truthful model of screen state once wrap or scroll happens under PowerShell and Windows Terminal, not just a cosmetic paint glitch.
The thing I'd instrument first is a tiny render receipt around every bad frame or wrap boundary:
If 0.130.0 is clean and 0.131.0 regresses, a diff on those receipts around wrap or scroll should show whether the break is in layout math or in the write strategy against conhost or Windows Terminal.
If you end up adding diagnostics, I'd be curious whether one small repro receipt per bad frame is enough to isolate it.
A render receipt with wrap mode, scroll state, viewport, repaint mode, and terminal identity would make these bugs far less hand-wavy. Screenshot repros help, but they don't tell you which branch of the renderer actually misbehaved.
I just updated to v0.134.0 which was released today, and I can confirm that the issue is now fully resolved and everything is working as expected.
Thank you for the quick fix! Closing this issue now.