›_ Codex Issues
Codex Issues / #5576

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

Resolved 💬 20 comments Opened Oct 23, 2025 by BobbyWang0120 Closed May 9, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

0.47.0

What subscription do you have?

Pro plan

Which model were you using?

gpt-5-high

What platform is your computer?

macOS

What issue are you seeing?

When the Codex CLI is producing output and I resize the terminal window to a smaller (half) width, the new output lines wrap to fit the reduced width. However, when I resize the window back to the original/full width while Codex is still outputting, the subsequent output remains constrained to the smaller width. It does not expand to fill the full width of the terminal, so the text continues to wrap at the narrower width even though the window has been restored.

What steps can reproduce the bug?

  1. Launch the Codex CLI and start a task that prints multiple lines of output continuously.
  2. While the CLI is outputting content, resize the terminal or window to approximately half of its original width.
  3. Notice that the new output lines adjust to the smaller width as expected.
  4. Without stopping the task, resize the terminal back to its original or a wider width.
  5. Observe that the subsequent output still uses the narrower width, even though the window has been resized back to full size.

What is the expected behavior?

After resizing the window back to its original or larger width, the Codex CLI should adjust the output to the new width. New lines of output should wrap according to the current window size, so they use the full available width rather than remaining restricted to the narrower width used during the temporary resize.

Additional information

_No response_

View original on GitHub ↗

20 Comments

github-actions[bot] contributor · 9 months ago

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

  • #5259
  • #4873
  • #5457
  • #5163

Powered by Codex Action

etraut-openai contributor · 9 months ago

Thanks for posting. I think this may be a duplicate of #5259. If so, let's close this one. And feel free to upvote the existing issue.

PaulRBerg · 7 months ago

Still happening in Codex v0.75.0 in Warp terminal v0.2025.12.17.17.17.stable_02

Initial Width of Terminal

<img width="200" src="https://github.com/user-attachments/assets/b7de1bce-d533-4229-bca9-b7822ccb6634" />

Expanded Width of Terminal

Codex text has not resized according to the terminal

<img width="250" src="https://github.com/user-attachments/assets/8b8df71f-feee-4ba4-b396-ae2ee555d96d" />

mert-kurttutan · 6 months ago

Still happening in 0.77. I think this should be prioritized. It is very annoying when giving codex a chance to try out. Not a good a first impression

felixmin · 5 months ago

+1, this is extremely annoying and regularly makes me write "repeat your response"

PaulRBerg · 5 months ago

Still happening in v0.92

vprasanth · 5 months ago

This is pretty big issue for a tool built to run in the terminal

pthrasher · 5 months ago

FYI - I just submitted a PR that fixes this: #11221

esemeniuc · 4 months ago

Can we please get this fixed? its a frequent paper-cut for me

maxktz · 3 months ago

this makes codex cli unusable lately

failable · 3 months ago

Same issue

geekerzhou · 3 months ago

+1

figelwump · 3 months ago

I can reproduce this reliably in Ghostty. The issue is not limited to width changes:

  • Setup a vertical split. Run codex in one of the splits and load some content that fills scrollback.
  • Expand the pane using focus mode (in ghostty that is cmd-shift-enter) so it becomes full-height
  • The height of the rendered codex UI does not change even though the enclosing terminal has changed. Scrolling works, but if you type anything in the message bar, codex resets scroll position so message field is mid-terminal (because it's still rendering it as if it's half-height).

Some more data:

  • The PTY size is correct when Codex is this stale state.

Example from a live repro:
```bash
stty -f /dev/ttys023 size
63 206


- I monitored the TTY during focus enter/exit and the kernel winsize changed correctly when toggling focus mode:

    30 102
    63 206
    30 102
    63 206
    30 102
- In the embedding host, the terminal surface also resized correctly at the same time.
- Manually sending SIGWINCH to the affected foreground process group did not fix the stale rendering.

This makes features like focus mode (or any feature that requires changing the size of a codex terminal) frustrating to work with.
bmizerany · 2 months ago

I found a workaround. It’s annoying, but it consistently works for me:

Switch to another agent, then switch back. Codex appears to always have at least one background agent running, and changing agents seems to force a redraw. It is the only way I can get codex to redraw without exit+resume.

_Sometimes_ Ctrl-l will fix it, maybe.

I’ve seen something similar in Claude Code, which also has gnarly TUI redraw issues: opening the full transcript view and then closing it also forces a redraw. That transcript workaround does not work in Codex, but the agent-switching workaround does.

For comparison, applications like nvim, top, etc. resize perfectly in the same environment, which removes the ever-so-slight suspicion it _could_ be a Ghostty issue (which was a very low suspicion).

EDIT: I updated to 0.130.0 and the issue persists.

etraut-openai contributor · 2 months ago

The original bug described in this bug report has been fixed.

@bmizerany, if you're still seeing similar behavior, please open a new bug report and fill in all of the information request in the bug report template.

bmizerany · 2 months ago
The original bug described in this bug report has been fixed. [](https://github.com/bmizerany)

What release?

etraut-openai contributor · 2 months ago

I think it was 0.129.0. Make sure you're running the latest (0.130.0 or newer).

bmizerany · 2 months ago
EDIT: I updated to 0.130.0 and the issue persists.

https://github.com/openai/codex/issues/5576#issuecomment-4413645709

bmizerany · 2 months ago

I just tried 131 alpha 4 (still persists as it did in 129 and 130: https://github.com/user-attachments/assets/18fd498d-f627-429d-85be-740686542f05

etraut-openai contributor · 2 months ago

If you are still seeing cases where the issue persists, please create a new bug report and fill out all of the information in the bug report template including detailed repro steps.