›_ Codex Issues
Codex Issues / #12542

Regression: Codex CLI TUI no longer handles input on Windows Terminal (raw ANSI sequences shown)

Resolved 💬 10 comments Opened Feb 23, 2026 by joce Closed Feb 24, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.104.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.3-codex (xhigh)

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

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

Windows Terminal (cmd)

What issue are you seeing?

I enter codex. Most (if not all) of the printable keys appear to work fine, but no Enter. Pressing Ctrl-anything doesn't work (e.g. Ctrl-C). Backspace moves the cursor forward. Pressing the arrow keys gives e.g. [A[C[D[B[A[D[B.

What steps can reproduce the bug?

Just start Codex, and I get into this state, making codex CLI 100% unusable.

What is the expected behavior?

Codex is usable! ;-)

hepl.

Additional information

Codex used to work just fine. I don't know if I hit any key combination or anything, but now it no longer does.

  • I've restarted the terminal. Didn't help.
  • I've rebooted. Didn't help.
  • I've tried to "delete" (rename, actually) the ~/.codex dir. After that, I could get in and interact until I was asked to setup a sandbox. The app stopped working (no up/down/enter keys worked) then.
  • Looking at another issue with similar symptoms, I tried to run with --disable shell_snapshot. That made no difference.
  • I've tried to downgrade to 0.103. Didn't help.
  • I've tried to run in a Powershell rather than cmd, still not working.

Here's the content of a fresh codex-tui.log when I open Codex CLI (I tried to just attach the file, but GH won't let me):

2026-02-23T04:47:05.368872Z  INFO codex_core::models_manager::manager: models cache: evaluating cache eligibility client_version="0.104.0"
2026-02-23T04:47:05.368897Z  INFO codex_core::models_manager::cache: models cache: attempting load_fresh cache_path=C:\Users\jocel\.codex\models_cache.json expected_version="0.104.0"
2026-02-23T04:47:05.369520Z  INFO codex_core::models_manager::cache: models cache: loaded cache file cache_path=C:\Users\jocel\.codex\models_cache.json cached_version=Some("0.104.0") fetched_at=2026-02-23 04:41:53.982589200 UTC
2026-02-23T04:47:05.369537Z  INFO codex_core::models_manager::cache: models cache: cache is stale cache_path=C:\Users\jocel\.codex\models_cache.json cache_ttl_secs=300 fetched_at=2026-02-23 04:41:53.982589200 UTC
2026-02-23T04:47:05.369575Z  INFO codex_core::models_manager::manager: models cache: no usable cache entry
2026-02-23T04:47:05.369856Z  INFO codex_core::models_manager::manager: models cache: evaluating cache eligibility client_version="0.104.0"
2026-02-23T04:47:05.369860Z  INFO codex_core::models_manager::cache: models cache: attempting load_fresh cache_path=C:\Users\jocel\.codex\models_cache.json expected_version="0.104.0"
2026-02-23T04:47:05.370194Z  INFO codex_core::models_manager::cache: models cache: loaded cache file cache_path=C:\Users\jocel\.codex\models_cache.json cached_version=Some("0.104.0") fetched_at=2026-02-23 04:41:53.982589200 UTC
2026-02-23T04:47:05.370201Z  INFO codex_core::models_manager::cache: models cache: cache is stale cache_path=C:\Users\jocel\.codex\models_cache.json cache_ttl_secs=300 fetched_at=2026-02-23 04:41:53.982589200 UTC
2026-02-23T04:47:05.370229Z  INFO codex_core::models_manager::manager: models cache: no usable cache entry
2026-02-23T04:47:05.373168Z  INFO codex_core::models_manager::manager: models cache: evaluating cache eligibility client_version="0.104.0"
2026-02-23T04:47:05.373171Z  INFO codex_core::models_manager::cache: models cache: attempting load_fresh cache_path=C:\Users\jocel\.codex\models_cache.json expected_version="0.104.0"
2026-02-23T04:47:05.373469Z  INFO codex_core::models_manager::cache: models cache: loaded cache file cache_path=C:\Users\jocel\.codex\models_cache.json cached_version=Some("0.104.0") fetched_at=2026-02-23 04:41:53.982589200 UTC
2026-02-23T04:47:05.373473Z  INFO codex_core::models_manager::cache: models cache: cache is stale cache_path=C:\Users\jocel\.codex\models_cache.json cache_ttl_secs=300 fetched_at=2026-02-23 04:41:53.982589200 UTC
2026-02-23T04:47:05.373492Z  INFO codex_core::models_manager::manager: models cache: no usable cache entry
2026-02-23T04:47:05.373497Z  INFO codex_core::models_manager::manager: models cache: cache miss, fetching remote models
2026-02-23T04:47:06.161207Z  INFO session_init: codex_core::codex: new
2026-02-23T04:47:06.164717Z  INFO session_init:shell_snapshot{thread_id=019c88d2-8db1-7741-b3e5-4382496e8b16}: codex_core::shell_snapshot: new
2026-02-23T04:47:06.165300Z  INFO session_loop{thread_id=019c88d2-8db1-7741-b3e5-4382496e8b16}: codex_core::codex: new
2026-02-23T04:47:06.165007Z  WARN session_init:shell_snapshot{thread_id=019c88d2-8db1-7741-b3e5-4382496e8b16}: codex_core::shell_snapshot: Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell

Stack backtrace:
   0: <unknown>
   1: tree_sitter_bash
   2: tree_sitter_bash
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: BaseThreadInitThunk
  13: RtlUserThreadStart
2026-02-23T04:47:06.173420Z  INFO session_init:shell_snapshot{thread_id=019c88d2-8db1-7741-b3e5-4382496e8b16}: codex_core::shell_snapshot: close time.busy=8.50ms time.idle=203µs
2026-02-23T04:47:06.173432Z  INFO session_init: codex_core::codex: close time.busy=3.91ms time.idle=8.32ms

View original on GitHub ↗

10 Comments

etraut-openai contributor · 4 months ago

Thanks for the bug report. We haven't heard this from any other users, so I wonder if it's specific to your system, terminal emulator, or configuration.

Let's first confirm that it's a regression in the CLI rather than something local to your system. Please try downgrading to 0.103.0 and see if the problem goes away.

joce · 4 months ago

As I mentioned in the bug report, I've already tried 0.103, to no avail. I've just retried, and got the same.
I kind of strongly suspect this is an error strictly on my side, but I can't identify what. Other CLIs (e.g. Claude) work flawlessly, so it's not an issue with the terminal per se.
FWIW, I can run without issue in the VSCode plugin. But it's not the same. :-(

etraut-openai contributor · 4 months ago
As I mentioned in the bug report, I've already tried 0.103

Oh sorry, I missed that in your original bug report. Are you pretty sure that it previously worked on 0.103.0? Maybe it was an earlier version where a regression was introduced?

The fact that you're seeing the same thing in cmd and PowerShell is interesting.

What keyboard layout are you using? For example, is it a French layout? If so, does changing it to English fix it?

joce · 4 months ago

I get the same issue with US English (that I normally use with Codex) or Canadian Multilingual Standard, that I also have installed.

I'm not only pretty sure it used to work on 0.103, I'm convinced it did. And 0.104 too. It started acting weird in the middle of a coding session (using 0.104) just hours ago! I have been using it all day, on and off and did not close or log off. After an interaction, it just started acting weird.

FWIW, when I opened that session in VSCode, the first thing it did upon startup was it started by compacting it. Not sure it has any bearing on anything, especially since I got the same issue even with a brand new ~/.codex dir (as I mentioned, I had renamed it, and started Codex again. Same issue). But I figure it's more info you might want to know.

joce · 4 months ago

Maybe something in the sandbox... ?

etraut-openai contributor · 4 months ago

It sounds like this might be specific to your system. Without a solid repro, there's little that we can do.

Here's an idea. You could clone the codex repo, build it from source, then ask codex to debug the issue for you. It will add logs, etc. and help you pinpoint the cause.

joce · 4 months ago

Great idea. Thanks Eric! Much appreciated.

joce · 4 months ago

OK. Issue found and dealt with. Reporting just in case anybody else runs into this.

Turns out that I had in my PATH, before the path for the git I have installed on Windows, C:\Tools\wslgit\cmd, a shim that pointed to the WSL2 git install I have, and it was that version that was picked up by default. _Somehow_ it used to work in the past. Yesterday, among the 1000 things I did, I ran sudo apt update && sudo apt upgrade and git was upgraded to 2.43 on the WSL2 side (I'm on 2.53 on the Windows side), and in doing so, now any folder that had a git repo was non functional with Codex.

I do not know exactly WHAT was borking Codex with this setup, but something was (I did not pursue the investigation forward). Just removing the C:\Tools\wslgit\cmd path from my PATH fixed the thing. FWIW, I was helped tremendously into narrowing it down with the help of Codex (on the IDE side, which did not suffer from the same issues).

cheers!

etraut-openai contributor · 4 months ago

Good finding! Thanks for sharing the diagnosis.

jshtk · 1 month ago

@
Still reproducing on Codex v0.136.0 on Windows 11, despite the v0.134.0 fix(tui): restore Windows VT before TUI renders (#24082).

Environment

  • OS: Windows 11 Pro, build 26100
  • Codex: v0.136.0 (npm install)
  • Terminals tested (all reproduce): Windows Terminal (latest), PowerShell 7, cmd.exe
  • Also fails with codex --no-alt-screen
  • CWD during repro: C:\Users\js (not a git repo — rules out #23691 as the same root cause)

Symptom

After an indeterminate runtime (works fine initially, breaks after several minutes / a number of Alt-Tab cycles), the TUI composer stops handling input correctly. Keystrokes that should be control sequences are rendered as their un-prefixed CSI tail in the composer — i.e., the leading ESC (0x1B) is being consumed but the parser falls off its state machine and re-emits the remainder as literal text:

| Visible in composer | Actual sequence | Source |
|---|---|---|
| [A [B [C [D | ESC[A/B/C/D | Arrow keys (DECCKM) |
| [I / [O | ESC[I / ESC[O | Focus In/Out reporting (CSI ?1004h) |
| [200~ … [201~ | ESC[200~ … ESC[201~ | Bracketed paste (CSI ?2004h) |
| [3~ | ESC[3~ | Delete key |

Enter no longer submits in this state. Composer contents captured during a hang:

[O[I[O[I[O[I sdfvklns[3~[3~[D[D[D[D[D[B[A[O[I[O[I[O[I[200~codex --no-alt-screen[201~dsrflkgjndslgklk[3~[3~[C[A[B[D[C[A[D[O[I[O[I

The density of [O[I pairs is notable: those appear specifically on Alt-Tab focus changes. This strongly suggests focus reporting (CSI ?1004) is at least an amplifier of the bug — every window focus change feeds another unparsed sequence into the broken input reader, and the failure tends to manifest after a session has accumulated focus changes.

What this implies for diagnosis

  • ESC is being consumed but the CSI body is not — the input parser enters the escape state, then exits it incorrectly and writes the body to the composer buffer. Looks like a state-machine bug, not a "VT mode never got set" bug.
  • --no-alt-screen does not help → not specific to the alt-screen swap.
  • Identical behavior across PowerShell, cmd, and Windows Terminal directly → rules out the host shell / ConPTY config as the trigger.
  • v0.134.0s VT-restore fix only covers initial render path; this happens mid-session.
  • Once broken, the session is unrecoverable from inside the TUI — restarting loses session state, which is the main usability cost here.

Happy to provide

  • Verbose / trace log on next repro if theres a flag or env var you want enabled (e.g. RUST_LOG, CODEX_LOG, anything that dumps the input parser state). Please point me at the right knob.
  • A wt.exe keybinding-replay or Windows Terminal session log if useful.

@