MCP servers fail on SSH/remote: cmd.exe spawned locally instead of on remote

[shanevcantwell]

Bug Description

When VS Code is connected to a remote workspace via SSH (and likely Dev Containers), MCP servers configured with stdio transport fail with:

Failed to connect to "New MCP server" Error: command "cmd.exe" not found. To use this MCP server, install the cmd.exe CLI.

Root Cause

Two related issues in core/context/mcp/MCPConnection.ts:

1. resolveCommandForPlatform() only handles WSL remotes (line 429)

const isWindowsHostWithWslRemote =
  process.platform === "win32" && ideInfo?.remoteName === "wsl";

This bypasses cmd.exe wrapping for WSL but not for SSH or other remote types. On SSH remotes, batch commands like npx still get wrapped as cmd.exe /c npx, which fails because cmd.exe doesn't exist on the Linux remote.

2. Deeper: StdioClientTransport spawns locally, not on remote

Even if the cmd.exe wrapping is fixed, the underlying StdioClientTransport uses cross-spawn (Node's child_process.spawn()) which executes in the Local Extension Host on Windows — not on the remote. The MCP server process would be spawned on the Windows host regardless of the command used.

This is the same class of bug fixed for terminal commands in PR #10786, where childProcess.spawn() was replaced with VS Code's terminal API for remote execution.

3. PATH resolution also only handles WSL (line 569)

const isWindowsHostWithWslRemote =
  process.platform === "win32" && ideInfo?.remoteName === "wsl";
if (process.platform !== "win32" || isWindowsHostWithWslRemote) {

SSH remotes also need Linux shell PATH resolution, not the Windows PATH.

Steps to Reproduce

1. Open VS Code connected to an SSH remote (Linux host)
2. Configure an MCP server in Continue with a stdio command (e.g., npx @playwright/mcp@latest)
3. Observe the "cmd.exe not found" error

Expected Behavior

MCP servers should spawn on the remote host when VS Code is connected to a remote workspace.

Context

• extensionKind: ["ui", "workspace"] causes the extension to run in the Local Extension Host on Windows
• process.platform returns "win32" even when connected to a Linux remote
• Compare with runTerminalCommand.ts line 122 which correctly checks !["", "local"].includes(ideInfo.remoteName) for any remote type
• Related: PR feat: shell integration-based terminal output capture for remote environments #10786 (terminal command remote fix), issue runTerminalCommand fails with "spawn powershell.exe ENOENT" when VS Code on Windows host connects to WSL2/Dev Container - Continue extension ignores container environment #10007

Environment

• Windows 11 + VS Code SSH Remote to Linux host
• Continue extension running in Local Extension Host