Sandboxes and desktop
The isolated Linux workstation a run executes in, the provider behind it, warm pools, the visible desktop, and how a run survives a backend restart.
Work runs inside an isolated sandbox, not in the backend process. The backend drives the sandbox from outside and records everything it observes.
Sandbox
The isolated Linux workstation where agent commands, repositories, browser
automation, desktop apps, and recordings run. A thread gets one sandbox and one
working directory, retained and reused across its runs: the lease checks
liveness and required labels before reuse and re-provisions when the retained
sandbox is stale (backend/src/engines/thread-sandbox.ts). A run executes
inside its thread’s sandbox.
Sandbox provider
A vendor-specific implementation selected behind a provider-neutral sandbox contract. Daytona and Cube expose the same required process, filesystem, PTY, preview, and lifecycle boundary, then keep provider-specific behavior and tests for native capabilities. Code above the contract does not branch on the provider.
Warm pool
Prepared sandboxes kept ready so a new run avoids most cold-start work. Warm-pool claimable creation and parallelized post-sandbox preparation are part of the turn-start latency effort.
Desktop
The visible XFCE and Chromium workstation shown through noVNC. Readiness is strict: it requires the noVNC page, RFB, XFCE, browser CDP, and both CDP relays. Daytona can drive the desktop natively, while Cube uses trusted X11 controls. An engine controls it through the desktop computer-use tools, and desktop recording publishes a real MP4 artifact.
Restart reconciliation
Because the sandbox runs independently of the backend, a backend restart does not kill a live run:
The sandbox keeps executing
The engine process inside the sandbox is unaffected by a backend bounce.
A recovery loop re-probes
On restart, a background loop finds the in-flight session and streams the interim provider events into the timeline with a visible heartbeat.
The real result is adopted
The recovered run adopts the finished result, or fails honestly at a bounded deadline, rather than discarding work that actually completed.
The sandbox lane never stops: the one-shot boot pass (runs/recovery.ts) settles the commands mailbox, then the adaptive loop (recovery.ts, index.ts) re-probes every 15s with run.reconciling heartbeats until it adopts the real result or fails honestly at the bounded deadline.