Latest npm Codex CLI renders raw ANSI/control sequences in Windows Terminal

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

What version of Codex CLI is running?

Broken version: ``@openai/codex@0.131.0 ` and `@openai/codex@0.132.0` Known working version: `txt @openai/codex@0.130.0 ``

What subscription do you have?

Pro

Which model were you using?

5.5 but any

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

PowerShell 5 and 7

Codex doctor report

not available

What issue are you seeing?

<img width="603" height="195" alt="Image" src="https://github.com/user-attachments/assets/cbfca6cf-8651-4af3-9b1b-60a6f1dfdd79" />

The latest npm-installed Codex CLI renders terminal control sequences as visible text inside Windows Terminal. The UI becomes filled with raw ANSI/control codes instead of formatted text.

Examples visible in the terminal include sequences like:

[25;3H
[1m
[22m
[39m
[49m
[?2026h
[?2026l

The visible output repeats across the screen and makes the TUI unusable. It looks like Codex is emitting a terminal renderer/control stream that is not being interpreted by Windows Terminal/ConPTY in this environment.

This happens in both Windows PowerShell 5.1 and PowerShell 7 (pwsh). Downgrading to @openai/codex@0.130.0 fixes the rendering, so this appears to be a regression after 0.130.0, not a shell-specific issue.

What steps can reproduce the bug?

at least on my pc :D

  1. On Windows, open Windows Terminal.
  2. Install the latest npm Codex CLI:
npm install -g @openai/codex@latest
  1. Run Codex:
codex
  1. Observe that the TUI renders raw ANSI/control sequences as text.
  2. Try again in PowerShell 7:
pwsh
codex
  1. The same rendering issue occurs.
  2. Downgrade to 0.130.0:
npm install -g @openai/codex@0.130.0
codex
  1. Rendering returns to normal.

What is the expected behavior?

Codex should render its TUI normally in Windows Terminal, without printing raw ANSI/control sequences as visible text.

The same terminal setup works correctly with:

@openai/codex@0.130.0

Additional information

_No response_

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 2 months ago

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

  • #23701
  • #23031
  • #23512
  • #23691

Powered by Codex Action

nos1609 · 2 months ago

looks like same but evolved to a similar cli-issue
https://github.com/openai/codex/issues/6178

nikkelly · 1 month ago

Saw this in 0.132.0 and now in 0.133.0

Interestingly starting codex in a net-new repo seems to work fine, just the existing repo renders raw

<img width="1919" height="373" alt="Image" src="https://github.com/user-attachments/assets/e606b05d-387f-4fcb-ac4a-874684fe328e" />

Simplereally · 1 month ago

same regression here. win11, powershell 7.6.2, windows terminal. 0.133.0 prints raw ansi sequences on startup ([?2026h, [39;49m, osc title strings, etc). downgrading to 0.130.0 fixes it completely. this is 100% reproducible in any git repo on my machine. not a shell config issue - happens on a clean pwsh profile too.

benjaminlefevre · 1 month ago

Same thing here, what a pain

fcoury-oai contributor · 1 month ago

Unfortunately this is a bug with older versions of git that manifest when we added support for fsmonitor=false. You can either upgrade your git version to the latest or wait for the next release.

Clonkex · 1 month ago

Why on earth does the installed version of git have anything to do with how codex renders characters in the terminal??

fcoury-oai contributor · 1 month ago
Why on earth does the installed version of git have anything to do with how codex renders characters in the terminal??

Fair question, and my previous explanation was indeed too compressed.

Codex invokes Git inside a repository to collect repository metadata and working-tree status. In #22652 / commit 6ec8c4a6, we began invoking those internal Git commands with -c core.fsmonitor=false, so Codex would not run a repository's configured filesystem monitor while collecting metadata.

On affected older versions of Git for Windows, that invocation can leave the Windows console with virtual terminal (VT) processing disabled after Git exits. Console output mode is shared state, so a subprocess can affect what the parent application sees afterward.

Codex then renders its terminal UI by writing ANSI/VT control sequences, including redraw controls and terminal-title updates. If VT processing has been disabled, Windows displays those bytes literally instead of interpreting them, which is why users see sequences such as [?2026h or ]0;....

So Git is not responsible for rendering Codex's UI. A Git subprocess was inadvertently changing terminal state that Codex relies on, and the issue appeared in Git repositories because that is where Codex performs the affected metadata reads.

Updating Git for Windows avoids the trigger. We have also merged #24082 / commit acd851e89f, which makes Codex re-enable Windows VT processing before it renders, so Codex is resilient even if a subprocess changes that mode.

That fix is already available in the 0.134.0-alpha.3 pre-release and will be included in the next stable release.

In the meantime, updating Git for Windows is the immediate workaround for stable Codex releases affected by this issue.

Sorry for the confusing shorthand in my earlier reply and hope this helps understanding why on Earth they're related :blush:

fcoury-oai contributor · 1 month ago