Codex CLI still renders at stale terminal size after resize

[bmizerany]

What version of Codex CLI is running?

codex-cli 0.131.0-alpha.4

What subscription do you have?

Pro plan

Which model were you using?

Not model-specific. This is TUI resize/rendering behavior.

What platform is your computer?

Darwin 25.4.0 arm64 arm

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

Ghostty 1.3.1. No multiplexer observed. TERM=xterm-ghostty.

What issue are you seeing?

Codex continues rendering to a stale terminal size after the enclosing terminal or pane is resized. New output remains wrapped/clipped to the old dimensions even after the terminal has been restored to a larger size.

The transcript area itself also remains trapped in a smaller box than the actual window size. Once it gets into this state, it does not seem to recover on its own.

Switching to another agent and back forces a redraw. Sometimes Ctrl-L helps. Neither is a fix.

Current repro attachment:
https://github.com/user-attachments/assets/18fd498d-f627-429d-85be-740686542f05

This is the same user-visible failure discussed in #5576. Since #5576 is being treated as fixed/closed, here is the requested fresh report:
#5576 (comment)

What steps can reproduce the bug?

1. Open Codex CLI in Ghostty 1.3.1.
2. Start a session that produces enough output to make wrapping and scrollback visible.
3. Resize the Ghostty window or pane smaller while Codex is running.
4. Resize it back larger, or toggle Ghostty focus mode so the pane changes size.
5. Continue interacting with Codex.
6. Observe that Codex keeps rendering as if it is still at the old size, with the transcript/content area constrained to a smaller box inside the larger terminal.

What is the expected behavior?

Codex should repaint/reflow the TUI according to the current terminal dimensions after resize. New output, transcript content, dialogs, and the input area should use the current width and height without requiring agent switching, Ctrl-L, or exit/resume.

Additional information

Observed after updating through 0.129.0, 0.130.0, and 0.131.0-alpha.4.

Related:

• Output width remains truncated after resizing Codex CLI window back to full size #5576
• Rerender scrollback after terminal resize #5259

[github-actions]

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

• Output width remains truncated after resizing Codex CLI window back to full size #5576

Powered by Codex Action

[bmizerany]

Should burn more tokens filing a bug against Codex Action?

[truffle-dev]

github-actions tagged this as a duplicate of #5576, but #5576 was just closed and the collaborator-suggested path was a fresh report for any case still reproducible on 0.130.0+. That's this issue.

Source state at rust-v0.131.0-alpha.4, in case it helps triage:

• The terminal_resize_reflow feature is default_enabled: true (codex-rs/features/src/lib.rs:743-752), so 0.131.0-alpha.4 runs every Event::Resize through App::handle_draw_pre_render (codex-rs/tui/src/app/resize_reflow.rs:354).
• That path calls handle_draw_size_change (codex-rs/tui/src/app/resize_reflow.rs:300), which schedules a debounced 75 ms reflow on width or height change, and maybe_run_resize_reflow (codex-rs/tui/src/app/resize_reflow.rs:377) rebuilds via clear_scrollback_and_visible_screen_ansi (codex-rs/tui/src/custom_terminal.rs:531).

figelwump's earlier diagnostic on #5576 is the most useful evidence for narrowing this. PTY winsize updates correctly across Ghostty's focus-mode toggle (stty -f /dev/ttysXXX size reports the new dimensions), and a manual kill -SIGWINCH <pgrp> after the fact does not recover the stale render. So the signal isn't being missed and a retroactive resize event isn't enough to repair the screen for this terminal/transition combination. The gap is somewhere downstream of Event::Resize arrival in the resize-reflow rebuild path, not in signal delivery.

bmizerany's "switching agents fixes it" workaround on #5576 fits that picture: a side-effect that forces Terminal::invalidate_viewport (codex-rs/tui/src/custom_terminal.rs:492) recovers, while the resize-driven path apparently doesn't.

[fcoury-oai]

Should burn more tokens filing a bug against Codex Action?

Can you confirm whether Terminal resize reflow is enabled in /experimental, or whether your config.toml has [features] terminal_resize_reflow = false in any active profile?

[bmizerany]

Should burn more tokens filing a bug against Codex Action?

Can you confirm whether Terminal resize reflow is enabled in /experimental, or whether your config.toml has [features] terminal_resize_reflow = false in any active profile?

It was on. I have now tried with both on and off in 131-alpha4 and the issue persists for both configurations.

[truffle-dev]

Thanks for the toggle datapoint, that changes the analysis.

The terminal_resize_reflow feature gates two distinct paths:

1. Whether App::handle_draw_pre_render runs the reflow pipeline at all (codex-rs/tui/src/app.rs:1115-1117). With the feature off, the only pre-render resize work is refresh_status_line(). No scheduling, no transcript rebuild, no clear_scrollback_and_visible_screen_ansi call.
2. Which draw variant is used afterwards (app.rs:1156-1174). Tui::draw_with_resize_reflow calls update_inline_viewport_for_resize_reflow (tui.rs:739). Tui::draw calls update_inline_viewport (tui.rs:682) plus the cursor-position-aware pending_viewport_area heuristic (tui.rs:923-943).

My earlier trace through clear_scrollback_and_visible_screen_ansi is on the reflow rebuild path and doesn't run with the feature off, so your test rules that out. With the toggle off, the only resize-time terminal manipulation is scroll_region_up inside update_inline_viewport (tui.rs:693-704) plus whatever offset pending_viewport_area produces from a cursor-position query during the resize. Either path can leave the viewport positioned such that the next implicit invalidate_viewport doesn't repaint the missing rows.

"Switching agents recovers" still fits as a workaround because it eventually forces Terminal::invalidate_viewport (custom_terminal.rs:492) downstream of whatever state the resize handler left.

[fcoury-oai]

Thanks, that helps narrow it down. A few follow-up details would help distinguish whether this is specific to Ghostty's resize sequence or something lower-level in Codex's viewport handling:

1. Does this reproduce from an ordinary Ghostty window resize, or only from pane/focus-mode changes?
2. Right before and after the bad resize, from inside Codex, can you run !stty size and paste the output from both points?
3. Can you paste:

   printf 'TERM=%s\nTERM_PROGRAM=%s\nTERM_PROGRAM_VERSION=%s\nCOLORTERM=%s\nTMUX=%s\nSTY=%s\nZELLIJ=%s\n' \
     "$TERM" "$TERM_PROGRAM" "$TERM_PROGRAM_VERSION" "$COLORTERM" "$TMUX" "$STY" "$ZELLIJ"

4. If you have any non-default Ghostty config related to term, shell integration, splits/focus mode, scrollback, or resize behavior, please include that too.
5. A short recording showing shrink -> grow back -> one new response after the grow would also be very helpful.

Since you already confirmed Terminal resize reflow behaves the same both on and off, the most useful next signal is whether Ghostty reports the new terminal size correctly while Codex remains visually stuck at the old one.

[bmizerany]

Thanks, that helps narrow it down. A few follow-up details would help distinguish whether this is specific to Ghostty's resize sequence or something lower-level in Codex's viewport handling:

1. Does this reproduce from an ordinary Ghostty window resize, or only from pane/focus-mode changes?

Yes to the former.

2. Right before and after the bad resize, from inside Codex, can you run !stty size and paste the output from both points?

It reports "not a terminal." But there is a clue: When I size wider, then focus with the mouse, type something, the input appears about as many cols up as it grew wider... maybe? See:

3. Can you paste:> printf 'TERM=%s\nTERM_PROGRAM=%s\nTERM_PROGRAM_VERSION=%s\nCOLORTERM=%s\nTMUX=%s\nSTY=%s\nZELLIJ=%s\n' > "$TERM" "$TERM_PROGRAM" "$TERM_PROGRAM_VERSION" "$COLORTERM" "$TMUX" "$STY" "$ZELLIJ"

4. If you have any non-default Ghostty config related to term, shell integration, splits/focus mode, scrollback, or resize behavior, please include that too.

I do not.

5. A short recording showing shrink -> grow back -> one new response after the grow would also be very helpful.>

See previous reports with recordings. I see what they see.

Since you already confirmed Terminal resize reflow behaves the same both on and off, the most useful next signal is whether Ghostty reports the new terminal size correctly while Codex remains visually stuck at the old one.

[truffle-dev]

bmizerany's image shows the input row appearing roughly N columns up after the terminal grew N columns wider. That signature is specific: it matches Tui::pending_viewport_area (codex-rs/tui/src/tui.rs:923-943) on the legacy draw path (reflow=off).

The heuristic queries terminal.get_cursor_position() after a size change, computes cursor_pos.y - last_known_cursor_pos.y (lines 935-938), and applies the delta as a viewport offset. The inline comment on line 932 admits it's "a heuristic that seems to work well at least in iTerm2." iTerm2 doesn't reflow scrollback by default; Ghostty does, on width change.

When the terminal widens, Ghostty unwraps lines in scrollback above the inline area. The cursor moves up by the count of newly-unwrapped lines (roughly proportional to the width delta, depending on how many lines actually wrapped at the old width). pending_viewport_area interprets this cursor delta as "the terminal moved me" and offsets the viewport upward by that many rows. The next render lands above the actual cursor row, producing the "input N cols up as it grew wider" picture.

One discriminator that's cheap for the legacy path: when width changes but height does not, and the inline area is bottom-aligned (which it always is for the input prompt), the correct delta is zero. The terminal did not reposition the inline area; the scrollback above it shortened.

That covers reflow=off. Reflow=on uses Tui::draw_with_resize_reflow, which intentionally skips pending_viewport_area (per the doc comment at line 869-870). The symptom on that path comes from a different fault site, most likely somewhere in the transcript rebuild pipeline (clear_scrollback_and_visible_screen_ansi then maybe_run_resize_reflow). The visual signature is similar, the path is distinct.

Mouse-focus or keystroke recovery fits both paths: an invalidate_viewport triggered later re-queries the cursor at a stable moment after the reflow has settled.