Sandbox API
The nemo_gym.sandbox module is the provider-neutral interface for creating isolated execution environments, running commands, and moving files in or out of those environments. Agents and resources servers call the same API while provider pages document backend-specific setup, configuration, and isolation properties.
Import caller-facing APIs from the public package boundary:
Treat nemo_gym.sandbox as the stable caller-facing API. Provider modules under nemo_gym.sandbox.providers are implementation details unless you are adding or configuring a provider.
Run sandboxes through an OpenSandbox server and SDK.
provideropensandboxRun sandboxes as local Apptainer instances on a host or HPC node.
providerapptainerImplement the SandboxProvider protocol and register a new runtime backend.
Install Provider Dependencies
The public API is part of nemo-gym. Runtime backends can have optional dependencies, so install the extras or system packages required by the provider you configure in your agent or resources server.
Core Types
First-Run Example
Create a small local script after your provider is available. Replace the provider name and settings with the backend configured for your environment.
Run it from your local checkout or application environment:
exec() returns a SandboxExecResult. Nonzero process exits are reported in return_code; providers should reserve exceptions for sandbox runtime failures such as allocation, transport, or lifecycle errors.
Provider Config Blocks
Agents can refer to a named provider block instead of embedding provider credentials or backend settings in the agent config. The sandbox_provider field names a top-level config block, and that block contains exactly one provider key plus optional reserved keys:
The agent then references that block by name:
Every provider config can bind the same name, such as sandbox, so swapping backends is swapping the provider config path passed to gym env start. If one run needs multiple sandboxes, give each block a distinct name and reference each one separately.
default_metadata is merged into SandboxSpec.metadata before create. The agent’s own sandbox_spec.metadata wins on key conflicts.
The helpers used by agents are public:
Inline single-key mappings are also accepted when a caller does not use Hydra config:
Lifecycle
AsyncSandbox and Sandbox are lifecycle objects. Construct one with a provider config and optional SandboxSpec, call start(), run commands or transfer files, then call stop(). Context managers close the provider on exit, but they do not start the sandbox automatically.
Sync vs. Async
Use AsyncSandbox inside FastAPI handlers, async resources servers, async agents, and rollout collection code.
Use Sandbox only in synchronous code, such as a third-party harness adapter that does not expose async hooks.
Do not call Sandbox from FastAPI handlers, async resources servers, or async agents. It blocks the caller by design. Use AsyncSandbox in async code.
SandboxSpec Fields
SandboxSpec is intentionally provider-neutral. Providers map these fields onto their own runtime primitives.
You can pass resources as either a SandboxResources instance or a mapping:
Unknown resource keys raise a ValueError, which catches config drift early.
Startup Files and File Transfer
Use files for small text files that should exist before the first command runs:
Use upload() and download() for local files:
upload() and download() operate on files. If you need structured values, serialize them locally before uploading and parse the downloaded file locally after the sandbox command completes.
Status and Cleanup
Call status() when a runner needs to distinguish a stopped sandbox from a provider error:
Always stop sandboxes in cleanup paths. stop() is idempotent on the public facade and closes provider-scoped resources after ending the sandbox lifecycle.
Image Rewrites
Use rewrite_image() when a benchmark’s upstream image needs to run through an internal registry mirror.
Rewrites are ordered. The first matching from prefix wins.
Error Handling
Sandbox create failures use provider-neutral exception classes:
SandboxCreateErrorfor sandbox allocation or readiness failures.SandboxCreateVerificationErrorwhen a created sandbox fails Gym readiness verification.
In resources servers and agents, catch these errors close to the sandbox operation and return a meaningful verifier or rollout error. Do not let one bad sandbox allocation crash a long-running server.