WSL: codex-core safe-command test fails when Windows PowerShell is on PATH

Open 💬 2 comments Opened Jul 23, 2026 by sangoi-exe

💡 Likely answer: A maintainer (sangoi-exe, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.145.0; also reproduced from openai/codex main at 44d76c6a6dd04fa2efc302b906ac8774267a1272.

What subscription do you have?

ChatGPT Pro.

Which model were you using?

Not applicable; this is a repository test failure.

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using?

Windows Terminal with WSL2.

Codex doctor report

Not applicable; the failure reproduces in the Rust test suite on a clean upstream checkout.

What issue are you seeing?

just test -p codex-core commands_generated_by_shell_command_handler_can_be_matched_by_is_known_safe_command fails on WSL when Windows PowerShell executables are inherited through PATH:

thread 'tools::handlers::shell::tests::commands_generated_by_shell_command_handler_can_be_matched_by_is_known_safe_command' panicked at core/src/tools/handlers/shell_tests.rs:68:5:
assertion failed: is_known_safe_command(&shell.derive_exec_args(command, true))

The test conditionally exercises every PowerShell executable returned by try_find_powershell_executable_blocking() and try_find_pwsh_executable_blocking(). On WSL those functions find the Windows executables under /mnt/c, but the non-Windows implementation of is_known_safe_command intentionally does not accept PowerShell commands. The resulting expectations are contradictory on WSL.

What steps can reproduce the bug?

Use WSL2 with Windows interop paths present in PATH.
Confirm both commands resolve:

``text command -v powershell.exe command -v pwsh.exe``

In this environment they resolve to:

``text /mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/powershell.exe /mnt/c/Program Files/PowerShell/7/pwsh.exe``

Check out upstream commit 44d76c6a6dd04fa2efc302b906ac8774267a1272.
Run:

``text just test -p codex-core commands_generated_by_shell_command_handler_can_be_matched_by_is_known_safe_command``

The test fails on both nextest attempts.

What is the expected behavior?

The upstream test suite should pass in a normal WSL environment. The test should not require non-Windows safety classification to accept Windows PowerShell executables merely because WSL can discover them.

Additional information

No fork-owned code is needed to reproduce this. The same exact test fails from detached upstream main at the commit above.

View original on GitHub ↗

2 Comments

tylergibbs1 · 1 month ago

i traced this on current main at f47f28cd. the core test, powershell finder, and safe-command classifier are unchanged from the reported revision.

the behavior changed in 42c80385 / #24946. that commit deliberately limited powershell safe-command classification to windows and added non_windows_safe_classification_does_not_spawn_repo_powershell_path, which requires powershell-looking argv to stay unsafe on unix without executing the supplied path. the older core test still discovers powershell on every operating system.

the finder searches PATH and runs the candidate with Write-Output ok. on wsl, the inherited powershell.exe passes that probe, but its argv must then fail the non-windows classifier. accepting it in the classifier would undo the security invariant from #24946.

this can be reproduced on ordinary unix by putting a runnable powershell.exe shim on PATH that exits successfully for the probe. that gives the regression test a portable fixture and keeps the production classifier unchanged.

sangoi-exe contributor · 1 month ago

Thanks — I confirmed this against current main at f61b51dd: the relevant core test, finder, and classifier blobs are still unchanged, so your analysis still applies.

I agree that the production classifier must remain unchanged. Accepting a WSL-discovered Windows PowerShell executable in the Unix classifier would violate the security invariant from #24946.

A runnable powershell.exe shim on PATH is a good portable regression fixture: it can prove that the finder discovers and validates the candidate while the Unix safe-command classifier still rejects the derived PowerShell argv. That reproduces the contradictory old test expectation without depending on WSL or weakening the classifier.

Thanks for tracing the regression window and identifying the portable fixture.