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

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.