Editors and execution hosts

I split work between VSCode Remote SSH for remote MCP and Zed with extensions and LSP disabled for editing. Editors run on M1 Mac; inference and MCP run on the EPYC + Blackwell compute server.

In the tested setup, Zed resolved MCP commands on Mac while VSCode Remote SSH launched them on compute. I checked the execution host and PATH differences.

Placement plan and changes

Original Plan

Run an editor server on the compute side and make the Mac a thin terminal.

  • VSCode Server or Zed Remote Server on the compute machine
  • MCP servers also on compute, using local runtime directly
  • Mac as the terminal and browser client

Actual Setup

Editors stayed on Mac to use its available resources.

  • Zed: remote editing only. Extensions and LSP disabled — used as a pure editor
  • VSCode Remote SSH: used when MCP is needed
  • Compute server handles inference and MCP server execution

The requirement was to use compute’s uvx, python and container runtimes for MCP.

The requirements were:

  • Use the remote machine’s PATH and binaries as-is
  • Clean up processes automatically when the session ends
  • Limit always-on helper processes
  • Keep compatibility with one-shot execution through podman run --rm

Where the command runs

The same command entry can use a different PATH and runtime depending on which host launches it.

The related VSCode Server setup note uses a single connection and self-contained runtime. MCP follows that remote-subprocess arrangement.

Local startup in Zed

The primary problem was that Zed resolved MCP server commands from the local side, effectively the Mac. Even when I placed .zed/settings.json inside the remote project, that did not make Zed use the remote uvx or python. The command still originated locally.

The Mac-side startup could not resolve the runtime installed on compute.

The tested Zed MCP used stdio from a local process. I considered mcp-remote, but lack of SSE support in the setup prevented a direct remote arrangement.

Concrete Failures Observed in Zed

The concrete failures were consistent:

  • Remote-installed uvx and serena were never referenced.
  • Starting serena through local uvx could not use the compute server PATH.
  • Port forwarding did not materially help because the startup model was still local.
  • No listening MCP process appeared on the remote side during use.

Changing the settings location did not change the process host.

Remote startup in VSCode

VSCode Remote SSH’s extension host ran remotely. mcp.servers command and args used compute’s PATH and environment.

Python and uvx used compute’s environment. Closing the connection also ended the MCP subprocess.

podman run --rm starts a container when needed and removes it on exit.

Observed Behavior (verified with ss -ltnp)

ss -ltnp showed a compute listener such as users:(("python",pid=xxxx)). It disappeared on closing the VSCode connection, matching remote subprocess execution.

The equivalent remote listener did not appear during Zed attempts. I switched clients based on that difference.

Final Design Direction

The planned startup wrapper is /opt/containers/runtime/mcps/run.sh, calling podman run --rm to manage dependencies, volume scope and teardown.

VSCode’s MCP command calls the wrapper as a remote subprocess. Session shutdown and --rm handle process and container cleanup.

Frequently used MCP servers may later move to SSE and quadlet. Current use remains subprocess-based.

Division of uses

VSCode Remote SSH met the requirement to use compute’s runtime. Remote editing in Zed did not change MCP’s execution host in this setup.

VSCode Remote SSH handles MCP; Zed (ext/LSP off) handles editing. For LLM integration development environments, /opt/containers/runtime/mcps/run.sh and podman run --rm separate the execution environment.

Editors on Mac and MCP on compute use both machines’ resources.

Next Steps

Next I plan to define run.sh arguments, environment variables, volume conventions and the corresponding VSCode mcp.servers settings.

Persistent SSE mode would be considered based on startup frequency, initialization cost and shared cache needs.