codex - 💡(How to fix) Fix Codex CLI startup hangs ~60s in WSL before UI due to Windows TERM_PROGRAM probe via cmd.exe

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

ChatGPT account

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.6.114.1-microsoft-standard-WSL2 x86_64 x86_64

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

Windows Terminal running a WSL Ubuntu profile

Codex doctor report

not available

What issue are you seeing?

When launching codex interactively from WSL, the terminal stays blank for about 60 seconds before the Codex TUI draws anything.

This happens immediately after pressing Enter on codex, before normal session initialization appears in ~/.codex/log/codex-tui.log.

I narrowed it down to Codex's WSL terminal detection path. Codex appears to call:

cmd.exe /d /s /c "set TERM_PROGRAM"

On this machine, that command takes about 61 seconds when run from a WSL Linux working directory:

/usr/bin/time -f elapsed=%e timeout 75 cmd.exe /d /s /c "set TERM_PROGRAM"

Output:

'\wsl.localhost\Ubuntu-24.04\home<user>\codex' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. Environment variable TERM_PROGRAM not defined Command exited with non-zero status 1 elapsed=61.05

During the blank period, Codex has only emitted initial terminal mode output such as bracketed paste enablement. The TUI has not drawn yet.

A local workaround confirms the cause: putting a narrow cmd.exe shim first in PATH only for codex, which immediately responds to cmd.exe /d /s /c "set TERM_PROGRAM", makes Codex draw the UI within a few seconds.

What steps can reproduce the bug?

1. Use Windows Terminal with a WSL2 Ubuntu profile.

2. Install and authenticate Codex CLI.

3. Open WSL in a Linux filesystem directory, for example:

   cd ~/codex

4. Run:

   codex

5. Observe that the terminal is blank for about 60 seconds before the TUI appears.

To isolate the underlying slow probe, run:

/usr/bin/time -f elapsed=%e timeout 75 cmd.exe /d /s /c "set TERM_PROGRAM"

In this environment it takes about 61 seconds.

I also tested these nearby mitigations:

codex --no-alt-screen codex --no-alt-screen --disable terminal_resize_reflow CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex --no-alt-screen TERM_PROGRAM=Windows_Terminal codex --no-alt-screen

None of those avoided the startup blank period in this setup.

What is the expected behavior?

Codex should not block TUI startup for around a minute while probing Windows-side TERM_PROGRAM from WSL.

Possible fixes:

• Put a short timeout around the cmd.exe /d /s /c "set TERM_PROGRAM" probe.
• Skip the Windows-side probe unless it is strictly needed.
• Honor CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 before calling the WSL cmd.exe probe.
• Prefer Linux-side TERM_PROGRAM when set and avoid Windows interop when unset.

Unsupported or slow terminal detection should fall back quickly and draw the UI.

Additional information

This looks related to the WSL/Windows interop class of issues, but I did not find an exact duplicate for this startup path.

Related but not identical:

• https://github.com/openai/codex/issues/7886
• https://github.com/openai/codex/issues/17531

The relevant source path appears to be:

codex-rs/tui/src/tui/keyboard_modes.rs

Specifically, read_windows_term_program() calls:

  std::process::Command::new("cmd.exe")
      .args(["/d", "/s", "/c", "set TERM_PROGRAM"])