run_terminal_command fails with spawn powershell.exe ENOENT over VS Code Remote-SSH from Windows
In Continue v1.3.31 pre-release with VS Code on Windows 11 connected via Remote-SSH to Ubuntu 24.04, run_terminal_command immediately fails with "run_terminal_command failed with the message: spawn powershell.exe ENOENT". Why does it try to start PowerShell on the Linux remote, and how can I fix it?
Originally asked on GitHub: https://github.com/continuedev/continue/issues/10462
6 answers
The reported Windows-to-SSH-Remote case is fixed: PR #10391 was merged and closed this issue. The root cause was that the Continue extension runs in the Local Extension Host on Windows because of extensionKind: ["ui", "workspace"]. getShellCommand() checks process.platform, sees "win32", and returns powershell.exe, but child_process.spawn() then tries to run that binary on the Windows host instead of the remote Linux host. PR #10391 adds detection with isWindowsHostWithRemote = process.platform === "win32" && !["", "local"].includes(ideInfo.remoteName) and routes the command through ide.runCommand() so it executes on the remote. Related issues include #9661, #10007, #8826, and #10433.
Follow-up comments in the thread show the same ENOENT pattern still occurred in some environments after that fix: Linux host to Linux server produced "spawn /bin/sh ENOENT", macOS to SSH Linux produced "spawn /bin/bash ENOENT", and Dev Containers produced "spawn /bin/sh ENOENT" even though /bin/sh existed on both host and container. A contributor confirmed the fix did not fully address those cases and pointed to PR #10538, which restricts childProcess.spawn to local-only environments, and PR #10786, which replaces it with the VS Code Shell Integration API for output capture on all remote types. If you still see the error after updating, check whether your release includes those PRs; as general advice, verify which remote types are covered by your installed Continue version before relying on run_terminal_command.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
Reproduced the failure by opening a workspace on a remote Linux host over VS Code Remote-SSH and asking the model to run a terminal command like pwd; Continue v1.3.31 pre-release returned "spawn powershell.exe ENOENT".
Source: https://github.com/continuedev/continue/issues/10462 (opens external site)
Did this work for you?What @dochy-ksti tried on GitHub (Didn't work)
Set up an MCP shell server using "npx -y @modelcontextprotocol/server-shell" and asked the agent to run ls; the terminal tool still failed with "spawn powershell.exe ENOENT" on the same Windows-to-SSH-Linux setup.
Source: https://github.com/continuedev/continue/issues/10462#issuecomment-3900476833 (opens external site)
Did this work for you?What @emilations tried on GitHub (Didn't work)
On a Linux host connecting to a Linux server over Remote-SSH, running a terminal command produced "spawn /bin/sh ENOENT" instead of the PowerShell error.
Source: https://github.com/continuedev/continue/issues/10462#issuecomment-3904945216 (opens external site)
Did this work for you?What @martianrock tried on GitHub (Didn't work)
In a dev container on Windows, run_terminal_command failed with "spawn /bin/sh ENOENT" even though /bin/sh is present on both the host and the container.
Source: https://github.com/continuedev/continue/issues/10462#issuecomment-3911264231 (opens external site)
Did this work for you?What @avlis tried on GitHub (Didn't work)
From VS Code on macOS connecting via Remote-SSH to a Linux server, running a terminal command like echo $HOSTNAME failed with "spawn /bin/bash ENOENT".
Source: https://github.com/continuedev/continue/issues/10462#issuecomment-4073377387 (opens external site)
Did this work for you?