shedix

VS Code on a remote machine: Remote-SSH, code-server or a terminal

By the shedix team · · 5 min read · remote dev, ssh, security, agents

When your code lives on a remote machine, there are three common ways to work on it. VS Code's Remote-SSH extension keeps the editor on your laptop and runs a server on the machine. code-server runs the whole editor on the machine and shows it in a browser tab. Or you skip the editor and use a terminal.

Day to day they feel much the same. They differ in what gets installed where, in where extensions run, and in which direction trouble can travel. Those differences matter more when the machine is one a coding agent works on.

What Remote-SSH installs

You pick a host from your ~/.ssh/config in the Remote Explorer, or name it on the command line, here a host called devbox:

code --remote ssh-remote+devbox /home/dev/work/app

When you connect, the extension installs VS Code Server on the remote machine, separate from any VS Code already there (Remote-SSH docs). It lives in ~/.vscode-server (troubleshooting docs). Your source code never needs to be on the laptop. Most extensions run on the remote machine, while UI extensions such as themes and snippets stay on the laptop.

Thomas Ptacek of Fly.io took a hard look at that server in VSCode's SSH Agent Is Bananas (February 2025). Emacs's Tramp works through the remote shell it finds; VS Code, he wrote, "mounts a full-scale invasion". A shell snippet downloads an agent with its own copy of Node, which talks back to the editor through a forwarded SSH port and can roam the filesystem, edit any file, start its own shells and stay installed. He'd be uneasy about people editing dev servers that way, and far more so a production machine during an incident.

On a machine that exists to be worked on, much of that is the point: the server runs language tools next to the code, and on a throwaway machine it hardly matters what it leaves behind. That's where Ptacek was heading too. His post starts from wanting agents to run in a loop on a clean Linux machine that can't hurt you, rather than on a laptop, where they'll wander well past the project they were given.

The direction that matters on an agent's machine

Ptacek's worry runs from the editor to the server. On a machine where an agent runs commands, installs packages and reads text written by strangers, the other direction matters more: the machine reaching your laptop.

Microsoft's Security Note for Remote-SSH covers it. It asks you to connect only to remote machines you trust, and says a compromised remote could use the connection to run code on your local machine. In 2025, Tuyen Le, An Nguyen and Khanh Pham of Calif showed one way: an extension on a compromised server opened a terminal on the developer's own computer and typed commands into it, with default settings in both VS Code and Cursor.

So if an agent runs on a machine with few prompts, assume that machine could be compromised one day, and decide what your editor's connection should give it.

code-server: the editor lives on the machine

code-server, from Coder, runs VS Code on the machine and serves it to your browser. The editor's server and its extensions run there; your laptop runs a browser tab. Out of the box it listens on 127.0.0.1:8080 and asks for a password generated into ~/.config/code-server/config.yaml. Its setup guide recommends reaching it through an SSH tunnel:

ssh -N -L 8080:127.0.0.1:8080 dev@203.0.113.10

Then open http://127.0.0.1:8080 on your laptop. The same guide warns never to put code-server on the internet without authentication and encryption, since whoever gets in gets a terminal on the machine.

Extensions come from a different place. Microsoft's terms reserve its marketplace for Microsoft's own products, so code-server uses Open VSX, the gallery other VS Code forks use too. Its FAQ admits Open VSX isn't perfect, and Microsoft's closed-source Live Share and Remote extensions aren't available. You can point code-server at another gallery, but its FAQ discourages using Microsoft's, since that breaks Microsoft's terms.

Where extensions run

An extension runs wherever the editor's extension host runs, with that user's permissions. In late October 2026, Calum Hall of Phorion reported that versions 2.1.312 and 2.1.313 of the Claude Code extension on Cursor's marketplace carried a backdoor, which Cursor then removed. Per the advisory, the code ran as soon as the extension loaded. It added an attacker's key to ~/.ssh/authorized_keys, tried to turn on SSH, opened a reverse SSH tunnel, arranged to start again after a reboot, and reported the host's details along with the names, not the values, of environment variables that looked like secrets.

Where that runs depends on the setup:

  • The editor on your laptop alone: on your laptop.
  • Remote-SSH: most extensions run on the remote machine and UI extensions on the laptop, so it depends on the extension's kind, and the connection itself still reaches back to the laptop.
  • code-server: on the remote machine. The exception is a web extension, which VS Code in a browser can run inside the tab, in a web worker.

None of these makes a bad extension harmless. Running the editor on the machine changes what it can reach: the machine's files and sign-ins rather than your laptop's.

When a terminal is enough

With an agent doing most of the editing, you often need less editor than you think. You read diffs, run tests and steer, and SSH with tmux covers all three. Nothing new is installed on the machine, and your laptop runs only ssh. To see what the agent changed:

ssh dev@203.0.113.10 'cd ~/work/app && git status --short && git diff --stat'

Or push its branch and review the pull request. Reach for an editor when you need to read a lot of code or fix something by hand.

How shedix does it

shedix machines offer both. On every stack except Plain, the machine runs code-server, and VS Code on the machine's page opens it in a new tab already signed in: the page sends the machine's password to code-server's own sign-in, so you type nothing. It's reached through a Cloudflare tunnel at a random address and asks for that password when opened any other way. An open VS Code tab counts as use, so the machine stays awake while you edit.

For VS Code or Cursor on your laptop, shedix code <name> connects with Remote-SSH (add --cursor for Cursor). It puts shedix's own SSH key on the machine if it isn't there, writes host entries under ~/.config/shedix, adds one Include line at the top of ~/.ssh/config so the editor finds machines by name, and runs code --remote ssh-remote+<name>. shedix ssh <name> opens a plain shell.

To give a machine an agent works on as little of your laptop as possible, edit in the browser or use a terminal, and keep Remote-SSH for machines you'd trust as much as the laptop itself. Our security page lists what shedix isolates and what it doesn't, and Off your laptop shows the everyday setup.