Views on a session

An Isolation session has five kinds of view: terminal, code, files, web and agent. A view is a window onto the sandbox with its own URL through the server's doorman, and each one points at this container and no other. You open views from the session screen, from a chat with /view, or from an MCP client with view_create, and the workspace remembers which ones to open at the next launch.

The five types

Terminal. Creating the view creates a tmux session in the sandbox, in the directory you chose and with the command you gave typed into it. ttyd attaches every browser tab to that one session, so two tabs show one shell, and a dev server you declared comes up whether or not anyone opens the tab.

Code. The server serves a Monaco editor itself; nothing runs inside the sandbox for it. Reads and writes go through the sandbox's file API, rooted at /workspace, with a 10 MB cap per file. The SCM panel lists what changed on the session branch, a changed file opens as a diff, and the git menu commits. Its "Open externally" menu is how you work from your own IDE.

Files. The workspace as a drive. The doorman speaks WebDAV at /v/<viewId>/mnt/<folder>/, class 2 with LOCK and UNLOCK because macOS mounts a class 1 server read-only. Authentication is HTTP Basic, the only credential a native file client has, scoped to that one view. Finder, Explorer and GNOME Files mount it with nothing installed.

Web. Nothing starts. The view names a port your app already listens on, and the doorman forwards to it. A web view is the one kind with a public address, <slug>.isolation.cc: a 20-character label, 10 characters that route to the server and 10 random ones that are the access secret. Anyone with the link can open it, which is what /share is for; deleting the view kills the address. See sharing a web preview.

Agent. One conversation with one agent from your roster, a real harness session inside the sandbox over ACP: streamed replies, tool calls, diffs, permission prompts, slash commands and modes. The transcript lives in the workspace tree at /workspace/.isolation/threads/<key>.json, keyed by the workspace-level view id, so the same window in your next session is the same chat.

How does a view reach my browser?

Every view is served by the doorman, the data plane of isolation-server, at /v/<viewId>/* on the server's private tunnel. The browser talks to the doorman and the doorman talks to the sandbox; view bytes never pass through Isolation Cloud. A browser cannot set an Authorization header on an iframe or a WebSocket, so the session screen opens each view with a view token in the query string: signed with the server's master token, valid for one view and one hour, then promoted to a cookie scoped to that view's path so later assets and WebSockets authenticate on their own. What is reachable from outside is in tunnels, the doorman and what is public.

Layouts

Your workspace definition carries defaultViews and layouts. Each default view has a stable key, so the terminal you named "server" and the agent view for Isla come back as the same windows in every session, arranged the way you left them.

Creating a view

From the session screen, Add view asks for the type and its one argument. From a chat, /view takes the type and a short form of that argument: a port for a web view, a directory for a terminal, code or files view, an agent's name for a conversation.

/view web 3000
/view terminal apps/api as "api shell"
/view agent Isla
/views

Over MCP the same action is view_create with sessionId, type (web, terminal, code, directory, agent) and url, dir, command, agent or label. view_link returns a web view's public address, view_connect the door into any other kind, view_update renames or restyles, view_delete closes. The full list is in what an external agent can do.