run_terminal_command fails with "spawn powershell.exe ENOENT" via SSH Remote from Windows

[shanevcantwell]

Before submitting your bug report

• I've tried using the "Ask AI" feature on the Continue docs site to see if the docs have an answer
• I'm not able to find a related conversation on GitHub discussions that reports the same bug
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS: Windows 11 (host) → Ubuntu 24.04 (remote via SSH)
- Continue version: v1.3.31 pre-release
- IDE version: VS Code 1.96+ with Remote-SSH extension
- Model: nvidia/nemotron-3-nano-30b-a3b via LM Studio
- Connection: VS Code Remote-SSH to Linux host

Note

Filing this for searchability — this is the SSH Remote variant of #9661 (WSL) and #10007 (WSL/Dev Container). We reproduced it while testing tool overrides over an SSH tunnel and realized the scenario wasn't documented as its own issue. PR #10391 (already merged) fixes this, so this can be closed at your convenience. Apologies for the extra triage work — just wanted a findable record for anyone hitting this specific error via SSH Remote.

Description

When VS Code on Windows connects to a Linux host via SSH Remote, run_terminal_command fails immediately:

run_terminal_command failed with the message: spawn powershell.exe ENOENT

Root cause: extensionKind: ["ui", "workspace"] runs the Continue extension on the Windows host. getShellCommand() checks process.platform, gets "win32", and returns powershell.exe — but the command should execute on the remote Linux host where powershell.exe does not exist.

To reproduce

1. Open VS Code on Windows
2. Connect to a Linux host via Remote-SSH
3. Open a workspace on the remote host
4. In Continue chat, ask the model to run any terminal command (e.g., pwd)
5. Observe: spawn powershell.exe ENOENT

Resolution

Fixed by #10391, which generalizes Windows remote detection to all remote types (WSL, SSH, Dev Container, Codespaces, tunnels):

const isWindowsHostWithRemote =
  process.platform === "win32" && !["", "local"].includes(ideInfo.remoteName);

When true, the implementation delegates to ide.runCommand() instead of spawning a local shell.

Related: #9661, #10007, #8826, #10433

Log output

run_terminal_command failed with the message: spawn powershell.exe ENOENT

[dochy-ksti]

I couldn't reproduce this, but I also saw this message.

I made a mcp server for shell

name: Local Config
version: 1.0.0
schema: v1
models:
  - name: "QwQ-32B"
    provider: "ollama"
    model: "qwq:32b"
    apiBase: "http://192.168.1.73:11434"

mcpservers:
  - name: shell
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-shell"

and I sent the message "shell機能を使ってlsを実行して"(run ls command with shell function) to the the agent.

The prompt which wanted to run command "ls" appeared and I accepted.

The output is

$ ls

run_terminal_command failed with the message: spawn powershell.exe ENOENT

• OS: Windows 11 (host) → Ubuntu 24.04 (remote via SSH)
• Continue version: v1.3.31 pre-release
• IDE version: VS Code 1.109.3+ with Remote-SSH extension
• Model: QwQ:32B via Ollama
• Connection: VS Code Remote-SSH to Linux host

[emilations]

I wish this could also be implemented from linux host to linux server as well.

[shanevcantwell]

I wish this could also be implemented from linux host to linux server as well.

Are you getting a spawn powershell.exe error when going from linux->linux? It looks like maybe you could be still looking at your host's filesystem and not the server's. Is that the symptom?

[emilations]

I wish this could also be implemented from linux host to linux server as well.

Are you getting a spawn powershell.exe error when going from linux->linux? It looks like maybe you could be still looking at your host's filesystem and not the server's. Is that the symptom?

The error I get is:

run_terminal_command failed with the message: spawn /bin/sh ENOENT

Please try something else or request further instructions.

[shanevcantwell]

I'll look into it. This fix doesn't fully address it yet.

[shanevcantwell]

It's part of a pattern that has improved for the Windows->WSL side as with #10538. This expands that fix even further to all remote environments. The pattern had good intent (#10542) but unfortunately causes problems with remote environments such as wsl and containers that render the terminal command tool unusable.

[martianrock]

This error also happens in devcontainer. run_terminal_command failed with the message: spawn /bin/sh ENOENT. /bin/sh is present in both host and container.

[shanevcantwell]

@martianrock Confirmed — Dev Containers hit the same spawn ENOENT as SSH and WSL. The extension runs in the Local Extension Host on Windows, so child_process.spawn() tries to execute the remote shell locally.

Two open PRs fix this:

• PR fix: restrict terminal childProcess.spawn to local-only environments #10538 — Restricts childProcess.spawn to local-only environments
• PR feat: shell integration-based terminal output capture for remote environments #10786 — Replaces it with VS Code Shell Integration API for output capture on all remote types (WSL, SSH, Dev Containers)