[Bug] Windows shell resolution picks WSL bash.exe over Git Bash, breaking Windows commands

[RelaxJonh]

Affected area

Coding agent and CLI (Windows)

What happened?

On Windows with WSL installed, the shell resolution in packages/coding-agent/src/utils/shell.ts can resolve to WSL's bash.exe instead of Git Bash. The findBashOnPath() function uses where bash.exe which may return C:\Windows\System32\bash.exe (WSL's entry point) before Git Bash's location.

WSL bash runs in Linux mode — it cannot execute Windows .cmd or .bat shims. The shouldUseWindowsShell() function in packages/coding-agent/src/utils/child-process.ts handles known package managers (npm, npx, pnpm, yarn, corepack), but arbitrary Windows commands passed through the bash tool would fail silently or produce confusing errors.

The resolution order in getShellConfig() is:

1. Custom shellPath from settings
2. Git Bash in Program Files\Git\bin\bash.exe
3. bash.exe on PATH (Cygwin, MSYS2, WSL)

Step 3 does not distinguish between MSYS2/Cygwin bash (which can run Windows commands) and WSL bash (which cannot). If Git for Windows is not installed but WSL is, Prime Agent silently picks the wrong shell.

Steps to reproduce

1. Windows 11 with WSL installed but Git for Windows NOT installed.
2. Verify where bash.exe returns C:\Windows\System32\bash.exe first.
3. Run prime-agent and execute a bash tool call that runs a Windows .cmd command.
4. The command fails or produces unexpected output because WSL bash interprets it differently.

Expected behavior

The shell resolution should detect WSL bash and either:

• Skip it in favor of a compatible shell, or
• Warn the user that WSL bash is being used and may not work correctly for Windows commands, or
• Document this limitation in the Windows setup guide.

The current windows.md docs list "WSL" as a valid bash source without noting this incompatibility.

Prime Agent version

0.7.2 (source checkout at main)

Environment

Windows 11, WSL2 (Ubuntu), Node.js 24.x

Additional context

A potential fix would be to check if the resolved bash.exe path matches C:\Windows\System32\bash.exe (or more robustly, check if the path contains System32) and either skip it or add a warning. The existing comment in shell.ts:81 mentions WSL as a valid source, but the behavior is undocumented.

Happy to test a fix on my Windows/WSL setup if maintainers consider this in scope.

[RelaxJonh]

Root cause analysis\n\nThe bug is in , function (line ~15-28).\n\nOn Windows, returns ALL matches in PATH order. WSL's entry point typically appears before Git Bash because is earlier in PATH. The function takes \u2014 the first match \u2014 without checking whether it is WSL bash.\n\nWSL bash runs in Linux mode and cannot execute Windows / shims. The function in handles known package managers (npm

Usage:

npm install install all the dependencies in your project
npm install add the dependency to your project
npm test run this project's tests
npm run run the script named
npm -h quick help on
npm -l display usage info for all commands
npm help search for help on
npm help npm more involved overview

All commands:

access, adduser, audit, bugs, cache, ci, completion,
config, dedupe, deprecate, diff, dist-tag, docs, doctor,
edit, exec, explain, explore, find-dupes, fund, get, help,
help-search, hook, init, install, install-ci-test,
install-test, link, ll, login, logout, ls, org, outdated,
owner, pack, ping, pkg, prefix, profile, prune, publish,
query, rebuild, repo, restart, root, run-script, sbom,
search, set, shrinkwrap, star, stars, start, stop, team,
test, token, uninstall, unpublish, unstar, update, version,
view, whoami

Specify configs in the ini-formatted file:
/home/tony/.npmrc
or on the command line via: npm --key=value

More configuration info: npm help config
Configuration fields: npm help 7 config

npm@10.9.7 /home/tony/.hermes/node/lib/node_modules/npm, , Version 10.33.0 (compiled to binary; bundled Node.js v20.11.1)
Usage: pnpm [command] [flags]
pnpm [ -h | --help | -v | --version ]

These are common pnpm commands used in various situations, use 'pnpm help -a' to list all commands

Manage your dependencies:
add Installs a package and any packages that it depends
on. By default, any new package is installed as a
prod dependency
i, install Install all dependencies for a project
ln, link Connect the local project to another one
rm, remove Removes packages from node_modules and from the
project's package.json
unlink Unlinks a package. Like yarn unlink but pnpm
re-installs the dependency after removing the
external link
up, update Updates packages to their latest version based on the
specified range

Review your dependencies:
audit Checks for known security issues with the installed
packages
ls, list Print all the versions of packages that are
installed, as well as their dependencies, in a
tree-structure
outdated Check for outdated packages
why Shows all packages that depend on the specified
package

Run your scripts:
create Create a project from a "create-" or "@foo/create-"
starter kit
dlx Fetches a package from the registry without
installing it as a dependency, hot loads it, and runs
whatever default command binary it exposes
exec Executes a shell command in scope of a project
run Runs a defined package script

Other:
c, config Manage the pnpm configuration files
init Create a package.json file
publish Publishes a package to the registry
self-update Updates pnpm to the latest version

Options:
-r, --recursive Run the command for each project in the workspace., , ), but arbitrary user commands or tool calls that spawn child processes through WSL bash will fail silently or produce confusing errors.\n\n## Suggested fix\n\nIn , iterate through ALL matches from and skip entries under (WSL entry point):\n\n[prime-agent] Using WSL bash (). Windows .cmd/.bat commands may not work correctly. Install Git for Windows for full compatibility.\n\n## Alternative approach\n\nIf the project prefers to avoid at the shell-resolution level, the warning could be emitted in instead, after returns. The key behavior change is the same: skip matches first, fall back to them only if nothing else exists.\n\n## Impact\n\nThis affects any Windows user with WSL installed but Git for Windows not installed. The current behavior silently picks the wrong shell, causing confusing failures in tool calls that spawn child processes. The fix is backward-compatible: users with Git Bash installed are unaffected (Git Bash is already found first by the check in step 2 of ).\n

[RelaxJonh]

Root cause analysis

The bug is in packages/coding-agent/src/utils/shell.ts, function findBashOnPath() (line ~15-28).

On Windows, where bash.exe returns ALL matches in PATH order. WSL's entry point C:\Windows\System32\bash.exe typically appears before Git Bash because System32 is earlier in PATH. The function takes result.stdout.trim().split(/\r?\n/)[0] — the first match — without checking whether it is WSL bash.

WSL bash runs in Linux mode and cannot execute Windows .cmd/.bat shims. The shouldUseWindowsShell() function in child-process.ts handles known package managers (npm, npx, pnpm, yarn, corepack), but arbitrary user commands or tool calls that spawn child processes through WSL bash will fail silently or produce confusing errors.

Suggested fix

In findBashOnPath(), iterate through ALL matches from where bash.exe and skip entries under \System32\ (WSL entry point):

if (process.platform === "win32") {
    try {
        const result = spawnSync("where", ["bash.exe"], { encoding: "utf-8", timeout: 5000 });
        if (result.status === 0 && result.stdout) {
            const matches = result.stdout.trim().split(/\r?\n/);
            // Prefer non-WSL bash: skip C:\Windows\System32\bash.exe which
            // is the WSL entry point and runs in Linux mode — it cannot
            // execute Windows .cmd/.bat shims.
            const nonWsl = matches.find(
                (m) => m && existsSync(m) && !m.toLowerCase().includes("\\system32\\")
            );
            if (nonWsl) return nonWsl;
            // If only WSL bash exists, use it but log a warning so the
            // user understands why Windows commands may fail.
            const firstMatch = matches.find((m) => m && existsSync(m));
            if (firstMatch) {
                console.warn(
                    `[prime-agent] Using WSL bash (${firstMatch}). ` +
                    `Windows .cmd/.bat commands may not work correctly. ` +
                    `Install Git for Windows for full compatibility.`
                );
                return firstMatch;
            }
        }
    } catch {
        // Ignore errors
    }
    return null;
}

Alternative approach

If the project prefers to avoid console.warn at the shell-resolution level, the warning could be emitted in getShellConfig() instead, after findBashOnPath() returns. The key behavior change is the same: skip \System32\ matches first, fall back to them only if nothing else exists.

Impact

This affects any Windows user with WSL installed but Git for Windows not installed. The current behavior silently picks the wrong shell, causing confusing failures in tool calls that spawn child processes. The fix is backward-compatible: users with Git Bash installed are unaffected (Git Bash is already found first by the ProgramFiles\Git\bin\bash.exe check in step 2 of getShellConfig()).