Skip to main content
SandboxJobsRuntimeCapability exposes SandboxJobsApi under platform.sandbox.jobs. It runs registered, versioned Actions in an isolated Sandbox Runtime and returns validated outputs as portable Workspace Files references. Plugin callers choose only action, actionVersion, a structured payload, portable files, and declared outputs. Runtime profiles, images, commands, entrypoints, environment variables, providers, and engine options are resolved and enforced by the host. For Action Bundle packaging, queue ownership, and operational setup, also read Sandbox Jobs.

API methods

Call getActionHealth() before exposing or enqueueing an operation whose availability depends on the runtime:

Run an Action

A SandboxJobRunInput contains:
Use read-only-seekable file access only when an Action needs seekable, on-demand reads such as media decoding. materialized verifies and copies the complete file under /workspace/input before execution.

Status and progress

Persisted status is one of waiting, starting, running, succeeded, failed, cancelled, or lost. A snapshot includes the selected runtime version, Action version, attempt, provider/binding evidence, latest structured progress, validated outputs, timestamps, and any stable error code. Trusted Actions can emit structured progress using:
The SANDBOX_JOB_PROGRESS_PREFIX constant contains the required prefix. progress is normalized from 0 through 1; stage should be a stable machine-readable name.

Errors and retry policy

Failed run() calls reject with SandboxJobRuntimeError. Use isSandboxJobRuntimeError() because dynamically loaded plugins can resolve another SDK module instance and instanceof alone is not a reliable boundary.
Stable error codes cover unavailable or invalid Actions, profiles, runtimes, versions and capacity; startup and browser failures; timeout, memory, media, input and output validation failures; and cancellation. Drive retry from retryable, not from matching message text. The exported SANDBOX_JOB_ERROR_CODES list contains:
Health checks use a separate reason: ACTION_MISSING, ACTION_INVALID, PROFILE_MISSING, VERSION_MISMATCH, RUNTIME_UNBOUND, PROVIDER_UNAVAILABLE, or PROFILE_UNHEALTHY.

Operational rules

  • Run heavyweight Actions from a Managed Queue, not an HTTP handler.
  • Keep the idempotency key stable across retries of the same immutable work.
  • Put only structured JSON and portable file references into queue state.
  • Validate getActionHealth() for product availability, but still handle a later run() failure because runtime health can change.
  • Persist jobId in plugin business state when users need status, cancellation, or audit.
  • Treat returned provider, binding, runtime, and digest fields as evidence. Do not use them to choose infrastructure for the next job.