Skip to main content
Sandboxes run untrusted or short-lived code in an isolated microVM and capture its output, useful for agent tool-calls, REPLs, and one-off jobs. They are provided by the iii-sandbox worker:
This page is a quick tour of the sandbox worker. For the authoritative documentation, see the iii-sandbox worker docs.
You drive sandboxes by invoking the worker’s sandbox::* triggers, the same way you call any function (see Triggering functions). Images are catalog names such as python or node, not arbitrary OCI references. The examples below capture the new sandbox’s id with jq and stop the sandbox when done so nothing keeps running.

One-shot run

sandbox::run boots a VM, runs a snippet, captures its output, and stops the VM in a single call, so there is nothing to clean up.
lang accepts node, python, shell, or an interpreter path. Pass keep_sandbox=true to leave the VM running afterwards (then stop it yourself with sandbox::stop).

Lifecycle

For multi-step work, create a sandbox, operate on it with its id, then stop it. Most triggers take flat key=value arguments; only nested payloads need --json.
A whitespace-containing cmd is split into a command and its arguments. It is not a shell, so it does not expand variables or chain commands; use sandbox::run with lang=shell for that.

Catalog

sandbox::catalog::list reports the images this engine can boot (presets plus any operator-registered images). Call it when you do not already know what is available. It does not boot a sandbox, so there is nothing to stop.

Filesystem

The sandbox::fs::* triggers manipulate files inside a running sandbox. Each takes a sandbox_id plus operation-specific fields.

Moving files in and out

To copy a file between the host and a running sandbox, use the iii worker sandbox CLI: