Codex CLI still renders at stale terminal size after resize

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

• #5576

Powered by Codex Action

Should burn more tokens filing a bug against Codex Action?

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.

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?

> 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.

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.

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:

``sh
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"
``

1. If you have any non-default Ghostty config related to term, shell integration, splits/focus mode, scrollback, or resize behavior, please include that too.
2. 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.

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:

<img width="2452" height="936" alt="Image" src="https://github.com/user-attachments/assets/b7f8bd18-9a4c-470e-aaa5-d8d16799de61" />

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"

<img width="1788" height="448" alt="Image" src="https://github.com/user-attachments/assets/d51f56d3-45c3-4a1d-b4d4-bb0b06841166" />

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.

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.

I have the same issue. Latest version of Codex. More than "I have the same issue" I should just say "the issue never went away" since this has been happening since I first started using Codex many months ago and has never been fixed.

@masinov can you run codex doctor --all and send me the response so we can investigate it further?

codex doctor --all

Codex Doctor v0.131.0 · linux-x86_64

Environment
✓ runtime npm
version 0.131.0
install method npm
commit unknown
executable /usr/lib/node_modules/@o…-linux-musl/codex/codex
✓ install consistent
context npm
managed by npm: yes · bun: no · package root /usr/lib/node_modules/@openai/codex
PATH entries (2) /usr/bin/codex
/bin/codex
npm update target /usr/lib/node_modules/@openai/codex
✓ search ripgrep 15.1.0 (rev af60c2de9d) (system, rg)
search command rg
search provider system
search command readiness ripgrep 15.1.0 (rev af60c2de9d)
✓ terminal VS Code 1.112.0
terminal VS Code
TERM_PROGRAM vscode
terminal version 1.112.0
stdin is terminal true
stdout is terminal true
stderr is terminal true
terminal size 196x48
color output enabled
COLORTERM truecolor
effective locale en_US.UTF-8
SSH_CONNECTION present
SSH_CLIENT present
VSCODE_IPC_HOOK_CLI present
✓ state databases healthy
CODEX_HOME ~/.codex (dir)
log dir ~/.codex/log (dir)
sqlite home ~/.codex (dir)
state DB ~/.codex/state_5.sqlite (file) · integrity ok
log DB ~/.codex/logs_2.sqlite (file) · integrity ok
active rollouts 147 files · 371.63 MB (avg 2.53 MB)
archived rollouts 0 files · 0 B (avg 0 B)

Configuration
✓ config loaded
model gpt-5.4 · openai
cwd ~/projects/******
config.toml ~/.codex/config.toml
config.toml parse ok
MCP servers 0
feature flags 28 enabled · 0 overridden
enabled flags shell_tool, unified_exec, shell_snapshot, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search, tool_suggest, plugins, plugin_hooks, in_app_browser, browser_use, browser_use_external, computer_use, plugin_sharing, image_generation, skill_mcp_dependency_install, steer, guardian_approval, collaboration_modes, tool_call_mcp_elicitation, personality, fast_mode, tui_app_server, workspace_dependencies
✓ auth auth is configured
auth storage mode File
auth file ~/.codex/auth.json
stored auth mode chatgpt
stored API key false
stored ChatGPT tokens true
stored agent identity false
✓ mcp no MCP servers configured
✓ sandbox restricted fs + restricted network · approval OnRequest
approval policy OnRequest
filesystem sandbox restricted
network sandbox restricted
linux helper ~/.codex/tmp/arg0/codex-…fbp/codex-linux-sandbox
execve wrapper helper ~/.codex/tmp/arg0/codex-…bp/codex-execve-wrapper

Updates
✓ updates update configuration is locally consistent
startup update check true
update action npm install -g @openai/codex
version cache ~/.codex/version.json
cached latest version 0.130.0
last checked at 2026-05-18 13:05 UTC
dismissed version 0.116.0
npm update target /usr/lib/node_modules/@openai/codex
latest version 0.131.0
latest version status current version is not older

Connectivity
✓ network no proxy env vars
proxy env vars none
✓ websocket connected (HTTP 101 Switching Protocols) · 15s timeout
model provider openai
provider name OpenAI
wire API responses
supports websockets true
proxy env vars none
connect timeout 15000 ms
auth mode chatgpt
endpoint wss://chatgpt.com/backend-api/<redacted>
DNS 2 IPv4, 2 IPv6, first IPv4
handshake result HTTP 101 Switching Protocols
reasoning header false
models etag present true
server model present false
✓ reachability active provider endpoints are reachable over HTTP
reachability mode ChatGPT auth
ChatGPT base URL https://chatgpt.com/backend-api/ reachable (HTTP 404)

Background Server
○ app-server not running (ephemeral mode)
daemon state dir ~/.codex/app-server-daemon
settings ~/.codex/app-server-daemon/settings.json (missing)
pid file ~/.codex/app-server-daemon/app-server.pid (missing)
update-loop pid file ~/.codex/app-server-daem…/app-server-updater.pid (missing)
control socket ~/.codex/app-server-cont…app-server-control.sock
status not running
mode ephemeral

─────────────────────────────────────────────────────────────
13 ok · 1 idle · 0 warn · 0 fail ok