fix(task): resolve bash deterministically on Windows to avoid WSL launcher

[JamBalaya56562]

Summary

When mise spawns bash -c for a task on Windows, prefer a real POSIX bash
(Git Bash / MSYS2) over the WSL launcher at C:\Windows\System32\bash.exe.
The WSL launcher is on PATH first when mise is invoked from PowerShell, and
routing into WSL means the spawned task body runs inside a separate Linux
user-space where mise-managed Windows tools aren't visible — tasks fail with
command not found even though mise install succeeded.

Reproduction

[tools]
bun = "latest"

[tasks.bun-via-bash]
shell = "bash -c"
run = "bun --version"

From Git Bash — works

$ MISE_VERBOSE=1 mise run bun-via-bash
[bun-via-bash] $ bun --version
DEBUG $ C:\Program Files\Git\usr\bin\bash.exe -c bun --version
1.3.13

From PowerShell — fails

PS> $env:MISE_VERBOSE='1'; mise run bun-via-bash
[bun-via-bash] $ bun --version
DEBUG $ C:\WINDOWS\system32\bash.exe -c bun --version
/bin/bash: line 1: bun: command not found
[bun-via-bash] ERROR task failed

uname -s inside the spawned bash returns Linux, confirming the body ran
inside WSL rather than on Windows. Same mise.toml works or fails based
purely on which terminal the user ran mise from.

Why

src/task/task_executor.rs::resolve_posix_shell_program_path calls
which::which_in(&task_env_PATH) to make bash an absolute path before
spawning. Under PowerShell, C:\Windows\System32 precedes any Git Bash
directory on PATH, so the WSL launcher wins. Under Git Bash, MSYSTEM
ordering puts /usr/bin first, so the real bash wins. The previous code had
no Git Bash preference and no WSL-launcher rejection.

Resolution order

The bash-specific path inside resolve_posix_shell_program_path:

1. MISE_BASH_PATH env var — explicit user override (task env, then process env).
2. Common Git Bash install locations:
   • C:\Program Files\Git\bin\bash.exe
   • C:\Program Files (x86)\Git\bin\bash.exe
   • %LOCALAPPDATA%\Programs\Git\bin\bash.exe
3. The existing which::which_in(&task_env_PATH) search.
4. Final guard: if PATH search returns the WSL launcher
   (...\Windows\System32\bash.exe or ...\Microsoft\WindowsApps\bash.exe),
   reject it with a warning and let the spawn fail loudly rather than silently
   routing into WSL.

Scope

• Bash only. sh/zsh/fish/ksh/dash keep the existing behavior.
• Windows only. The relevant code path is already #[cfg(windows)]; Linux
  and macOS builds are unaffected — both resolve_posix_shell_program_path
  and maybe_convert_env_for_msys_shell sit behind #[cfg(windows)] gates.

Test plan

• cargo fmt --check clean

• Unit tests added (Windows-gated):

  • is_bash_basename — accepts bash / bash.exe / BASH.EXE / absolute paths; rejects sh / zsh.exe / fish / dash / cmd.exe / bashfoo
  • is_wsl_launcher_bash — detects C:\Windows\System32\bash.exe (any drive, any case) and ...\Microsoft\WindowsApps\bash.exe (forward or back slash); accepts C:\Program Files\Git\bin\bash.exe, C:\Program Files\Git\usr\bin\bash.exe, C:\msys64\usr\bin\bash.exe, scoop / per-user installs
  • git_bash_candidates — emits Program Files paths; appends a LOCALAPPDATA\Programs\Git\bin\bash.exe candidate when LOCALAPPDATA is in the task env
  • resolve_posix_shell_program_path — MISE_BASH_PATH override is honored via tempdir; non-POSIX shells skip the path; Unix-form PATH skips the path

• All 15 tests in task::task_executor::tests::* pass on Windows MSVC build

