Sandbox

When no pre-built tool fits, the agent writes code in JavaScript, SQL, or shell and runs it in the Sandbox, isolated from your real systems. The code is written for the task, executed, and the sandbox is destroyed after the run.

The agent writes code when no tool fits

Most work goes through provider tools, which are typed, named, and gated. The Sandbox covers the rest: reshape a dataset no tool reshapes, run a one-off calculation, glue two outputs together. Inside a script, sandbox runs are ops like any other, with bindings in and out.

The sandbox is isolated

Sandbox code can't reach your connected systems, and its writes stay inside the sandbox. There is nothing consequential to gate, which is why sandbox runs don't need an approval gate. When results should touch a real system, that write goes through a gated tool like any other. Timeouts are enforced; when the run ends, the sandbox is destroyed.

Every run is recorded

The code the agent wrote, what it printed, and what it returned all land in the job's trace like any tool call. You can read exactly what ran, not just what came back.

What's next

• Agents: when the agent reaches for the Sandbox.
• Scripts: sandbox runs as script ops.
• Approvals: why sandbox runs don't gate, and real writes do.

Updated 2026-08-03