Views on a session

An Isolation session has four kinds of view: terminal, editor, display 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 four 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.

Editor. One folder of the workspace (the whole of /workspace unless you name one), in three modes you switch between with the column at its left edge (a row on top on a phone, and keys 1 2 3 in the terminal client):

• Code: the explorer and a Monaco editor. Reads and writes go through the sandbox's file API, with a 10 MB cap per file.
• Changes: what changed in each repository under the folder, a changed file as a diff, and commit, push and pull.
• Files: a file manager. Browse with previews, upload and download (a folder downloads as a .tar.gz), copy, move, rename, delete and make folders. On an editor of the whole workspace it also reaches the sandbox user's home.

The server serves the editor itself; nothing runs inside the sandbox for it. The mode you picked is remembered by your browser or app, not by the session. Its "Open externally" menu is how you work from your own IDE.

Display. What a display shows is its kind. The default kind is web: nothing starts, the view names a port your app already listens on, and the doorman forwards to it. You open it in your browser on its own private link, <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. Kind api is the same link, for an API. See sharing a preview.

Device and window displays are coming to Cloud Servers: an Android emulator (android), an iPhone, iPad, Watch or TV simulator (apple-device), or one Mac app window (apple-window). They are drawn live on the session screen, with touch and keys, and have no public link. Android needs a sandbox type with nested virtualization, and the Apple kinds need a macOS sandbox.

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 display, a directory for a terminal or an editor, an agent's name for a conversation.

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

Over MCP the same action is view_create with sessionId, type (display, terminal, editor, agent) and url, dir, command, agent or label. A display also takes kind (web by default, or api), and port and target for a device or window display.

{ "sessionId": "<session>", "type": "display", "kind": "web", "url": "http://localhost:3000" }

In the workspace definition the same view is stored as { "type": "display", "url": "http://localhost:3000", "display": { "kind": "web" } }; a device or window display carries display: { kind, port, target } instead of a url. view_link returns a web or api display'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.