Terminal output not captured when Windows VS Code connects to WSL (follow-up to #9679)

[shanevcantwell]

Before submitting your bug report

• I've tried using the "Ask AI" feature on the Continue docs site
• I'm not able to find a related conversation on GitHub discussions
• 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 with WSL2 (Ubuntu)
• Continue version: Built from feature branch with fix: use ide.runCommand when Windows host connects to WSL #9679 merged
• IDE version: VS Code 1.96+
• Extension installed: LOCAL (Windows)

Description

This is a follow-up to #9679 which fixed the spawn powershell.exe ENOENT error when Windows VS Code connects to WSL.

Background:

• Issue Bug: Cannot run commands in terminal "The URL must be of scheme file" #8091 reported "The URL must be of scheme file" - fixed by PR fix: handle non-file URI schemes in runTerminalCommand for WSL2 #9325
• Issue VSCode: spawn powershell.exe ENOENT #9661 reported "spawn powershell.exe ENOENT" - fixed by PR fix: use ide.runCommand when Windows host connects to WSL #9679
• PR fix: use ide.runCommand when Windows host connects to WSL #9679 detects isWindowsHostWithWslRemote and falls through to ide.runCommand() instead of spawning

Current behavior:
The fix in #9679 successfully prevents the spawn error, but ide.runCommand() only sends text to VS Code's terminal via terminal.sendText() - it cannot capture output. The command executes successfully (visible in terminal), but Continue receives:

Terminal output not available. This is only available in local development environments and not in SSH environments for example.

Proposed solution:
For the isWindowsHostWithWslRemote case, instead of falling through to ide.runCommand(), spawn wsl.exe from Windows to execute commands in WSL with output capture:

if (isWindowsHostWithWslRemote) {
  // Use wsl.exe to spawn into WSL and capture output
  const shell = "wsl.exe";
  const args = ["-e", "bash", "-l", "-c", command];
  // ... rest of spawn logic with output capture
}

This allows the Windows extension host to execute commands in WSL while still capturing stdout/stderr.

To reproduce

1. Install Continue extension on Windows (LOCAL, not WSL)
2. Connect VS Code to WSL
3. Ask Continue to run a terminal command (e.g., "What folder are we in?")
4. Command runs visibly in terminal but Continue shows "Terminal output not available"

Related issues

• Bug: Cannot run commands in terminal "The URL must be of scheme file" #8091 - Original "scheme file" error (fixed by fix: handle non-file URI schemes in runTerminalCommand for WSL2 #9325)
• VSCode: spawn powershell.exe ENOENT #9661 - spawn powershell.exe ENOENT (fixed by fix: use ide.runCommand when Windows host connects to WSL #9679)
• Continue VS Code extension fails to start MCP servers in WSL workspaces (looks for cmd.exe inside Ubuntu) #9151 - MCP servers in WSL look for cmd.exe

[sestinj]

Related issues:

• VSCode: spawn powershell.exe ENOENT #9661 - spawn powershell.exe ENOENT (fixed by PR fix: use ide.runCommand when Windows host connects to WSL #9679, which this issue is a follow-up to)
• Bug: Cannot run commands in terminal "The URL must be of scheme file" #8091 - Original "scheme file" error when running terminal commands (fixed by PR fix: handle non-file URI schemes in runTerminalCommand for WSL2 #9325)
• Continue VS Code extension fails to start MCP servers in WSL workspaces (looks for cmd.exe inside Ubuntu) #9151 - MCP servers in WSL look for cmd.exe (same Windows host + WSL remote pattern)
• Code-Server bug where it says "Terminal output not available" even though it works on Kilo Code #7636 - Terminal output not available in code-server (same error message, different environment)
• @Git Diff context provider fails in WSL (Remote) - "Git shows no current changes" #9136 - @git Diff context provider fails in WSL Remote (related WSL path resolution issues)

[shanevcantwell]

WSL Support Dependencies

Fixing terminal output capture for WSL is part of a broader set of Windows+WSL detection issues. Here are the related bugs that share the same root cause pattern:

Already Open

• Continue VS Code extension fails to start MCP servers in WSL workspaces (looks for cmd.exe inside Ubuntu) #9151 - MCP cmd.exe ENOENT in WSL (same pattern as VSCode: spawn powershell.exe ENOENT #9661)
• @Git Diff context provider fails in WSL (Remote) - "Git shows no current changes" #9136 - Git diff fails in WSL
• Git Diff always returns no changes on WSL #2822 - Git diff always returns no changes on WSL
• Can not access build in tools in remote server opened by SSH #8072 - Built-in tools fail on SSH remote

New Issues (opened as dependencies)

• IntelliJ: Windows → WSL remote not detected (only SSH detected) #9735 - IntelliJ WSL detection
• CLI: runTerminalCommand has no remote/WSL detection #9736 - CLI no remote detection
• shellPath.ts returns undefined for Windows even when connected to WSL #9737 - Shell path undefined on Windows+WSL

Root Cause

All these issues stem from extensionKind: ["ui", "workspace"] causing the extension to run on Windows while the workspace is in WSL. Code that checks process.platform gets "win32" but needs to execute in a Linux context.

The Pattern

PR #9679 established the fix pattern:

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

This pattern should be applied consistently across all process spawning code paths.

[miks2021]

The issue is falsely claimed to be closed by #9810, however #9810 resolved it for cli only, not for vscode extension. I am still experiencing the same error on Continue for vscode v1.3.30
@RomneyDa @uinstinct