How to open a cloud sandbox in VS Code with Remote-SSH

Run runtime sandbox ssh config --install once, then in VS Code run Remote-SSH: Connect to Host and enter <id>.runtime.

On Runtime the editor connects through Runtime's API with your key, so the sandbox opens no SSH port to the internet and there is no key to copy onto it. The machine behind the window is a Firecracker microVM with its own kernel, running Ubuntu 24.04 with Python 3.12, Node.js 24, Bun, git and a compiler, and sudo for anything else. A 2 vCPU, 4 GiB sandbox costs $0.03125 an hour while you read code and $0.08 an hour with both CPUs busy (pricing), and an idle pause stops the compute charge while you are away.

Connect

On your own machine, once:

Terminalnpm install --global withruntime        # the runtime CLI; or use npx withruntimeruntime sandbox ssh config --install    # every sandbox becomes the host <id>.runtime

Then in VS Code:

1. Install the Remote - SSH extension.
2. Open the Command Palette and run Remote-SSH: Connect to Host....
3. Enter <id>.runtime or <name>.runtime.
4. Open /workspace, the sandbox user's home, with File > Open Folder.

The command writes a Host *.runtime entry and includes it from ~/.ssh/config, which is the file Remote-SSH reads unless its remote.SSH.configFile setting names another. VS Code then installs its own server in the sandbox, and most extensions run there, next to the code (VS Code docs, read 25 September 2026). The sandbox image is Ubuntu 24.04 for amd64, a glibc-based x86_64 system of the kind VS Code lists as supported.

A workspace that waits for you

A sandbox made with a name and an idle pause is the same machine every time:

TypeScriptimport { Sandbox } from "withruntime";const dev = await Sandbox.getOrCreate("dev", { idlePauseSeconds: 900, diskMiB: 16_384 });await dev.exec("mkdir -p /workspace/app");console.log(`${dev.info.name}.runtime`); // the host to enter in VS Code

Pythonfrom withruntime import Sandboxdev = Sandbox.get_or_create("dev", idle_pause_seconds=900, disk_mib=16_384)dev.exec("mkdir -p /workspace/app")print(f"{dev.info['name']}.runtime")  # the host to enter in VS Code

Terminalruntime sandbox create --name dev --get-or-create --idle-pause 900 --disk 16384

After 15 minutes with no request it pauses, keeping its files, memory and running processes. Connecting again wakes it, as any command does.

Settings that matter

Mistakes and how Runtime handles them

• The window disconnects after a while. An open connection does not keep a sandbox running. When its lease pauses or stops it, VS Code loses the host. Extend the lease, or use --persistent for a workspace you keep open all day.
• Reconnecting after a day. A session lasts at most 24 hours; reconnect to go on.
• Many windows at once. An organization has at most 16 SSH logins and port forwards open at the same time.
• A host key prompt. The installed entry skips host key checks on purpose: each login gets a fresh host key, and the connection already goes to the sandbox you named through Runtime's authenticated API.
• A custom image with no SSH server. The first connection installs openssh-server once.
• Previewing the app you are building. VS Code's Forward a Port works over the same connection; for a link to share, create a preview.

VS Code, JetBrains or the terminal?

All three use the same <id>.runtime host. VS Code puts the editor on your machine and its server in the sandbox. JetBrains Gateway runs the whole IDE backend in the sandbox. A plain SSH session needs nothing but the CLI.

Related

• SSH and editors.
• Per-user dev environments.
• Pause and resume a sandbox.

Sources

• Visual Studio Code, "Remote Development using SSH", https://code.visualstudio.com/docs/remote/ssh, read 25 September 2026.

Facts on this page were checked on 25 September 2026.