›_ Codex Issues
Codex Issues / #3468

Windows branch shell.rs frequently and incorrectly handles pwsh, causing command execution failures.

Resolved 💬 6 comments Opened Sep 11, 2025 by zheli1119 Closed Jan 24, 2026
💡 Likely answer: A maintainer (bolinfest, collaborator) responded on this thread — see the highlighted reply below.

What version of Codex is running?

0.34.0

Which model were you using?

GPT-5-high

What platform is your computer?

Microsoft Windows 10 10.0.19045 x64-based PC

What steps can reproduce the bug?

  1. Run a command containing quotes or Windows paths on a Windows environment.
  1. The program incorrectly triggers Unix commands or fails due to escaping issues.

What is the expected behavior?

  • Prioritize pwsh in the Windows branch.
  • If pwsh fails, fallback should be Windows PowerShell, not bash.
  • Optionally perform a self-check at program startup:
  • If Unix tools are required, inform the user clearly to install them instead of silently failing.
  • Avoid repeated failures (currently a single execution may fail 5–6 times), as this makes logs noisy and user interaction confusing.
  • Use ScriptBlock execution for pwsh commands to ensure proper escaping.

What do you see instead?

<img width="727" height="439" alt="Image" src="https://github.com/user-attachments/assets/c1b1d7ae-e47a-48c8-b1c4-c861f1a6ae05" />

<img width="973" height="102" alt="Image" src="https://github.com/user-attachments/assets/b9219a4f-7a5f-4874-b21b-59273074c5aa" />

<img width="1085" height="174" alt="Image" src="https://github.com/user-attachments/assets/fb54877a-1ed9-484c-bd68-9c7a3b3915d2" />

<img width="1051" height="266" alt="Image" src="https://github.com/user-attachments/assets/b2de9762-0510-415b-8e21-95e39a15d982" />

Additional information

I previously submitted a PR (#3253
) that attempted to improve this behavior. While the implementation might not have been perfect, in practice it significantly reduced command execution errors and ensured that pwsh was consistently prioritized.

View original on GitHub ↗

6 Comments

mrairdon-midmark · 11 months ago

This would be awesome to see improved

ledmaster · 11 months ago

Yep, even using Git Bash and explicitly telling it to use bash commands in the AGENTS.md, Codex still gets confused at first

bolinfest collaborator · 11 months ago

@zheli1119 you wrote:

If pwsh fails, fallback should be Windows PowerShell, not bash.

Do you mean pwsh.exe should be the first choice and powershell.exe should be the fallback?

zheli1119 · 11 months ago

@bolinfest

@zheli1119 you wrote: > If pwsh fails, fallback should be Windows PowerShell, not bash. Do you mean pwsh.exe should be the first choice and powershell.exe should be the fallback?

Yes, pwsh.exe should be the first choice.
Here’s why:

  • pwsh (PowerShell 7+) defaults to UTF-8 for pipeline operations, which avoids encoding issues when passing data between tools.
  • powershell.exe (5.x), on the other hand, uses the console’s OEM code page by default, which can cause corrupted characters in pipelines. It also writes output with a BOM, which may lead to further inconsistencies.

In an environment like CLI Version: 0.39.0 with PowerShell 7.5.3, command escaping issues have been significantly reduced, though occasional cases still occur.

I’ve also noticed that if the user has Git Bash (X:\Git\bin) included in their system PATH, the agent’s commands almost never fail, making the experience nearly identical to macOS and Linux.

👉 Suggestion: perhaps we could add a detection prompt on Windows.
If no Bash environment is found in the system PATH, recommend the user to install and configure Git Bash.
This would be similar to how Claude Code refuses to run when no Git Bash is detected.
That way, we don’t even need to worry about choosing between pwsh.exe and powershell.exe, completely avoiding unnecessary complexity.

zheli1119 · 11 months ago
@zheli1119 you wrote: > If pwsh fails, fallback should be Windows PowerShell, not bash. Do you mean pwsh.exe should be the first choice and powershell.exe should be the fallback?

@bolinfest

I found a new bug: when the client machine’s system locale/encoding is non-UTF-8, Codex fails to detect files. It only recognizes files with English (ASCII) names. Even after changing the console OEM code page and/or using pwsh, it still cannot detect files with non-English names.
Codex version: 0.42.0.
This appears to be a serious compatibility issue.

etraut-openai contributor · 7 months ago

I think this bug is no longer relevant, so I'm going to close. If you're seeing a similar problem in the latest version of Codex, please open a new bug with repro details.