feat: shell integration-based terminal output capture for remote environments

[shanevcantwell]

Summary

• When the extension host runs on Windows with a remote workspace (SSH, WSL, Dev Container), childProcess.spawn executes locally instead of on the remote. The existing fallback used ide.runCommand (sendText) with no output capture, returning a hardcoded "Command failed" status.
• Adds a new runCommandWithOutput IDE method using VS Code's Shell Integration API (1.93+) to execute commands on remote terminals with full stdout capture and ANSI color preservation.
• When shell integration is unavailable, runCommandWithOutput falls back to sendText internally and the caller reports "Command completed" — no double-execution.

How it works

1. Creates an invisible terminal (not shown to user)
2. Waits for shell integration to activate via onDidChangeTerminalShellIntegration (10s timeout)
3. Executes via shellIntegration.executeCommand(command)
4. Reads output via execution.read() async iterable
5. Strips only VS Code's internal OSC 633 markers; preserves ANSI color codes for UnifiedTerminal's AnsiRenderer
6. Disposes terminal after capture
7. If shell integration is unavailable: shows terminal, sends command via sendText, returns empty string (command still executes, just without output capture)

Files changed (10)

File	Change
core/index.d.ts	Add runCommandWithOutput to IDE interface
core/config/types.ts	Add to global IDE type
core/protocol/ide.ts	Add protocol type
core/protocol/messenger/messageIde.ts	Add proxy method
core/protocol/messenger/reverseMessageIde.ts	Add listener
extensions/vscode/src/extension/VsCodeMessenger.ts	Add handler
extensions/vscode/src/VsCodeIde.ts	runCommandWithOutput() + waitForShellIntegration() implementation
core/tools/implementations/runTerminalCommand.ts	Use new method in remote fallback path
core/tools/implementations/runTerminalCommand.vitest.ts	Update mocks and assertions
core/util/filesystem.ts	Add stub for FileSystemIde

Test plan

• SSH remote: pwd, echo, Python scripts with ANSI output — green "Command completed" with captured output and rendered colors
• WSL remote: Same commands — working, ~5s initial delay due to shell integration startup on WSL terminals
• Native Windows (no regression): Local childProcess.spawn path completely unaffected — no changes to that code path
• Shell integration unavailable: Falls back to sendText internally, reports "Command completed" without double-executing
• Unit tests: 36/37 pass (1 pre-existing failure unrelated to this change)

Related issues

• Fixes runTerminalCommand fails with "spawn powershell.exe ENOENT" when VS Code on Windows host connects to WSL2/Dev Container - Continue extension ignores container environment #10007 (spawn powershell.exe ENOENT in WSL2/Dev Container) — fix: generalize Windows remote detection for terminal commands #10391 partially addressed this by adding the isWindowsHostWithRemote guard but the fallback had no output capture
• Builds on the remote execution guard from fix: restrict terminal childProcess.spawn to local-only environments #10538
• ANSI rendering works with @chezsmithy's UnifiedTerminal component (feat: 💄 Unified Terminal #7383)

🤖 Generated with Claude Code

[haystack-code-reviewer-pr-hook]

Try Haystack Code Reviewer

Want AI-powered code review for this PR? Get instant analysis, interactive visualizations, and actionable insights.

Review this PR with Haystack

[cubic-dev-ai]

1 issue found across 10 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="core/tools/implementations/runTerminalCommand.vitest.ts">

<violation number="1" location="core/tools/implementations/runTerminalCommand.vitest.ts:273">
P0: Fallback on empty output causes commands to execute twice in remote environments</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[shanevcantwell]

Better now in ssh and wsl-Ubuntu remote. Containers, JetBrains, linux mint, macos use the same code path. Thanks for the patience while I got to the core of the issue.

[RomneyDa]

@shanevcantwell I think current implementation would break things for Jetbrains. You could add ide type detection or jetbrains support

[shanevcantwell]

@shanevcantwell I think current implementation would break things for Jetbrains. You could add ide type detection or jetbrains support

Hi Dallin - I completely missed your update here. I'm curious why you think Jetbrains won't go down the same code path as what #10538 fixed. I don't have $700+ to repro tho. I only had the preview subscription.

[shanevcantwell]

Analysis strictly from the code:

PR #10538 established IDE-agnostic routing — the decision is local vs remote, not IDE type. Both VS Code and JetBrains go through ide.runCommand(). No IDE type detection needed there.

PR #10786 adds a new protocol method (runCommandWithOutput). Each IDE implements it natively:

• VS Code → Shell Integration API (this PR)
• JetBrains → terminal widget system, similar to how they implemented runCommand() years ago

This is an implementation gap on the JetBrains side, not an architecture problem. The delegation pattern already works — each IDE provides its own native output capture. Adding it to IntelliJIDE.kt follows the same protocol-driven approach that has worked for all prior PRs (#9679, #9740, #10391, etc.).