Windows native TUI inserts [C/[D/[3~ when VT input is re-enabled

What version of Codex CLI is running?

codex-cli 0.140.0-alpha.19 from the Windows npm package.

I also reproduced this on a native Windows source build from openai/codex@dfd03ea01b before applying a local diagnostic patch.

This appears to be a recent regression in the native Windows path: the same Windows environment was usable with the previous stable npm version before updating.

What subscription do you have?

Not included here. The issue reproduces in local TUI input handling before any model/API request is needed.

Which model were you using?

Not model-specific.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

Additional context from codex doctor --json: Windows 11 Professional, x64.

WSL2 Fedora in the same Windows Terminal does not reproduce the issue.

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

Primary repro: Windows Terminal 1.24.11321.0 with PowerShell 7.6.2 (pwsh).

Also reproduced on native Windows in Git Bash and VS Code integrated terminal. No tmux/screen/zellij.

Codex doctor report

Redacted to the parts relevant to this TUI input issue:

{
  "schemaVersion": 1,
  "overallStatus": "ok",
  "codexVersion": "0.140.0-alpha.19",
  "checks": {
    "installation": {
      "status": "ok",
      "summary": "installation looks consistent",
      "details": {
        "install context": "npm on windows-x86_64"
      }
    },
    "runtime.provenance": {
      "status": "ok",
      "summary": "running npm on windows-x86_64",
      "details": {
        "platform": "windows-x86_64",
        "version": "0.140.0-alpha.19"
      }
    },
    "system.environment": {
      "status": "ok",
      "summary": "Windows 11 Professional [64-bit]",
      "details": {
        "os": "Windows 10.0.26200 (Windows 11 Professional) [64-bit]",
        "os type": "Windows",
        "os version": "10.0.26200"
      }
    },
    "terminal.env": {
      "status": "ok",
      "summary": "terminal metadata was detected",
      "details": {
        "terminal": "Windows Terminal",
        "terminal size": "120x50"
      }
    }
  }
}

What issue are you seeing?

I am filing this as a native Windows TUI input regression report, with a locally validated mitigation included below for context.

On native Windows terminals, the Codex TUI can intermittently insert terminal escape-sequence tails into the composer when navigation/editing keys are pressed. For example, pressing Right/Left/Down/Delete can leave literal text like [C, [D, [B, and [3~ in the input area.

This materially degrades usability of the native Windows TUI. The same workflow in WSL2 inside Windows Terminal does not show the issue.

What steps can reproduce the bug?

1. Start native Windows codex in Windows Terminal + PowerShell.
2. Focus the composer.
3. Press arrow keys and Delete.
4. Watch the composer text.

I could also reproduce this with constructed PTY input in both WinPTY and ConPTY paths by sending focus + navigation/delete sequences equivalent to:

ESC[O ESC[I ESC[C ESC[C ESC[C ESC[D ESC[D ESC[B ESC[3~ XYZ

On the affected build, the visible composer text contains escape tails such as [C, [D, [B, and [3~.

What is the expected behavior?

Arrow keys and Delete should be handled as key events/navigation/editing operations. Their escape-sequence bytes should not be inserted as text in the composer.

Additional information

I instrumented a local native Windows build to narrow this down. The evidence points to ENABLE_VIRTUAL_TERMINAL_INPUT being enabled on the console input handle while crossterm's Windows event stream is reading.

A representative failing state was:

input_mode=0x00000398, ENABLE_VIRTUAL_TERMINAL_INPUT=true
raw crossterm events: KeyEvent { code: Char('[') }, KeyEvent { code: Char('C') }, ...

After clearing ENABLE_VIRTUAL_TERMINAL_INPUT, the mode becomes 0x00000198 and the same navigation/delete input no longer leaks [C/[D/[B/[3~ into the composer.

The notable detail is that clearing this bit only during initial setup was not sufficient in this environment. Logging showed startup and event-stream creation with VT input disabled, followed by a later Poll::Pending path where the input mode had returned to 0x398.

A locally validated mitigation does the following:

• Does not emit crossterm focus-change enable/disable commands on Windows.
• Defaults keyboard enhancement mode off on native Windows, while keeping the existing env override.
• Explicitly clears ENABLE_VIRTUAL_TERMINAL_INPUT after raw mode setup, after Windows color probing/palette probing, after crossterm EventStream::new(), and again when the event stream returns Poll::Pending before waiting for more stdin.

Validation of that local patch:

• Windows-side cargo fmt --check: passed (only the existing rustfmt nightly-option warning).
• cargo test -p codex-tui tui::keyboard_modes --lib: passed, 11 tests.
• cargo check -p codex-tui: passed.
• cargo build -p codex-cli --bin codex: passed.
• WinPTY/ConPTY constructed-input probes no longer leave [C/[D/[B/[3~ visible in the composer.

I would be happy to open a PR with this Windows-gated patch if maintainers consider this direction appropriate. I am also happy to adjust the shape of the change if the preferred boundary is closer to the crossterm event-source layer.