Why VS Code Remote is the right shape for this

VS Code Remote-SSH doesn't just open a remote terminal. It installs and runs the VS Code server, and every extension you add, inside the machine you connect to. Install Continue from a Remote-SSH window and it runs in the Linux guest, not on your Mac. Its requests to a local model then travel exactly like a CLI agent's: through the same socat proxy, across vsock, to AI Bridge on the Mac. There's no separate bridge for editors to switch on; it's the same connection described in the AI Bridge architecture post, reached from a different client.

What Velo Workspaces gives you

A running Linux workspace's Access tab includes a VS Code Remote section: step-by-step instructions and a ready-to-paste ~/.ssh/config block, named after the workspace, with a Copy button:

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

For a workspace created from a cloud image or an automatic install, the app fills in the account you created, so there's nothing to edit. For a system you installed by hand, it leaves <username> for you to replace with the account you made during the install, rather than guessing a name like "ubuntu" that wouldn't exist.

One thing to set up once: VS Code connects with your own SSH key, not the key the app keeps in the Keychain for its built-in terminal. The easiest way is to paste your public key (for example the contents of ~/.ssh/id_ed25519.pub) under SSH Public Keys when you create the workspace. Alternatively, turn on Allow SSH logins with the password, or export this Mac's key from Settings › Access and add it to the config block as an IdentityFile.

Step by step

  1. Create a Linux workspace with AI Bridge on. The quickest route is Cloud image › Ubuntu 26.04 LTS with the AI Sandbox profile, which turns AI Bridge on; on another profile, turn it on under Advanced Settings. Add your public key on the account step.
  2. Install a model server on your Mac, Ollama or MLX. The complete guide has the commands and a table for choosing a model that fits your Mac's memory.
  3. Start the workspace, open its Access tab, and copy the VS Code Remote block into ~/.ssh/config on your Mac.
  4. In VS Code on your Mac, install the Remote - SSH extension if you haven't, run Remote-SSH: Connect to Host, and pick the alias you just added.
  5. Inside that remote window, install the Continue extension. Installing it while connected puts it on the guest's side of the connection, which is the whole point.
  6. Start 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 command with your port filled in, 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. In the remote window's integrated terminal (so the file lands in the guest, not on 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 the model you pulled in step 2. Reload the window, and Continue's chat and inline-edit panels should list Local Model.

Why not point Continue at Ollama directly?

The obvious shortcut: if Ollama already runs on your Mac, install Continue in a normal VS Code window and point it at 127.0.0.1:11434. Nothing stops you, but then Continue's edits land on your Mac's real files, and anything its agent mode runs, runs there too. Going through VS Code Remote moves editing and execution into the guest instead, which is the isolation argument the AI agent security post makes for CLI agents: a bad suggestion or a command gone wrong costs you no more than closing the workspace. Inference still happens on the Mac's GPU either way. Only the editing and execution move.

A gotcha that can waste a debugging session

Switching AI Bridge's Host Provider, say from Ollama to MLX, moves the Mac-side listener immediately, but the guest's socat service still names the old port, and restarting the workspace doesn't change it. The AI researchers post covers the same gotcha for CLI agents. If Continue suddenly can't reach the model after a provider switch, run the forwarder command from the AI Bridge tab again before looking elsewhere.

Related reading: the architecture behind AI Bridge, the complete guide this adds an editor path to, what leaves your Mac when a model is reached this way, and why a headless guest is enough for a workflow that looks graphical. Or download Velo Workspaces and try it yourself.