How VS Code Remote Development Works: SSH, Containers, and Tunnels

June 23, 2026 · The Engine Behind Every AI Code Editor (part 5)

▶ Watch on YouTube & subscribe to The Stack Underflow

If you have been following this series, you already know that VS Code is not a monolith — it is a collection of separate processes (UI, extension host, language servers, shell) that talk to each other over message channels. Episode 5 asks the obvious follow-up question: what happens to all those processes when you open a remote machine, a dev container, or a GitHub Codespace?

The answer is almost anticlimactic, and that is exactly the point. Almost nothing changes structurally. The same process model, the same message channels — one of those channels just gets a lot longer.

The one-sentence version: When VS Code goes remote, the UI stays on your machine and everything else moves to the remote machine; the only architectural difference is that one IPC channel becomes a network tunnel.

The local baseline: all processes on one machine

In the default, offline-capable, laptop-on-a-plane scenario, all VS Code processes live on the same machine:

Your Laptop
┌─────────────────────────────────────────────┐
│  Electron UI  ←──IPC──→  Extension Host      │
│                          ↕                   │
│                       Language Servers        │
│                          ↕                   │
│                        Shell / Terminal       │
└─────────────────────────────────────────────┘

Everything communicates through local inter-process communication (IPC). The “channels” are a few inches of wire, or more precisely, local Unix sockets or named pipes. Latency is microseconds. No network required.

What moves when you go remote

When you connect VS Code to a remote target — an SSH host, a Docker container, a cloud VM, GitHub Codespaces — VS Code splits itself in two:

The remote side is collectively called the VS Code Server. It is a lightweight Node.js process that VS Code installs automatically on the remote machine the first time you connect.

Your Laptop                      Remote Machine
┌───────────────┐   network   ┌────────────────────────────┐
│  Electron UI  │ ←──tunnel──→│  VS Code Server             │
│  (thin client)│             │  ├─ Extension Host           │
└───────────────┘             │  ├─ Language Servers         │
                              │  ├─ Shell / Terminal         │
                              │  └─ Your Code (filesystem)   │
                              └────────────────────────────┘

The key insight from the video: the architecture did not change. The same processes exist, the same message channels exist. The only difference is that one of those channels — the one between the UI and the extension host — now travels across a network tunnel instead of crossing a few inches of local IPC.

Same shape, longer wires.

Why this design decision matters

This “thin client UI, fat remote worker” split is not just an engineering curiosity. It is the foundation that makes an entire category of tools possible:

• Dev containers: The VS Code Server runs inside a Docker container. Your UI runs on your host OS. The container can have a completely different OS, toolchain, and environment than your laptop.
• GitHub Codespaces: The VS Code Server runs in a cloud VM. You can close your laptop and the server keeps running. Reopen it from any browser anywhere.
• Remote SSH: Connect to a production-adjacent server with the exact dependencies installed, without copying them to your local machine.
• Cloud agents: Headless VS Code Server instances that keep working after you disconnect — the foundation for AI coding agents that run jobs overnight.

Once the message channels exist and distance stops mattering, the remote machine could be in the next room or in a data center across the ocean. The UI does not know or care.

How extensions behave in this model

Not all extensions run in the same place. VS Code distinguishes:

• UI extensions: Themes, keybindings, anything that only touches the editor surface. These run locally.
• Workspace extensions: Linters, language servers, debuggers, anything that needs to touch your code or the filesystem. These run inside the VS Code Server on the remote machine.

This is why you sometimes have to install an extension “on the remote” separately — it needs to be present on the machine where the extension host lives.

The bigger picture: every AI editor uses this skeleton

The video closes with a statement worth sitting with: Cursor, Windsurf, and GitHub Copilot are all built on this same skeleton. They wrap an AI layer around VS Code’s existing process architecture rather than rebuilding it from scratch.

Understanding the VS Code Server split is therefore not just useful for remote development — it is the prerequisite for understanding how AI coding tools hook into your editor, where they run their inference calls, and why they have the capabilities and limitations they do. That is exactly what the next playlist (“AI agent internals”) digs into.

Common misconceptions

• “Going remote adds a completely new architecture.” It does not. The process topology is identical to local development. The VS Code Server is just the non-UI half of VS Code, packaged to run on a remote host.
• “The VS Code Server is a heavy cloud service I have to provision.” VS Code installs it automatically over SSH the first time you connect. You do not manage it manually in most cases.
• “Extensions work the same locally and remotely.” UI extensions do, but workspace extensions (language servers, linters, debuggers) run on the remote machine. You may need to install them on both sides.
• “Latency ruins the remote experience.” Because only one channel crosses the network (UI ↔ extension host), and VS Code was designed for this, the experience is typically very close to local — especially on a low-latency connection.

Frequently asked questions

What exactly is the VS Code Server? It is a small Node.js binary that VS Code automatically downloads and runs on the remote machine when you connect. It hosts the extension host, language servers, and terminal processes — everything except the UI. You can also run it standalone (headless) using the code-server or code tunnel CLI for browser-based access.

Does remote development require a constant internet connection? It requires a connection to the remote machine, but not necessarily the public internet. SSH remotes over a local network work fine. The connection only needs to stay alive while you are actively working; Codespaces and similar cloud hosts can keep the server running while you are disconnected.

Why does VS Code sometimes ask me to install an extension “on the remote”? Because workspace extensions run inside the VS Code Server on the remote machine, not on your local machine. If you install an extension locally, only the UI side of VS Code knows about it. The remote extension host needs its own copy to actually run language analysis, linting, or debugging against your code.

How does this relate to tools like Cursor or GitHub Copilot? Cursor is a fork of VS Code that preserves this same process architecture and adds AI features on top. GitHub Copilot is a VS Code extension that runs in the extension host — which, in a remote setup, means it runs on the remote machine alongside your code. The VS Code process model is the shared skeleton underneath all of these tools.

Where this fits in the series

This is episode 5 and the finale of the first playlist in How Claude Actually Works. The series started by decomposing VS Code into its separate processes, traced how those processes communicate, and now has shown that the same model stretches cleanly across a network. The next playlist moves up the stack into AI agent internals — how tools like Claude, Copilot, and Cursor are wired into this architecture. Check out all tutorials to follow along.