Windows: Codex bypasses PATH resolution and incorrectly uses WSL bash instead of user-configured MSYS2 bash

[LaelLuo]

What version of Codex is running?
Latest version

Which model were you using?
N/A (Windows PATH resolution and performance issue)

What platform is your computer?
Microsoft Windows 11 Pro (Build 22621) x64

What steps can reproduce the bug?

1. Install Git via Scoop package manager
2. Verify PATH correctly resolves to Git's bash:

   PS> which bash
   D:\Applications\Scoop\shims\bash.exe
   
   PS> bash --version
   GNU bash, version 5.2.37(1)-release (x86_64-pc-msys)

3. Verify WSL bash is different version:

   PS> wsl bash --version  
   GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

4. Run Codex CLI
5. Observe that Codex ignores PATH and uses WSL bash instead
6. Notice slower startup time and file operations

What is the expected behavior?

Codex should respect Windows PATH resolution and use the Git bash (version 5.2.37) that the system's bash command resolves to, providing optimal performance for Windows file operations.

What do you see instead?

Codex completely bypasses PATH resolution and directly uses WSL bash (version 5.1.16), causing:

Performance Issues:

• Slow startup: WSL initialization overhead significantly delays Codex startup
• Slow file operations: WSL accessing Windows files through /mnt/c/ is much slower than native Git bash
• Cross-system overhead: Unnecessary Linux/Windows file system bridging

Compatibility Issues:

• User autonomy violation: Users cannot control which bash Codex uses
• Environment inconsistency: Commands may behave differently in WSL vs Git bash
• PATH contract violation: System PATH configuration is ignored

Additional information

Root Cause Analysis:
The issue appears to be in codex-rs/core/src/shell.rs Windows detection logic. The current implementation seems to have hardcoded WSL bash detection that overrides PATH resolution.

Evidence of PATH bypass:

PS> Get-Command bash | Select-Object Source
Source
------
D:\Applications\Scoop\shims\bash.exe

# User's bash points to Git bash version 5.2.37 (fast, native Windows)
PS> bash --version
GNU bash, version 5.2.37(1)-release (x86_64-pc-msys)

# But Codex uses WSL version 5.1.16 (slow, cross-system)
PS> wsl bash --version
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

Performance Impact:

• Git bash provides native Windows performance for file operations
• WSL bash introduces cross-system overhead when accessing Windows files
• Users specifically choose Git bash over WSL for performance reasons

Suggested Fixes:

1. Respect PATH resolution: Use the bash that which bash or where bash returns
2. Add bash path configuration: Allow manual override in config.toml:

   [shell] 
   bash_executable = "D:\\Applications\\Scoop\\shims\\bash.exe"

3. Remove hardcoded WSL preference: Don't automatically prefer WSL bash over PATH-resolved bash
4. Display bash detection info: Show which bash version/path Codex will use during startup
5. Performance consideration: Prefer native Windows bash (Git bash) over WSL for better file I/O performance

Who is affected:
Windows 11 users who:

• Use Scoop to manage Git installation
• Work with large codebases where file I/O performance matters
• Experience slow Codex startup times due to WSL initialization
• Expect their PATH configuration to be respected
• Specifically chose Git bash over WSL for performance reasons

This is particularly problematic for Windows developers who specifically avoid WSL due to performance concerns but find Codex forcing WSL usage anyway.

[LaelLuo]

Even using globally installed git doesn't work. After I globally installed git using scoop, I can verify that the system uses git bash:

bash --version
GNU bash, version 5.2.37(1)-release (x86_64-pc-msys)

When I ask codex to execute bash --version, it shows it's already using git bash. However, during codex startup, it still uses WSL bash instead of respecting the PATH-resolved git bash.

[Nonary]

Not a bug, this is just how Windows works when it comes to SYSTEM level paths.

To workaround it, just set the path directly in your shell profile

Example (for PowerShell)

code $PROFILE

Set-Alias -Name bash -Value "D:\Software\MSYS2\usr\bin\bash.exe" -Force
$env:PATH = "D:\Software\MSYS2\ucrt64\bin;" + $env:PATH

Proof:

[LaelLuo]

Thanks @Nonary for the solution! I tested your approach using Set-Alias -Name bash -Value "$env:SCOOP\shims\bash.exe" and it works perfectly for resolving the bash path issue in Codex.

Just to clarify: VSCode extensions are working normally with this setup, so there don't seem to be any issues with VSCode plugin functionality that you mentioned might occur in other discussions.

If this is indeed a Windows system mechanism issue, Codex might not be able to resolve it independently, making this potentially the only viable temporary workaround available.

This is indeed an effective solution for the Windows PATH priority issue. Appreciate the help!

[LaelLuo]

Update: After further testing, I found that the PowerShell alias solution doesn't actually work.

I previously thought it worked because I was testing with a self-compiled version from the main branch. When testing with the official 0.39.0 release, setting the PowerShell alias has no effect at all - Codex still uses WSL bash.

So the PowerShell configuration workaround provided by @Nonary doesn't solve the issue in version 0.39.0. The root cause and proper solution need further investigation.

[LaelLuo]

Clarification: The issue is specifically about Codex's startup bash detection, not tool function calls.

To be clear:

• When Codex makes tool function calls involving bash during normal operation, it correctly follows PATH and uses Git bash
• The problem is only during Codex startup when it runs bash --version for detection - this incorrectly uses WSL bash

So the actual issue is: why does Codex's startup detection bypass PATH resolution while normal tool function calls respect it? This inconsistency causes the performance issues during startup due to unnecessary WSL initialization.

The PowerShell alias workaround doesn't affect the startup detection behavior, which explains why it doesn't solve the problem.

[LaelLuo]

Another strange finding: When I compile version 0.39.0 from source locally, the issue doesn't occur - it works correctly just like the main branch build.

This suggests the problem might be related to:

• Build environment differences between official releases and local builds
• Compiler flags or build configurations used for official releases
• Dependencies or libraries linked during the official build process

The fact that locally compiled 0.39.0 works fine but the official 0.39.0 release has this issue indicates it's not purely a code problem, but possibly a build/packaging issue.