WSL CLI startup from `/home/...` stalls ~60s in `cmd.exe` `set TERM_PROGRAM` probe

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

ChatGPT Plus via ChatGPT sign-in auth (auth_mode: chatgpt).

This startup stall happens before the first model request or tool call, so the plan tier does not appear to affect reproduction.

Which model were you using?

When I normally use Codex in this environment, I use gpt-5.4 with high reasoning effort.

For this specific bug, the stall occurs during interactive CLI startup before the first prompt/model request, so the model choice does not appear to affect reproduction.

What platform is your computer?

Ubuntu 22.04.2 LTS on WSL2:

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

Windows host:

Microsoft Windows NT 10.0.19045.0 x64
cmd.exe ver: Microsoft Windows [Version 10.0.19045.6456]

WSL component versions:

WSL 2.6.3.0
kernel 6.6.87.2-1
WSLg 1.0.71

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

Primary repro is in an interactive WSL shell with:

zsh 5.8.1 (x86_64-ubuntu-linux-gnu)

I also reproduced the same behavior under script(1) pseudo-TTY capture for strace, which suggests this is not specific to one terminal frontend.

What issue are you seeing?

Starting interactive Codex CLI from a WSL Linux cwd such as /home/... stalls for about 60 seconds before the UI becomes usable.

strace consistently shows Codex spawning:

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

during startup. When the launcher cwd is a WSL Linux path, that probe is followed by an approximately 60 second wait, and only after that do I see output referencing a \\wsl.localhost\\Ubuntu-22.04\\home\\... path and TERM_PROGRAM.

Control test:

• Launching the same unmodified Codex build from a Windows-backed cwd such as /mnt/c/Windows/System32
• while still targeting the same Linux repo via -C /home/...

does not show the equivalent 60 second stall.

Additional observation:

• Pre-setting TERM_PROGRAM=foo does not prevent the cmd.exe probe.
• Codex still executes cmd.exe /d /s /c "set TERM_PROGRAM" and still stalls when launched from /home/....

Based on the traces, the practical trigger appears to be the cwd from which Codex is launched in WSL, not the workspace path eventually used by -C.

What steps can reproduce the bug?

Minimal repro:

1. Install Codex CLI normally on WSL.
2. Open a WSL shell in a Linux-backed directory such as:

cd /home/<user>/<repo>

1. Start interactive Codex:

codex --no-alt-screen

1. Observe that startup stalls for roughly 60 seconds before the UI becomes usable.

Control repro:

1. From a Windows-backed cwd instead, for example:

cd /mnt/c/Windows/System32

1. Start the same Codex build, but point it back at the same Linux repo:

codex -C /home/<user>/<repo> --no-alt-screen

1. Observe that the equivalent ~60 second stall does not occur.

Instrumented repro used for trace capture:

CODEX_JS="$(npm root -g)/@openai/codex/bin/codex.js"

cd /home/<user>/<repo>
timeout 75s strace -f -ttT -o home_launch.strace \
  script -q -c "node $CODEX_JS --no-alt-screen" /dev/null

cd /mnt/c/Windows/System32
timeout 20s strace -f -ttT -o windows_cwd_launch_home_C.strace \
  script -q -c "node $CODEX_JS -C /home/<user>/<repo> --no-alt-screen" /dev/null

Representative trace lines from the slow /home/... launch:

execve("/mnt/c/Windows/system32/cmd.exe",
  ["cmd.exe", "/d", "/s", "/c", "set TERM_PROGRAM"], ...)
...
<... poll resumed>) = 1 ([{fd=8, revents=POLLIN}]) <60.024460>
read(7, "'\\\\wsl.localhost\\Ubuntu-22.04\\ho"..., 4096) = 158

Representative trace lines from the control launch from /mnt/c/...:

execve("/mnt/c/Windows/system32/cmd.exe",
  ["cmd.exe", "/d", "/s", "/c", "set TERM_PROGRAM"], ...)

but no corresponding \\wsl.localhost\\... output and no matching ~60 second wait in the same probe path.

What is the expected behavior?

Interactive Codex startup on WSL should not block for ~60 seconds just because the launcher cwd is a Linux path such as /home/....

If Codex needs terminal detection in WSL, I would expect one of these behaviors instead:

• Use a Linux-native probe in WSL rather than spawning cmd.exe
• Or launch the Windows helper with a safe Windows cwd
• Or skip the probe when TERM_PROGRAM is already present

Additional information

Observed facts from my local traces:

• cmd.exe /d /s /c "set TERM_PROGRAM" is executed during startup
• the slow path reproduces when Codex is launched from /home/...
• the slow path does not reproduce in the same way when Codex is launched from /mnt/c/... and given -C /home/...
• pre-setting TERM_PROGRAM=foo does not suppress the cmd.exe probe
• I reproduced this on the current installed CLI here: codex-cli 0.130.0
• before drafting this report, I searched for related WSL / UNC / cmd.exe / TERM_PROGRAM issues and did not find a clear exact duplicate for this specific CLI startup stall

Practical workaround:

cd /mnt/c/Windows/System32
codex -C /home/<user>/<repo> --no-alt-screen

I also have a local shell-level workaround that temporarily shadows cmd.exe, but I am intentionally not leading with that because the simpler control above already isolates the issue enough.

Related reports that seem adjacent but not identical:

• #18506
• #13762
• #14461

If useful, I can attach sanitized trace snippets or provide a smaller reproducer script.