Latest npm Codex CLI renders raw ANSI/control sequences in Windows Terminal
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
- On Windows, open Windows Terminal.
- Install the latest npm Codex CLI:
npm install -g @openai/codex@latest
- Run Codex:
codex
- Observe that the TUI renders raw ANSI/control sequences as text.
- Try again in PowerShell 7:
pwsh
codex
- The same rendering issue occurs.
- Downgrade to
0.130.0:
npm install -g @openai/codex@0.130.0
codex
- 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_
9 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
looks like same but evolved to a similar cli-issue
https://github.com/openai/codex/issues/6178
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" />
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.
Same thing here, what a pain
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.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
[?2026hor]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:
Fixed by https://github.com/openai/codex/pull/24082