fix: skip cmd.exe wrapping for MCP servers when Windows host connects to WSL

[shanevcantwell]

Summary

• Fixes MCP servers failing to start with cmd.exe not found when Windows VS Code connects to WSL
• Root cause: resolveCommandForPlatform() wrapped batch commands (npx, uvx, etc.) with cmd.exe even when connected to WSL remote
• Solution: Add isWindowsHostWithWslRemote check (same pattern as PR fix: use ide.runCommand when Windows host connects to WSL #9679)

Fixes #9151

Test plan

• Unit tests for all scenarios (WSL remote, local Windows, Linux, non-batch commands)
• Manual test: Configure MCP server (e.g., filesystem) in WSL workspace, verify it connects
• I'm not sure why CI is consistently timing out on building the win32-64, because that binary also shows up as a completed artifact in the CI failure message I'm sent.

Related PRs

• PR fix: use ide.runCommand when Windows host connects to WSL #9679 - Terminal ENOENT fix (merged) - established the isWindowsHostWithWslRemote pattern
• PR fix: pass pre-read content to RegistryClient for WSL compatibility #9739 - Path construction fix (open) - same WSL theme

🤖 Generated with Claude Code

---

Continue Tasks: ▶️ 2 queued — View all

---

Summary by cubic

Fixes MCP servers failing to start in WSL when VS Code on Windows connects to WSL by not wrapping batch commands with cmd.exe. WSL is now detected so Linux commands run directly.

• Bug Fixes

  • Skip cmd.exe wrapping on Windows hosts when remoteName is "wsl".
  • Added unit tests for WSL remote, local Windows, Linux, and non-batch commands.

• Refactors

  • Made resolveCommandForPlatform async to query IDE info.

^{Written for commit 74095d9. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files

[RomneyDa]

Nice fix!