fix(core/shell): unify Windows bash detection with which-resolved path

[LaelLuo]

Summary

Make Windows bash fallback detection consistent and predictable by using which::which("bash.exe") to resolve a concrete path and validate that exact path with --version. This ensures "detection source == returned path", eliminating run/which divergence.

Why

On Windows, process execution resolution (current dir → System32 → Windows dir → PATH → App Paths / execution aliases) differs from PATH-based resolution (which).
In WSL + Git Bash setups, this leads to running System32's WSL bash.exe while which resolves Git Bash (or vice versa), causing inconsistent behavior and confusing logs (see #3159).
Returning the which-resolved and validated path ensures "detection source == returned path", eliminating run/which divergence.

How

Windows default_user_shell:

• Get a concrete path via which::which("bash.exe").
• Execute --version against that exact path.
• Set PowerShellConfig.bash_exe_fallback = Some(path) only if it succeeds; otherwise None.
• Keep PowerShell selection logic unchanged (prefer pwsh.exe, else powershell.exe).

Tests:

• Keep PowerShell command formatting test.
• Add an ignored environment test that compares:
  • Run resolution: bash.exe --version
  • Which-resolved path: <which("bash.exe")> --version
• Preconditions: WSL installed; target bash precedes System32\bash.exe in PATH.

Validation

• Unit tests: cargo test -p codex-core.
• Environment demo (optional):
  • Check resolution order: where bash.exe (or PowerShell Get-Command bash.exe -All).
  • Run the ignored comparison test with logs:
    • cargo test -p codex-core shell::tests_windows::test_bash_run_vs_which_with_target_bash_priority -- --nocapture
  • Expected: both succeed; outputs differ (WSL vs target bash), demonstrating the mismatch fixed here.
• Behavioral sanity: bash_exe_fallback always equals the validated which-resolved path; no run/which divergence.

Impact

• Consistency: the reported path is the exact path validated and used.
• Predictability: PATH order controls which bash is used in mixed WSL + Git Bash environments.
• No change to PowerShell invocation formatting; no API changes.

Risks

• Behavior change for setups relying on execution resolving System32's bash.exe while PATH points elsewhere. This is intentional, documented, and controllable via PATH ordering.

Related Issue

Closes #3159

Note

This is a resubmission of PR #4084. The previous PR was closed after a force push to the branch. This PR includes all the same changes and provides an effective fix for the issue.

[etraut-openai]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Hooray!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[etraut-openai]

@LaelLuo thanks for filing the new issue. Could you please fix the lint (clippy cargo) issues so the CI actions pass? Thanks!

[LaelLuo]

@etraut-openai Fixed.

[dylan-hurd-oai]

Nice find - thanks for the contribution! Rather than add an ignored test, I'd prefer to add some assertion we can run consistently, if possible.

[LaelLuo]

Thanks for the suggestion! I've replaced the ignored WSL-only test with a deterministic one. The new test_default_user_shell_prefers_path_bash_override copies the cmd.exe resolved by which::which into a temp dir as bash.exe, prepends that directory to PATH, and asserts default_user_shell() now returns a bash_exe_fallback pointing at that override. If cmd.exe can't be located, the test logs a warning and skips. @dylan-hurd-oai

[dylan-hurd-oai]

LGTM! Will merge this later today / early tomorrow. We are currently holding off on some changes due to the launch gpt-5.1 and gpt-5.1-codex

[LaelLuo]

I have a question. I saw the commit 7b027e7. It seems to be part of your plan. Does this mean that fallback shell will no longer be supported?If it is no longer supported, does that mean this PR is no longer needed?

[etraut-openai]

I'd like to push to get this merged. @LaelLuo, could you please resolve the remaining merge conflict? Assuming that CI is green at that point, I think we're good to go.