Windows: Codex can fail to execute any PowerShell shell commands when PATH resolves an unusable pwsh alias

[jarmen423]

Summary

On Windows, Codex can end up unable to execute any PowerShell-backed shell commands even when the user has a valid PowerShell installation and the Codex config is already set to the most permissive options.

In my case, even trivial shell-tool commands like printing the working directory failed until the PowerShell resolution path was corrected.

This showed up as:

• shell/PowerShell commands consistently failing in the Codex environment
• the model falling back to doing as much as it could in the JS REPL instead
• for anything it could not do in JS REPL, the model would often explain that PowerShell commands were blocked in its environment

This was especially confusing because I had already tried making the environment fully permissive:

• full filesystem access / danger-full-access
• permissive approval settings
• permissive config.toml settings

So from the user side, this looked like a Codex runtime/sandbox failure rather than a local shell-path issue.

Likely root cause

On this machine, PATH surfaced a WindowsApps pwsh.exe alias before the real PowerShell 7 executable.

Codex currently resolves PowerShell through the generic shell lookup path in codex-rs/core/src/shell.rs, which uses PATH/which("pwsh") before the explicit fallback path. That means it can select an alias that looks valid enough to resolve but is not actually usable for Codex process execution.

The end result was that Codex effectively could not execute PowerShell commands at all.

Why this matters

When this happens, the user-visible failure mode is pretty bad:

• shell commands fail broadly
• the model starts routing more work through JS REPL
• tasks that require real shell execution stay blocked
• the assistant can end up repeatedly telling the user that PowerShell is unavailable in the environment

That is a rough degradation path for Windows users because it can make the tool feel fundamentally broken even though the machine has a working PowerShell install.

Proposed fix

Use the existing PowerShell-specific validated discovery helpers for Windows PowerShell selection before falling back to the generic PATH-first shell lookup.

Concretely:

• preserve explicit caller-provided shell paths
• prefer validated pwsh discovery
• then prefer validated powershell.exe discovery
• only after those fail, fall back to the old generic shell lookup path

This keeps the change narrowly scoped to Windows PowerShell selection and reuses logic the repo already has for probing whether a PowerShell executable is actually runnable.

Local patch / validation

I prepared and tested a local patch that makes this change in:

• codex-rs/core/src/shell.rs

Locally validated on Windows with:

• cargo test -p codex-core powershell_shell_prefers_validated_executable_discovery -- --nocapture
• cargo test -p codex-core test_detect_shell_type -- --nocapture

Both passed.

Patch availability

I have a working branch with the fix here:

• branch: jarmen423/windows-powershell-shell-resolution
• commit: a91630011

Compare link:

• https://github.com/openai/codex/compare/main...jarmen423:codex:jarmen423/windows-powershell-shell-resolution?expand=1

I noticed that this repo currently restricts PR creation to collaborators, so I could not open a PR directly from my fork. If this fix looks useful, feel free to cherry-pick or recreate it from that branch/commit.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Windows: tool-called PowerShell fails before command execution, even for trivial commands like 'exit 0' #18465
• Codex on VS Code(Windows) fails to start PowerShell for shell_command calls, causing all local shell operations to fail #17325
• PowerShell profile with oh-my-posh fails inside Codex #18531

Powered by Codex Action

[slix]

Still reproducible with Codex Desktop 26.727.6591.0 on Windows 10 22H2 build 19045 and PowerShell 7.6.4 MSIX.

Codex selected %LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe. Commands failed in both unelevated and elevated Windows sandboxes with:

CreateProcessAsUserW failed: 5 (Access is denied.)

Installing the MSI side-by-side was insufficient while the MSIX alias remained. After removing the MSIX package, Codex selected C:\Program Files\PowerShell\7\pwsh.exe and both sandboxes worked, including bundled Node/Python and workspace access.

Feedback ID: 019f22c0-430b-7163-b40d-1e72397e2ffc

[erfeeneo-rgb]

I reproduced the same underlying WindowsApps pwsh.exe resolution problem, with a slightly different sandbox failure code, and confirmed the workaround/fix with an A/B test.

Environment / symptom

• Windows 11 (build reported by Codex diagnostics: 10.0.26300.0, x64)
• PowerShell 7.6.4 originally installed as Store/MSIX
• Codex was resolving pwsh to:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe

Normal Codex work frequently showed transient shell/PowerShell failures and then recovered through retry/fallback.

A minimal sandbox-only test failed before the requested executable could spawn with:

windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW failed: 1312
(A specified logon session does not exist. It may already have been terminated.)

The raw runner command showed the outer shell was always the WindowsApps alias, even when the requested command was cmd.exe or Windows PowerShell 5.1, e.g. conceptually:

%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe -NoProfile -Command "... & 'C:\Windows\System32\cmd.exe' ..."

So the requested child executable never got a chance to run; the failure occurred while spawning the outer pwsh.exe alias.

A/B validation

1. I disabled the PowerShell App Execution Alias in Windows Settings.
2. where.exe pwsh then returned no result.
3. I fully restarted Codex and opened a fresh thread.
4. The same sandbox-only diagnostic succeeded, with Codex falling back to Windows PowerShell 5.1:

PowerShell version: 5.1.26100.8935
Executable: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe
Exit code: 0
Raw runner error: none

This removed the recurring sandbox/PowerShell error messages in normal Codex use.

Final fix

I then removed the Store/MSIX PowerShell package and installed PowerShell 7.6.4 via the MSI/WiX installer so that the real executable lives at:

C:\Program Files\PowerShell\7\pwsh.exe

After restarting Codex, a direct Windows-sandbox test (no fallback/escalation) reported:

PowerShell version: 7.6.4
Executable: C:\Program Files\PowerShell\7\pwsh.exe
Exit code: 0
Raw runner error: none

I also tested normal operations afterward in Codex Desktop and in the Codex browser sidebar; the previously recurring shell-error messages no longer appeared.

So in this case the root cause was not PowerShell 7 itself, ExecutionPolicy, PATH in general, workspace permissions, or the sandbox being fundamentally broken. It was specifically Codex selecting the Store/MSIX pwsh.exe App Execution Alias from Microsoft\WindowsApps, which could not be spawned correctly by the Windows sandbox runner. Replacing it with the real MSI/WiX pwsh.exe resolved the issue.

This is very similar to the existing report above, but the observed Windows error was 1312 rather than 5, so I wanted to add the variant and the A/B confirmation here.