Sandbox Configuration & Settings

The Sandboxes page shows all sandbox instances associated with the project, along with their current status, resource allocation, and lifecycle history.

Sandboxes are isolated Linux compute environments backed by TDX (confidential compute) infrastructure. Each sandbox gets dedicated CPU, memory, and disk resources and runs in a confidential compute environment tied to your project.

What a Sandbox Is Used For

Every time you open a workspace, run a task, or have an agent execute commands on your behalf, that work happens inside a sandbox, not on your local machine. The sandbox is the environment in which your project's code is cloned, dependencies are installed, and the agent's shell commands actually run.

Common use cases include:

• Running agent tasks safely — when an agent runs npm install, pytest, a migration script, or a long-running build, it executes inside the sandbox. If a command misbehaves (deletes files, eats memory, opens an unexpected port), the blast radius is the sandbox, not your laptop or shared infrastructure.
• Reproducible build environments — every workspace starts from the same base image with the same CPU/RAM/disk allocation, so a task that works for one teammate works the same way for another. No "works on my machine" drift.
• Confidential workloads — because sandboxes run on TDX-backed nodes, code and data inside the sandbox are protected by hardware-level memory encryption. This matters when the project handles customer data, proprietary algorithms, or unreleased product code that should not be visible to the host operator.
• Parallel workstreams — multiple sandboxes can run concurrently for the same project (for example, one workspace running the test suite while another is debugging a feature branch). Each entry in Workspace History corresponds to one such run.

Example: lifecycle of a sandbox

A typical flow looks like this:

1. A teammate creates a new workspace on the project. ORGN provisions a fresh sandbox on the sandbox-c3-44 pool — say, sandbox-88f2ce00 with 4 cores / 8 GB / 50 GB.
2. The repo is cloned inside the sandbox, dependencies install, and the agent picks up the task.
3. The teammate hands off for the day and closes the workspace. The sandbox moves to Archived and stops accruing compute cost, but its entry remains in Workspace History for audit and spend tracking.
4. Two weeks later the underlying infrastructure rotates and the archived instance is garbage-collected from Daytona. The history row now displays the Unknown state with the "Sandbox no longer exists in Daytona" note — the ORGN record is preserved, only the dormant compute artifact is gone.

Workspace History

All sandbox instances for the project are listed under Workspace History. The top-right of the section shows the total spend and total number of workspaces created for the project (for example, $10.00 · 5 workspaces).

Each entry shows:

• Instance name: a short identifier such as trial-a913393f or sandbox-88f2ce00
• UUID: the full unique identifier for the instance
• Status badge: the current state of the sandbox:
  • Running: the sandbox is active
  • Archived: the sandbox has been stopped and archived
  • Unknown: the instance record exists in ORGN but the sandbox no longer exists in the underlying Daytona infrastructure
• TDX Sandbox badge, confirms the instance ran on TDX-backed confidential infrastructure
• Resource allocation: CPU cores, memory, and disk shown for the instance (for example, 4 cores / 8 GB / 50 GB)

"Sandbox no longer exists in Daytona"

Some entries may show a warning: Sandbox no longer exists in Daytona. This means ORGN has a record of the sandbox but it has been removed from the underlying compute layer. The entry is kept in history for cost tracking and audit purposes. No action is required.

Infrastructure

Sandboxes run on a pool of nodes with the following allocation per node:

• 44 vCPUs
• 176 GiB RAM
• 750 GB storage

Three node pools back sandbox operations:

• sandbox-c3-44: where sandboxes execute (scales 1–110 nodes, Ubuntu 24.04 LTS)
• control-tdx: fixed 3-node control plane
• tdx-us-central1: general-purpose workloads (scales 1–5 nodes)

A single node hosts multiple sandboxes side-by-side — the per-node allocation above is the upper bound that the pool can hand out, not the size of any individual sandbox. A typical project sandbox is provisioned with 4 cores / 8 GB / 50 GB, which is why you can have many workspaces open in parallel without exhausting the pool.

When demand spikes (for example, a team kicks off a dozen agent tasks at once), the sandbox-c3-44 pool scales up additional nodes automatically and scales back down when those workspaces are archived. You don't need to provision capacity manually.

Viewing Sandboxes in OLLM

Sandboxes created in ORGN are also visible in the OLLM console. The OLLM view surfaces organisation-wide metrics including total sandboxes created, cumulative compute minutes, daily creation counts, and current resource utilisation across CPU, RAM, and storage.

Individual sandbox entries show the sandbox ID, resource allocation, creation timestamp, status, regional location, and an operational timeline. This view is for monitoring only, sandboxes cannot be created, modified, or deleted from the OLLM console.