Repeated Text Fragment When Scrolling in Codex CLI

Resolved 💬 7 comments Opened Jul 8, 2025 by tao12345666333 Closed Oct 16, 2025
💡 Likely answer: A maintainer (bolinfest, collaborator) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.2.0

Which model were you using?

o3

What platform is your computer?

Linux 6.14.5-100.fc40.x86_64 x86_64 unknown

What steps can reproduce the bug?

While using the OpenAI Codex CLI tool, I noticed that certain text fragments (such as "found in issue body") appear repeatedly and incorrectly on the screen during scroll events. This duplication seems to occur even when the content itself hasn't changed, creating a visually noisy and confusing interface.

  • Open codex
  • send and receive a lot of content (I just asked the codex to review my whole repo's code )
  • Scroll through the output using your terminal emulator (tested on Warp and Sakura Terminal).

What is the expected behavior?

Text should not be duplicated or visually repeated unless it actually exists multiple times

What do you see instead?

<img width="1739" height="953" alt="Image" src="https://github.com/user-attachments/assets/ff19400e-9b4c-431e-98bc-f95d0b7fb411" />

Additional information

_No response_

View original on GitHub ↗

7 Comments

bolinfest collaborator · 1 year ago

I need a good repro for this, but offhand, my best guess is that I'm not calling ansi_escape() somewhere:

https://github.com/openai/codex/blob/0b9cb2b9e767cba706c30381d9890a139b7d54d9/codex-rs/ansi-escape/src/lib.rs

At least, I have seen a similar issue in the past where that was the fix.

velaris1 · 1 year ago

I can repro it on Windows 10 (WSL) using Windows Terminal. I'm on Codex CLI 0.3 (latest as of the time of this writing).

Using the Unreal Engine codebase:

  • First prompt: "Only reference source code available in the working directory. Always provide source code reference when replying".
  • Second prompt: "Describe how TWeakObjectPtr works."

<img width="2038" height="1043" alt="Image" src="https://github.com/user-attachments/assets/d78a51ab-8490-4604-b581-006329824217" />

m4dc4p · 11 months ago

I'm using Windows Terminal / WSL2 / Ubuntu 22.04. When I run codex (0.20, rust binary), I don't get any scrollback . That is, once text scrolls off the top of the screen its gone. Scrolling up shows my last command prompt.

My terminal settings are such that I should be able to scroll 100,000 lines of history. Doesn't happen with man command, ls, etc. so it seems related to the codex binary.

This screen capture shows the problem. I scroll back up about 2 seconds in (you can see my prompt "m4dc4p@BEAST:~/Justin/Source/codex". Notice the scrolling text disappears under the prompt, and can't be recovered.

https://github.com/user-attachments/assets/6d2517bb-d86d-47d8-ba1b-4dcdfacc5cef

Strangely, running in the VS Code terminal does not show the same problem:

https://github.com/user-attachments/assets/cf5981b2-5974-463e-add1-24b4f3a33408

In both cases, TERM is set to xterm-256color.

yudhiesh-oc · 10 months ago

Noticing a similar issue where TERM=xterm-kitty on codex-cli 0.31.0, I never have this issue with Claude Code.

<img width="1695" height="1374" alt="Image" src="https://github.com/user-attachments/assets/c4442ca0-8884-4b4d-87c6-4b963282e5f1" />

tibo-openai collaborator · 9 months ago

Should be fixed in recent versions, marking as closed

pthrasher · 5 months ago

This may have been solved already, but my changes definitely add a bit of hardening / robustness around this specific bug... Also some regression tests. See: #11221

gennaro-tedesco · 3 months ago

Apologies to comment on a closed issue: has this been confirmed to work? Independent of the terminal I use (wezterm, iTerm, ghostty), text fragment artifacts and inability to scroll are still present. There are quite a few other reference issues still open, hence I wonder if/why this classifies as solved.

Is it possible to point me (if it exists) to a general codex cli scrolling docs/intended behaviour? This seems to be a long-running issue with the cli since the beginning.