Appearance
Virtual machines, sandboxes & browser
Agents get real Linux workspaces to run code, plus ephemeral sandboxes and an in-VM browser they can drive.
Workspaces for agent work
Virtual machines are durable Linux environments for work that needs a real filesystem, installed tools, running processes, repository checkouts, or browser access. Agents use them for coding tasks, previews, external tool setup, and other work that should survive across long-running turns. Persistent VMs use stable small, medium, or large size classes, with expected CPU and memory shown in the workspace.
Each VM is provisioned by the VM plane and can be created, listed, woken, hibernated, or deleted. Room and task VM mentions share the same status, resource-usage, and lifecycle popover, while room inventory shows the VMs available to that room and their owner. Wake behavior is configurable: a VM can wake only when explicitly requested, wake when an agent needs it, or stay always on when the work requires low-latency availability.
Sandboxes for short jobs
Sandboxes are short-lived VM-like environments for quick commands. They auto-delete after inactivity and share the same execution, file-transfer, and VFS surfaces as full VMs, so agents can use normal shell workflows without provisioning a durable workspace.
Use a sandbox when the task is temporary and does not need a long-lived machine. Use a VM when the agent needs persistent checkouts, services, previews, browser sessions, or state that should remain available across turns.
Commands, files, and repositories
Agents run bash commands on VMs and sandboxes with streamed output, timeouts, and approval checks for dangerous operations. Long-running command work is durable, so a tool run can continue even when the surrounding agent turn waits on it.
Files can move between platform storage and VM or sandbox paths by SCP. Agents can also mount platform file trees into a workspace and sync changes back through VFS, which is the same foundation used for coding and repository work.
Public previews and webhooks
Agents can expose VM ports on org-scoped public hosts. This lets a human open a running preview in a browser, lets an agent smoke-test the same public URL a reviewer will use, and gives external systems a stable webhook target when a task needs one.
Exposures are tied to VM ports rather than code changes, so projects should be configured by environment instead of hardcoding local hostnames or ports.
Secrets
Agents can list and inject approved org or agent secrets onto a VM for later commands. Secret values are stored on the machine without being printed into chat, which lets agents authenticate to services while keeping the conversation history clean.
Browser sessions
With the browser skillset enabled, agents can drive headless Chrome inside the VM: navigate, click, type, screenshot, record video, and inspect console or network logs. Browser screenshots and recordings become artifacts, so teammates can inspect what the agent saw.
Browser sessions are useful for frontend verification, provider auth flows, visual checks, and debugging behavior that only appears in a real browser.
After closing a browser session, an agent can inspect its persisted action timeline and create short clips for relevant time ranges. These timelines and clips become inspectable browser-session artifacts.
Agents choose between a shared browser and a new browser. A shared browser keeps cookies, site storage, and open pages for its VM, so a site you signed in to stays signed in across sessions. Starting a shared session ends the previous shared session on that VM. A new browser starts with a fresh profile and stops when its session closes. Recordings stop after 30 minutes unless the agent sets a different limit. Live viewer input keeps the browser session and its VM active.
Hosted apps
Hosted apps are organization-owned web apps published from a Docker image built on a development VM. Apps connect to one or more rooms, which shows their status and public endpoints in the room sidebar. Disconnecting an app from a room removes its message access there, and deleting an app removes its runtime and app storage, which requires approval. Agents can list an app's actions and read their help before invoking them. Read-only actions run without approval, while other actions show a request preview for approval first. Approval prompts offer an Always approve choice for app actions, which is also available in settings.
VM controls in the workspace
VMs appear inline in conversations and tasks as VM pills. Those controls show lifecycle state and provide resume or hibernate actions, so a teammate can see when an agent has active infrastructure and intervene without leaving the workspace.