[Windows] resolveShellPath() early-returns on win32, preventing shell-augmented PATH from reaching Claude Code subprocess

[oyardena]

Summary

resolveShellPath() in the VS Code extension unconditionally returns undefined on Windows:

static resolveShellPath(e) {
    if (process.platform === "win32") return;  // skips all PATH resolution
    // ... spawns $SHELL -lic to read login-shell PATH on other platforms
}

Combined with $d() only updating r.PATH when the result is truthy:

function $d(e) {
    let r = { ...process.env };
    if (e) r.PATH = e;  // never executes on Windows
    // ...
}

The Claude Code subprocess launched by the extension inherits only the parent Windows process.env.PATH, not any login-shell PATH augmentation. On non-Windows platforms the extension spawns $SHELL -lic 'command printenv PATH' to get the full resolved PATH; this is skipped entirely on Windows.

Impact

• Tools installed only in WSL (e.g. gh, python3, node via NVM in WSL) are not found by Claude Code on Windows unless also natively installed in Windows PATH.
• Claude Code may incorrectly claim a tool is "not available" when it exists in the user's WSL or login-shell PATH.
• Regression path: agent uses bare gh in Bash → fails → claims gh unavailable → falls back to WebFetch, losing CLI capabilities (pagination, auth, structured output).

Reproduction

1. Fresh Windows install, Git Bash configured.
2. Install gh only in WSL (sudo apt install gh && gh auth login). Do not install native gh.exe on Windows.
3. Open Claude Code in Cursor/VS Code on Windows.
4. Ask the agent to run gh pr view <number>.
5. Observe: Bash tool reports "command not found: gh"; agent claims gh unavailable and falls back to WebFetch.

On macOS/Linux the same setup works because resolveShellPath spawns the login shell and picks up the correct PATH.

Expected behavior

On Windows, resolveShellPath should resolve tools available in the user's shell environment. Possible implementations:

1. Git Bash: if %GIT_INSTALL_ROOT%\bin\bash.exe exists, spawn bash -lc 'command printenv PATH' to get the augmented PATH.
2. WSL probe: if wsl.exe is available, additionally check wsl.exe -e command -v <tool> before claiming unavailability.
3. Minimum viable: run where.exe <tool> to check Windows PATH, then wsl.exe -e which <tool> as fallback before reporting a tool as missing.

Workaround

Install the tool natively on Windows PATH (e.g. winget install GitHub.cli for gh). This bypasses the PATH resolution issue since process.env.PATH then includes the tool.

Extension version

anthropic.claude-code-2.1.181-win32-x64 (confirmed in package.json)

Platform

Windows 11 Enterprise 10.0.26200, Cursor IDE