Codex' responses in CLI TUI are cut off

Also noticing this - windows wsl

Thanks for the bug report. You mentioned this is happening since 0.98.0. Can you confirm that if you downgrade to 0.97.0, the problem goes away? That will verify that it's a regression in the CLI (as opposed to a change in your configuration or something else on your system). If you can confirm that it's something that changed between 0.97 and 0.98, that would help us localize the problem. Thanks!

Me too! Started in 0.98.0, it's so bad that I've had to start asking it to write it's replies to a file.

Note: No idea is this is related - but it's like this happens in the middle of the response too. The visible part seems to sometimes be missing bits, e.g. it's giving me a list of things and I'll see 1) and 3) with some disjointed text sometimes in the middle.

Having it too. I reside to tell it to write to file so I can read it.... On windows powershell. Version 0.98, havent used older versions.

Please run /feedback so we can look at traces on this.

To diagnose this quickly for us, ask codex to check the output against your session file (~/.codex/sessions) against the lines where it truncated to see if the model output contains the missing word.

Ask something like: What was the full sentence that has ... in it

This will help narrow this down to a server / model problem vs a harness problem. I suspect the latter, but want to rule out the former.

I'm getting the same issue and ran a quick test to repro it (vscode terminal, ssh'd into Linux 6.5.0-35-generic x86_64 x86_64). Attached are screenshots, you can see the in screenshots that lines 002 and 152 are not visible. Fwiw, I tried downgrading to 0.97 and also see multiple lines getting cut off with a similar test.

Thread id for feedback on 0.98.0: 019c3a27-02eb-72f0-a1a6-a84c836c1784
Thread id for feedback on 0.97.0: 019c3a30-63a0-7f72-8997-d007d0217bb1

<img width="998" height="750" alt="Image" src="https://github.com/user-attachments/assets/a45b7797-fe97-42e4-aa53-b34a781d8f4e" />
<img width="1016" height="750" alt="Image" src="https://github.com/user-attachments/assets/7a0c0053-3fbd-46d1-bbfc-b24bbeaac2c9" />
<img width="1007" height="754" alt="Image" src="https://github.com/user-attachments/assets/cb69f02f-6d81-4e0a-842b-4346841ca722" />
<img width="1009" height="749" alt="Image" src="https://github.com/user-attachments/assets/aed46450-2d54-4235-9059-439c116ea9e6" />

Have the same issue in v0.98.0 (Mac OS, VS code, Fish)

Related?
Windows WSL2.
Encountered in plan mode.
The terminal window was "not-maximized" and the text at the end of sentence was cut off when it was writing and reached the end of the terminal window (pic1).
I then maximized the window, exited codex and re-entered and resumed the chat. It showed the complete sentence (pic2).
Truncation happened for any line beyond the "limit"

pic1:
<img width="2096" height="129" alt="Image" src="https://github.com/user-attachments/assets/98ddcf62-b0ce-4188-91e1-cfc4a3bc1829" />

pic2:
<img width="2453" height="154" alt="Image" src="https://github.com/user-attachments/assets/2ad27139-df37-459f-a749-85f0514f7d41" />

Quickest fix for now is /resuming the chat again. It reproduces the complete output.

any fix to this yet? having the same problem and its super annoying

Encountering it too. Best way I found to "bypass" for now is to quit codex and run it again, then resume the conversation. This avoids wasting tokens compared to asking it to repeat again.

Encountering it too. Best way I found to "bypass" for now is to quit codex and run it again, then resume the conversation. This avoids wasting tokens compared to asking it to repeat again.

actually the easier way is to just hit /resume and then enter, and it refreshes the chat essentially

It's high on my priority list of things to look at and solve, but there were a couple of others things up there that took precedence - we're aware of this and are looking into it.

I dug into this and I think the root cause is a stale/uninitialized width when streaming starts.

ChatWidget stores a last_rendered_width: Cell<Option<usize>> that gets set during render() at chatwidget.rs:7177:

self.last_rendered_width.set(Some(area.width as usize));

When a new stream begins, that width is captured once and frozen into the StreamController → StreamState → MarkdownStreamCollector chain at chatwidget.rs:2293-2295:

self.stream_controller = Some(StreamController::new(
    self.last_rendered_width.get().map(|w| w.saturating_sub(2)),
));

The MarkdownStreamCollector stores this as a fixed width: Option<usize> at markdown_stream.rs:7-11 and all markdown wrapping for the entire stream uses it.

The problem: last_rendered_width is initialized to None (see chatwidget.rs:2680). If the first streaming delta arrives before the widget's first render() call completes, the width is None, so MarkdownStreamCollector gets width = None. When width is None, the markdown renderer in markdown_render.rs skips word wrapping entirely — lines render at their full unwrapped length and get clipped by the TUI area.

This explains all the observed symptoms:

• Resize fixes it because resize triggers a new render() call which sets last_rendered_width, and subsequent deltas pick up the correct width
• /resume works because it doesn't go through the streaming path — it loads pre-rendered lines
• Session files have full output because the session records raw text, not the width-dependent rendered lines
• Regression in v0.98.0 lines up with commit 01e6503 ("wrap markdown at render time") which moved wrapping from render-time (where width was always fresh) to stream-initialization-time (where it can be None)

The race is more likely on the first message in a conversation (widget hasn't rendered yet) and on slower machines or high-latency connections where the delta arrives before the first frame.

A couple of fix approaches I can think of:

1. Initialize last_rendered_width with a sensible default (e.g. query terminal size at startup via crossterm::terminal::size())
2. Make MarkdownStreamCollector lazily bind the width — instead of freezing it at construction, re-query on each commit_complete_lines() call
3. Ensure at least one render pass completes before processing the first stream delta

Option 2 would also handle the case where a user resizes mid-stream without needing a separate invalidation path.

Happy to dig further if any of this is off base.

Codex is basically unusable in VS Code... or in WSL on my machine. No upgrade, downgrade fixed it. Wtf is going on

Are any of you seeing this with the latest version (0.118.0 or newer)? We've made significant changes to the TUI in recent builds.

no i havent noticed it recently. will report back if ido

@etraut-openai Yes I am still. Suuuper annoying.
Version: v0.120.0
Client: Superset

MacBook Pro
Model Identifier: Mac16,1
Chip: Apple M4, 10-core CPU (4 performance, 6 efficiency)
Memory: 16 GB
macOS Version: macOS 15.3.1 (24D70)
Kernel: Darwin 24.3.0

@coleski, can you say more about what you're seeing? It's quite possible that it's different from the issue that was reported above.

The terminal is truncated at the end of the turn. You don't get to see the end of the model's response. The amount that it's truncated appears to vary. This sometimes, but not always, comes with a duplication of the input GUI (the grey bar, user input, model info, etc.). So you'll see a non functional GUI and then your real one at the bottom. And a bunch of blank space padding.

This error mode comes with two additional weird failures.

• If you try to /resume the same chat that's truncated, sometimes the instance crashes. Sometimes it correctly says "Already viewing."
• Both when it crashes, or if you manually kill it, it does not show the resume ID

Attaching some images of various examples...
https://imgur.com/a/tPS8gkU

If it would be helpful for me to screen share, I'm happy to hop on a call right now.

@coleski, the problem you're describing doesn't sound like a TUI display issue, which is what this issue describes. It sounds like you're experiencing a different issue where the persisted rollout is missing some information or is corrupted. That would explain the crashes you're seeing. Please open a new issue. If you're able to repro, use /feedback to upload your logs and session details and include the thread ID in the bug report. That will allow us to investigate further. Thanks!

done https://github.com/openai/codex/issues/17484