Skip to main content

SandboxEnv

Environment for executing commands in isolated Docker containers using Prime Sandboxes.

Overview

SandboxEnv provides isolated container execution with:
  • Container isolation: Each rollout gets its own Docker container
  • Resource control: Configurable CPU, memory, disk, and GPU allocation
  • Persistent containers: Containers persist across multiple commands within a rollout
  • Automatic cleanup: Containers are destroyed after rollout completion
  • Retry logic: Built-in exponential backoff for transient failures

Inheritance

Constructor

Parameters

str
default:"sandbox-env"
Name prefix for created sandboxes.
str
default:"python:3.11-slim"
Docker image to use for the sandbox container.
str
default:"tail -f /dev/null"
Command to run when the container starts. Use tail -f /dev/null to keep container alive for interactive commands.
int
default:"1"
Number of CPU cores to allocate.
int
default:"2"
Memory allocation in GB.
int
default:"5"
Disk space allocation in GB.
int
default:"0"
Number of GPUs to allocate.
int
default:"60"
Maximum lifetime of the sandbox container in minutes.
int
default:"30"
Timeout for individual command executions.
dict[str, str] | None
Environment variables to set in the container.
str | None
Prime Sandboxes team identifier.
AdvancedConfigs | None
Advanced sandbox configuration options from prime-sandboxes.
list[str] | None
Labels to attach to the sandbox for organization.
int
default:"5"
Maximum number of retry attempts for sandbox operations.
float
default:"0.5"
Initial delay in seconds for exponential backoff.
float
default:"2.0"
Multiplier for exponential backoff delays.
float
default:"30.0"
Maximum delay between retries.
float
default:"1e-3"
Random jitter added to retry delays to prevent thundering herd.
list[type[Exception]] | None
default:"[vf.SandboxError]"
Exception types that should stop the rollout immediately.
int
default:"50"
Maximum number of worker threads for sandbox client.
int
default:"100"
Maximum number of HTTP connections.
int
default:"50"
Maximum number of keepalive HTTP connections.
All other parameters are inherited from StatefulToolEnv.

Tools

bash

Execute a bash command in the sandbox container.
str
Bash command to execute.
str | None
Working directory for command execution. Defaults to container’s default directory.
Returns: str - Combined stdout and stderr output. Output format:
  • stdout content
  • stderr content prefixed with “stderr:” (if any)
  • (no output) if command produced no output
  • Error: Command timed out after Ns on timeout
The sandbox_id and sandbox_state parameters are hidden from the model and injected automatically via update_tool_args().

Core Methods

setup_state

Create a sandbox container for this rollout. Override to customize initialization. State keys added:
  • state["sandbox_id"]: Unique sandbox identifier
  • state["sandbox_state"]: Sandbox metadata (ready status, timing)

get_sandbox_request

Return the sandbox creation request for this rollout. Override to customize per-state configuration.
vf.State
Current rollout state.
Returns: CreateSandboxRequest - Sandbox configuration.

post_rollout

Run custom logic after rollout completes but before sandbox destruction. Override to cache results from the sandbox into state.
vf.State
Final rollout state (can be modified).

update_tool_args

Inject sandbox_id, sandbox_state, and working_dir into bash tool calls. Implemented by SandboxEnv.

Cleanup Methods

destroy_sandbox

Delete the sandbox after rollout completion. Runs automatically as a cleanup handler.

teardown_sandboxes

Delete all remaining sandboxes during environment shutdown. Runs automatically on exit.

bulk_delete_sandboxes

Delete multiple sandboxes by their global IDs in a single operation.
list[str]
List of sandbox IDs to delete.

State Management

SandboxEnv adds sandbox-specific state:

Built-in Rubric

SandboxEnv includes SandboxMonitorRubric which tracks:
  • sandbox_ready_wait_time: Time spent waiting for sandbox creation
  • sandbox_command_execution_time: Average command execution time

Example Usage

Basic File Operations

Custom Docker Image

With Environment Variables

GPU-Enabled Sandbox

Custom Start Command

Per-Task Sandbox Configuration

Caching Sandbox Results

With Retry Configuration

Error Handling

Error Types

  • SandboxCreationError: Failed to create sandbox
  • SandboxNotReadyError: Sandbox failed to become ready
  • vf.SandboxError: Base class for sandbox errors
All inherit from vf.SandboxError which is included in stop_errors by default.

Command Timeouts

Commands that exceed timeout_per_command_seconds return an error message:
The timeout is logged but does not raise an exception, allowing the model to retry or adjust.

Implementation Details

Lazy Initialization

Sandboxes are created during setup_state() but initialization is lazy:
  1. Container creation is queued asynchronously
  2. First bash() call awaits container readiness
  3. Subsequent calls execute immediately
This overlaps provisioning with other rollout setup.

Cleanup Guarantees

Sandboxes are cleaned up via multiple mechanisms:
  1. @vf.cleanup handler runs after each rollout
  2. @vf.teardown handler runs on environment shutdown
  3. Sandboxes auto-destroy after timeout_minutes

Bulk Operations

Use bulk_delete_sandboxes() to delete multiple sandboxes efficiently:
Batches of up to 100 sandboxes are deleted per API call.

When to Use

Use SandboxEnv for:
  • Code execution in isolated environments
  • System administration tasks
  • File system operations
  • Multi-language environments
  • Security-sensitive operations
Use PythonEnv for:
  • Python-specific REPL workflows
  • Persistent Python state across executions
  • Scientific computing tasks
Use StatefulToolEnv directly for:
  • Non-sandbox stateful resources (databases, APIs)
  • Custom state injection patterns

See Also