Why VS Code Remote is the right shape for this, not a new mechanism

VS Code Remote-SSH doesn't just open a terminal on a remote machine — it installs and runs the actual VS Code server, and every extension you add, inside the machine you connect to. Install Continue from a Remote-SSH window and it runs inside the Linux guest, not on your Mac. Its requests to a local model endpoint resolve inside the guest exactly the way a CLI agent's do: through the same socat proxy forwarding traffic across the vsock channel to AI Bridge on the host. There's no separate "GUI-aware" bridge feature to turn on — it's the identical connection covered in the AI Bridge architecture post, reached from a different client.

What Velo Workspaces actually generates for you

A running Linux workspace's Developer Tools tab has three sections: SSH Access, Console, and VS Code Remote. The VS Code Remote section is a ready-to-paste ~/.ssh/config block, with a Copy button, built from the workspace's own name:

# Add to ~/.ssh/config
Host my-workspace-name
    HostName <workspace-ip>
    User <username>
    Port 22

Two things worth knowing about that snippet before you paste it. First, it only appears once the workspace is a Linux guest with SSH enabled — a setting chosen when the workspace is created (or in its profile), not something you flip live on a running one, the same as CPU, memory, or storage. Second, <username> is a deliberate placeholder, not a guessed "ubuntu" or "debian" login. Velo used to guess the distribution's conventional cloud-image account name, which was wrong for every workspace installed from an ISO — covered in this blog's own Ubuntu and Debian posts, the official-image picker downloads the distro's actual installer ISO and you go through its normal interactive install, inventing your own account along the way. There's no cloud-image convention to guess from, so the app tells you to fill in what you actually typed rather than silently getting it wrong.

Set up, step by step

  1. Create or pick a Linux workspace with SSH enabled. The Ubuntu Developer template ("Best for most developers") is built for exactly this — its own description is "For coding, shared projects, and VS Code Remote." Turn on AI Bridge too, in Resources if it isn't already (the AI Sandbox profile turns it on by default; Ubuntu Developer doesn't).
  2. Install a model server on your Mac — Ollama or MLX, whichever you prefer. The complete guide has the install commands and a RAM-to-model-size table for picking what actually fits your Mac; no need to repeat it here.
  3. Start the workspace, open its Developer Tools tab, and copy the VS Code Remote config into ~/.ssh/config on your Mac. Replace <username> with the account you created during the guest's own install.
  4. In VS Code on your Mac, install the Remote - SSH extension if you don't have it, then Remote-SSH: Connect to Host and pick the alias from the config you just added.
  5. Inside that remote window — this part matters — install the Continue extension. Installing it while connected puts it on the guest side of the connection, which is the whole point.
  6. Establish the guest's vsock forwarder, the same one-time step every CLI agent in the complete guide uses: open the workspace's AI Bridge tab for the exact port-filled command, install socat, and either run the forwarder for the session or install it as a systemd service so it survives reboots.
  7. Point Continue at the bridge. Inside the remote VS Code window's integrated terminal (so this lands on the guest, not your Mac), edit ~/.continue/config.yaml: 
    name: Local via AI Bridge
version: 0.0.1
schema: v1
models:
  - name: Local Model
    provider: openai
    model: <model-name>
    apiBase: http://127.0.0.1:<PORT>/v1
    apiKey: local
    roles:
      - chat
      - edit
      - autocomplete
    <PORT> is 11434 for Ollama or 8080 for MLX, and <model-name> is whatever you pulled in step 2. Reload the window, and Continue's chat and inline-edit panels should list Local Model.

What this actually buys you over pointing Continue at Ollama directly

The obvious shortcut: if Ollama is already running on your Mac, why not just install Continue in a normal, non-remote VS Code window and point it at 127.0.0.1:11434 directly? Nothing stops you — but then Continue's edits land on your real Mac filesystem, and anything its agent mode executes runs there too. Routing through VS Code Remote moves the actual editing and code execution into the disposable guest instead, which is exactly the isolation argument this blog's AI agent security post makes for CLI agents — a suggestion Continue proposes, or a command its agent mode runs, that goes wrong costs you nothing more than closing the workspace. The model inference itself still happens on the Mac's own GPU either way; only the editing and execution surface moves.

A gotcha worth knowing before it wastes a debugging session

Switching AI Bridge's host provider — say, from Ollama to MLX — re-points the host-side listener immediately, but the guest's socat forwarder unit is a file that still names the old port, and nothing about a workspace restart touches it. This is the same gotcha the AI Researchers post covers for CLI agents, and it applies identically here: if Continue suddenly can't reach the model after you switch providers, re-run the forwarder setup command from the AI Bridge tab again before assuming something else broke.

Related reading: the architecture behind AI Bridge, the complete guide this setup extends with a GUI path, why isolating the edit-and-execute surface matters, and what actually leaves your Mac when a model is reached this way (nothing, structurally). Or download Velo Workspaces and try it yourself.