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

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:

```powershell
PS> which bash
D:\Applications\Scoop\shims\bash.exe

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

1. Verify WSL bash is different version:

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

1. Run Codex CLI
2. Observe that Codex ignores PATH and uses WSL bash instead
3. 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:

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

1. Remove hardcoded WSL preference: Don't automatically prefer WSL bash over PATH-resolved bash
2. Display bash detection info: Show which bash version/path Codex will use during startup
3. 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.