execute is the Harness's whole compute surface, reached through the call verb:

execute {runtime: 'ts' | 'python' | 'shell', code: string, timeout_secs?: number}
  → {summary, exitCode, success, stdout, stderr, truncated, durationMs,
     changedFiles: [{path, change: 'added' | 'modified' | 'removed'}]}

Code runs in hardware-isolated microVMs (microsandbox — libkrun on macOS and Linux, WHP on Windows). Per-call resource sprawl is deliberately collapsed into service configuration: the model chooses what to run; the operator decides where and how big (Operations).

The three runtimes

Each is exactly one argv command — bun -e, python -c, sh -c — so nothing is shell-quoted unless the runtime is the shell. TypeScript runs in its own image (default oven/bun) beside the Python image, and the contract the model reads lists only the runtimes this server can actually run: with no TypeScript image configured, ts is not advertised rather than advertised and broken.

Sandboxes are .security('restricted') and .ephemeral(true), default 1 vCPU and 512 MiB, with network egress restricted to public destinations — private, link-local, and metadata addresses are blocked — or disabled entirely by configuration. A requested timeout is clamped to 300 seconds, and the sandbox's own lifetime is that plus 30 seconds of grace, so a hung guest is reaped rather than lingering. stdout and stderr are each bounded at 64 KiB.

There is no separate file-passing protocol: /workspace is the agent's Memory, bind-mounted, so inputs arrive and outputs leave through ~/memory files.

Lambdas: authored tools become callable

An agent-authored tool document with source is a lambda. Calling one runs a three-step pipeline:

Validate the input against the lambda's own schema — outside the VM, so malformed input never boots a sandbox.

Execute the stored source. TypeScript is imported as a data:text/typescript;base64,… module rather than written to the sandbox filesystem, and the return value rides a single marked stdout line (__SEED_TOOL_RESULT__) so everything else the code prints stays usable as logs.

Validate the output against the lambda's output schema before it reaches the caller.

Author → test → save flows entirely through write and call. And a lambda call requires the same execute grant its runtime needs — authoring a tool is not a way around an owner who turned code execution off (Agents and Grants).

Scripts are not execute

Orchestration scripts spawned by delegate run in a different engine: deterministic QuickJS with a journaled effect log, built for replay and parking, not for compute. The two engines split the work: scripts orchestrate, microVM code computes. A script that needs real computation calls execute (or a lambda) as one of its journaled effects.

Availability is reported, not assumed

Code execution can be unavailable — no backend configured, no runtime staged, a container image without the sandbox binaries. The health endpoint reports codeExec with a reason and a code, and the tool simply is not offered when it cannot run. One deployment caveat worth knowing: the published Docker images cannot execute code today, because the final image stage omits the node_modules that carry the sandbox runtime.

Tools as Documents — lambdas and grants

Memory — /workspace semantics

Security · Operations

The three runtimes

Lambdas: authored tools become callable

Scripts are not execute

Availability is reported, not assumed

Related