Windows native TUI intermittently inserts escape-sequence tails ([I/[C/[D/[A]) and becomes unusable

What version of Codex CLI is running?

codex-cli 0.139.0

Installed via npm on native Windows.

I have not upgraded to 0.141.0 because the 0.141.0 release notes and the related open issues do not appear to mention a fix for this Windows TUI input / VT sequence leakage problem. I can test a newer version if maintainers think a relevant fix has landed.

What platform is your computer?

Native Windows 11, x64.

codex doctor --json reports:

{
  "codexVersion": "0.139.0",
  "overallStatus": "warning",
  "system.environment": {
    "os": "Windows 10.0.26200 (Windows 11 CoreCountrySpecific) [64-bit]",
    "os type": "Windows",
    "os version": "10.0.26200",
    "os language": "zh-CN"
  },
  "terminal.env": {
    "terminal": "Windows Terminal",
    "WT_SESSION": "present",
    "console input code page": "65001",
    "console output code page": "65001"
  },
  "installation": {
    "install context": "npm on windows-x86_64",
    "managed by npm": "true"
  }
}

What terminal emulator and shell are you using?

• Windows Terminal
• PowerShell 7.6.2 (pwsh)
• Native Windows codex process, not WSL

What issue are you seeing?

After using an interactive Codex CLI session for a while, the TUI input composer can enter a broken state where terminal control/key sequences are inserted as literal text and normal editing/control keys stop working.

Observed symptoms include:

• Arrow keys are inserted as visible text such as [A, [B, [C, [D.
• Focus transitions can insert [I / [O-style text.
• Delete may insert [3~-style text.
• Backspace behaves incorrectly; in one failure mode it appears to insert/move like spaces rather than deleting normally.
• Ctrl-C and other control key handling can stop working.
• Once this happens, the session becomes effectively unusable and the only reliable recovery is closing the terminal window and resuming from a new one.

This appears related to the same class of Windows TUI input / VT sequence leakage issues discussed in:

• #24929
• #28301
• #12542

However, the #12542 final root cause does not seem to match my environment: my PATH uses a native Windows Git (MinGit 2.54.0) and does not have a wslgit shim before Git.

Steps to reproduce

I do not yet have a deterministic minimal reproducer, but the issue happens during normal long-running interactive CLI use on native Windows:

1. Open Windows Terminal.
2. Start PowerShell 7.
3. Run codex.
4. Use the session normally for a while.
5. Switch focus between Windows Terminal and other windows and/or continue editing in the composer.
6. Eventually the composer may start inserting literal control-sequence tails such as [I, [C, [D, [A, [3~, and control keys stop working correctly.

Expected behavior

The TUI should continue parsing focus events, arrow keys, Delete, Backspace, Enter, and Ctrl-C as terminal/input events. Escape-sequence tails should not be inserted into the composer as literal text.

Actual behavior

The composer starts receiving and inserting escape-sequence tails as ordinary text, and the TUI input state becomes unusable.

Workarounds tried

I set the environment variable both in the current process and user environment:

[Environment]::SetEnvironmentVariable(
  'CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT',
  '1',
  'User'
)

The current shell also reports:

$env:CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT
# 1

This seems to reduce or change the failure surface but does not fully solve the problem.

Additional local checks

• codex doctor --json reports installation is consistent.
• The terminal is detected as Windows Terminal.
• The active Git in PATH is native Windows Git:

C:\Users\<USER>\Tools\MinGit-2.54.0\cmd\git.exe

No wslgit shim appears before Git in PATH.

Notes

Given #24929 and #28301 are still open and 0.141.0 release notes do not mention a Windows TUI input / focus reporting / VT input fix, I am filing this as an additional native Windows data point from 0.139.0 rather than upgrading first.