Work from your IDE
Open a session in VS Code, Cursor, Windsurf or Zed, ssh to ssh.isolation.cc, scp, port-forward, mount its files as a drive, or join the agent chat.
You open an Isolation session in VS Code, Cursor, Windsurf or Zed from the code view's "Open externally" menu, and the editor drives an ssh connection into the sandbox for you. The same ssh door takes a plain terminal, scp and port forwards; the files view mounts as a drive; an agent view can be joined from a terminal. Nothing is installed on your machine for any of them, and no password is ever typed: the bastion at ssh.isolation.cc checks the public keys on your SSH credential at the edge and jumps inward on its own key.
A local editor over ssh
Open the code view's options menu and pick an editor. Each pick shows one link that your browser hands to the OS, and the link is shown next to the button so you can copy it and send it to another machine. VS Code, Cursor and Windsurf share one shape; the route id in it is the ssh username, and ?windowId=_blank makes VS Code open a new window instead of taking over one you had open.
vscode://vscode-remote/ssh-remote+<routeId>@ssh.isolation.cc/workspace?windowId=_blank
cursor://vscode-remote/ssh-remote+<routeId>@ssh.isolation.cc/workspace?windowId=_blank
windsurf://vscode-remote/ssh-remote+<routeId>@ssh.isolation.cc/workspace?windowId=_blank
Zed documents its own scheme, and it is the fourth item of the same menu.
zed://ssh/<routeId>@ssh.isolation.cc/workspace
The editor uploads its own server into the sandbox over that ssh and speaks its protocol across it, so the code view's route is a transparent shell. It is the only route that carries exec, sftp and -L, which is why the commands below all use a code view's route.
A terminal
Every terminal view has an ssh line, shown by its "Connect" menu, by /ssh in a chat, or by view_connect over MCP. The username is the route id, and the route already says what it opens: a terminal's route attaches the very tmux session the browser is showing, so your local terminal and the browser tab are two windows on one shell.
ssh <routeId>@ssh.isolation.cc
Copying files with scp
Copy in either direction with the route of a code view. The session's sshd has the sftp subsystem, which modern scp and VS Code Remote both need.
scp ./fixture.json <routeId>@ssh.isolation.cc:/workspace/test/
scp <routeId>@ssh.isolation.cc:/workspace/build/report.html .
Forwarding a port
Reach a port inside the sandbox on localhost without publishing a web view. A database on 5432 or a dev server you do not want public stays private this way.
ssh -L 5432:localhost:5432 <routeId>@ssh.isolation.cc -N
The files view as a drive
A files view is a WebDAV mount served by the doorman, so its door is not ssh at all: plain HTTPS on the address the view plane already answers on. "Connect" on the view, /connect in a direct message, or view_connect gives you the address, a username and a password. The password belongs to that window and lasts as long as it does, which is why a chat only hands it out in a direct message. The address ends in the folder's name, because every desktop names the drive after that segment.
macOS Finder, press Command-K, paste the address, Enter
https://<user>:<password>@<server>/v/<viewId>/mnt/<folder>/
Windows File Explorer, Map network drive, tick "Connect using different credentials", paste the address
Linux gio mount 'davs://<user>@<server>/v/<viewId>/mnt/<folder>/'
The mount is read-write.
Joining the agent's conversation from a terminal
An agent view is one conversation with one agent, and its ACP bridge fans out to any number of clients. ssh -s asks for the acp subsystem on that view's route: you land in the same thread the session screen is showing, live in both directions, and quitting ends only your connection. What you type appears in the browser and the reply streams to both.
ssh -s <routeId>@ssh.isolation.cc acp
The conversation is stored in the workspace tree and outlives the session; see memory and conversations.
Letting a key in
Launch authorizes the public keys on your account. A laptop whose key is not on the account gets in without a restart: /allow-key <public key> (the ssh_key_authorize action) writes it to the running sandbox in seconds, the grant is this session's only and disappears with it, and /keys (ssh_keys) lists every authorized key by fingerprint and origin. Whoever holds the matching private key gets a shell, so treat it as handing over access.
Every one of these doors ends at the doorman or the bastion on the server's side, never at Isolation Cloud: bytes go from your machine to the server to the sandbox. What that means for what is public is in tunnels, the doorman and what is public.
Questions
Do I need to install anything to ssh into a session?
No. The session's sshd sits behind the bastion at ssh.isolation.cc, and your ssh client talks to it directly. There is no agent, no ProxyCommand and no cloudflared on your machine.
Which key opens the session?
The public keys on your account's SSH credential are authorized at launch. On a running session, /allow-key <public key> authorizes one more in seconds with nothing restarting; /keys lists them by fingerprint.
Does the ssh address change when the session restarts?
No. The route id in the username is stable for the life of the session, across restarts of the server, the tunnel and the session's own container.