Windows Desktop tool calls force Windows PowerShell 5.1, causing multi-second UI stalls when powershell.exe startup is slow

What happened?

On Codex Desktop for Windows, tool calls appear to force C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe for command execution / command parsing, even when a faster PowerShell 7 (pwsh.exe) is available and SHELL is set to point to it.

When Windows PowerShell 5.1 startup becomes slow on the machine, Codex Desktop appears to stall for multiple seconds at the beginning of tool calls. This is very noticeable as short hangs in the Codex UI and sometimes coincides with mouse/keyboard stutter.

Environment

• Product: Codex Desktop on Windows
• Codex version from codex doctor --json: 0.137.0-alpha.4
• Desktop app package observed: OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0
• OS from codex doctor --json: Windows 10.0.26200 (Windows 11 Core) [64-bit]
• Shell tool feature flags include: shell_tool, shell_snapshot, tui_app_server

Evidence

Running outside Codex in a normal PowerShell session showed Windows PowerShell 5.1 startup becoming intermittently slow, while cmd.exe remained fast:

Measure-Command { powershell.exe -NoLogo -NoProfile -NonInteractive -Command "exit" }
Measure-Command { cmd.exe /d /c exit }

Observed examples:

powershell.exe: ~4.00s to ~6.88s in slow periods
cmd.exe:        ~0.02s to ~0.15s

After a full Windows restart, powershell.exe temporarily improved to ~0.82s, then later regressed back to ~4s+.

PowerShell 7 portable was tested from a user-local folder without changing the system PowerShell:

pwsh.exe 7.6.2 portable, user-local path

Warm-start timing comparison after restart:

cmd.exe:              ~47 ms avg
powershell.exe 5.1:   ~2563 ms avg
pwsh.exe 7.6.2:       ~1157 ms avg

Earlier warm runs showed pwsh.exe often around ~0.4-0.7s, still materially better than Windows PowerShell 5.1.

Codex behavior observed

After setting a Codex env file:

SHELL=C:\Users\<user>\.codex\tools\PowerShell-7.6.2\pwsh.exe

and restarting Codex Desktop, tool calls still launched Windows PowerShell 5.1. Process inspection showed new children like:

powershell.exe -NoProfile -NonInteractive -Command ...
C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -Command ...
C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoProfile -NonInteractive -EncodedCommand ...

The tool-call environment still reported:

SHELL=C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe
CODEX_SHELL=1
ComSpec=C:\WINDOWS\system32\cmd.exe

So either .codex/.env is not intended to affect shell selection, or the Windows shell runner ignores it / force-selects Windows PowerShell 5.1.

Why this matters

When powershell.exe startup is slow, every Codex shell/tool call can incur multi-second latency or UI stalls. Since Codex may launch several PowerShell children around the same time, the user-visible hang compounds.

The user tried several mitigations first:

• Paused/closed Dropbox sync
• Reorganized Git roots to reduce repo noise
• Added Defender exclusions for Codex paths and processes, including powershell.exe and codex-command-runner.exe
• Restarted Codex and Windows
• Tested PowerShell 7 portable

The remaining bottleneck appears to be that Codex Desktop's Windows runner is pinned to Windows PowerShell 5.1.

Expected behavior

One of these would help:

1. Allow configuring the shell executable for Windows tool calls, for example pwsh.exe.
2. Prefer PowerShell 7 when available.
3. Reuse a persistent runner process more aggressively so repeated tool calls do not pay powershell.exe startup costs.
4. Document the intended way to configure the Windows shell if already supported.

Actual behavior

Codex Desktop keeps spawning Windows PowerShell 5.1 for tool calls, even with PowerShell 7 available and SHELL set to pwsh.exe in the Codex env file.

Notes

This is not a request to remove Windows PowerShell 5.1 support. The ask is for a configurable or faster path when Windows PowerShell startup is slow on a user's machine.