• Manual verification on Windows 11 with locally built mise:

  Invoker	Before fix	After fix
  PowerShell	resolves WSL launcher → command not found	resolves Git Bash → task succeeds
  Git Bash	resolves Git Bash → task succeeds	resolves Git Bash → task succeeds (unchanged)

WSL Linux build of mise was not exercised because the relevant code is
#[cfg(windows)] and is not compiled on Linux targets.

Adjacent / related

• Activating Mise installed on Windows and invoked from WSL zsh #5563 — Activating mise on Windows from WSL (opposite direction)
• File based tasks do not work on bash on windows #7507 / fix(task): discover and run shebang file tasks on Windows #7941 — file-based tasks with bash on Windows (partial fix; this is the inline shell = "bash -c" flavor of the same family)
• Proposal: Prevent mise from using Windows-hosted backends in WSL #7642 — Prevent mise from using Windows-hosted backends in WSL (opposite direction)
• fix: mise does not operate well under Git Bash on Windows #4048 — Git Bash detection + dual shim generation (does not cover task-spawn bash resolution)

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR fixes a Windows-specific bug where mise tasks using shell = "bash -c" silently routed into WSL when invoked from PowerShell, because C:\Windows\System32\bash.exe (the WSL launcher) appeared first on PATH. The fix adds a deterministic resolution strategy for bash in resolve_posix_shell_program_path that consults MISE_BASH_PATH, probes common Git Bash / MSYS2 install locations, and then walks PATH via which_in_all filtering out any WSL launchers before falling back.

• src/task/task_executor.rs: New helpers is_bash_basename, bash_candidates, and is_wsl_launcher_bash drive the bash-specific resolution; 15 new #[cfg(windows)] unit tests cover all branches including MSYS2 paths and case-insensitive drive letters.
• src/path.rs: Refactors the basename-stem extraction into a reusable program_stem helper used by both is_posix_shell_program and the new is_bash_basename.
• docs/troubleshooting.md: Adds a clear troubleshooting entry documenting the WSL-launcher symptom and the MISE_BASH_PATH override.

Confidence Score: 5/5

Safe to merge. All new logic is Windows-only and bash-specific; Linux/macOS builds are unaffected. The fallback (returning None and letting spawn fail loudly) is strictly better than the previous silent WSL routing.

The change is narrowly scoped behind #[cfg(windows)], the new helper functions each have their own unit tests, the refactored program_stem extracts existing logic without behaviour change, and the fallback path was already the safe pre-existing default for all other shells.

No files require special attention. src/task/task_executor.rs carries the most new logic but is thoroughly tested.

Important Files Changed

Filename	Overview
src/task/task_executor.rs	Adds bash-specific resolution logic inside resolve_posix_shell_program_path: checks MISE_BASH_PATH override, probes static Git Bash / MSYS2 candidate paths, then walks PATH via which_in_all filtering out the WSL launcher. New helper functions are well-scoped behind #[cfg(windows)] with thorough unit tests.
src/path.rs	Extracts the basename-stem logic from is_posix_shell_program into a new public program_stem helper, then rewrites is_posix_shell_program to use it. Clean refactor; behaviour is identical.
docs/troubleshooting.md	Adds a new Windows-specific troubleshooting section explaining the WSL-launcher pitfall and documenting the MISE_BASH_PATH override. Clear and accurate.

_{Reviews (2): Last reviewed commit: "fix(task): broaden Windows bash candidat..." | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This pull request improves bash resolution on Windows by prioritizing real POSIX bash installations over the WSL launcher, which can interfere with Windows-managed tools. It introduces the MISE_BASH_PATH environment variable, checks common Git Bash installation paths, and adds logic to ignore the WSL launcher. Review feedback suggests using which::all_in to find the first valid bash on the PATH and refactoring the program stem extraction logic into a shared helper to avoid duplication.

[bfrengley]

@JamBalaya56562 this PR breaks bash resolution when a valid bash is first in PATH and also causes a valid windows_default_inline_shell_args set to an absolute path to a valid bash binary (so no PATH resolution needed) to be ignored in favour of git bash.

See #9932 for extra details