Skip to main content
Each agent session runs in its own isolated sandbox environment, providing security, resource isolation, and clean state management.

Overview

The Sandbox primitive is the foundation of Agentbase’s execution model. Every agent session operates within its own isolated sandbox - a lightweight, secure container that provides a clean execution environment. This isolation ensures that:
  • Security: Agent operations are contained and cannot affect other sessions or the host system
  • Resource Isolation: Each sandbox has dedicated CPU, memory, and disk resources
  • Clean State: Every new session starts with a fresh environment
  • Predictable Execution: Consistent runtime conditions across all sessions

Automatic Creation

Sandboxes are created automatically when you run an agent - no manual setup required

Session-Based

Each sandbox is tied to a session ID and can be reused across multiple requests

Resource Managed

Automatic resource allocation and cleanup based on workload requirements

Network Enabled

Full internet access for API calls, package downloads, and web interactions

How Sandboxes Work

When you make an agent request, Agentbase automatically:
  1. Creates a new isolated sandbox environment (or resumes an existing one)
  2. Provisions the sandbox with necessary runtime tools and capabilities
  3. Executes your agent’s tasks within the isolated environment
  4. Persists the sandbox state for future requests in the same session
  5. Pauses the sandbox after 5 minutes of inactivity to save resources
  6. Cleans up the sandbox automatically when no longer needed
Session Continuity: Use the same session ID to reuse a sandbox and maintain state across multiple agent requests.

Sandbox Architecture

Isolation Layers

Agentbase sandboxes use multiple layers of isolation:

Security Boundaries

Each sandbox provides:
  • Process Isolation: Separate process namespaces prevent cross-contamination
  • File System Isolation: Dedicated filesystem with controlled access
  • Network Isolation: Outbound internet access with security policies
  • Resource Limits: CPU, memory, and disk quotas to prevent resource exhaustion

Code Examples

Basic Sandbox Usage

Reusing a Sandbox

Maintain state across multiple requests by reusing the same session:

Sandbox with Custom Modes

Different modes affect sandbox resource allocation:

Sandbox Lifecycle

Creation

Sandboxes are created automatically on the first request:

Persistence

Sandboxes remain active and persist state:

Auto-Pause

After 5 minutes of inactivity, sandboxes automatically pause:
  • Files preserved: All files and data remain intact
  • Packages preserved: Installed packages stay installed
  • Resume on next request: Automatic resume when session is reused

Cleanup

Sandboxes are automatically cleaned up after extended inactivity or when explicitly terminated.

Use Cases

1. Development Workflows

Create and test code in an isolated environment:

2. Data Processing

Process sensitive data in isolated environments:

3. Multi-Step Tasks

Maintain state across multiple steps:

4. Testing and Experimentation

Safe environment for testing code:

Best Practices

Session Management

Resource Optimization

Mode Selection: Use flash mode for simple tasks, base for standard workloads, and max only when you need advanced reasoning capabilities. This optimizes both cost and performance.

Error Handling

Handle sandbox-related errors gracefully:

Integration with Other Primitives

With File System

Sandboxes provide the execution environment for file operations:
Learn more: File System Primitive

With Computer

Sandboxes host the full Linux computer environment:
Learn more: Computer Primitive

With Browser

Browser automation runs within the sandbox:
Learn more: Browser Primitive

With Sessions

Sessions manage sandbox lifecycle and persistence:
Learn more: Sessions Primitive

Performance Considerations

Startup Time

  • Cold Start: First request creates sandbox (~2-5 seconds overhead)
  • Warm Start: Subsequent requests in same session are instant
  • Resume from Pause: Paused sandboxes resume quickly (~1-2 seconds)

Resource Limits

Each sandbox has resource quotas:
  • CPU: Shared allocation based on mode
  • Memory: 2GB for flash/base, 4GB for max mode
  • Disk: 10GB persistent storage per session
  • Network: Unlimited bandwidth with rate limiting

Optimization Tips

Batch Related Tasks

Group related operations in a single session to minimize sandbox creation overhead

Preload Dependencies

Install packages once and reuse the session for multiple tasks

Clean Up Files

Remove large temporary files to stay within disk limits

Monitor Session Time

Complete work within 5 minutes to avoid auto-pause overhead

Security Features

Isolation Guarantees

Sandboxes provide strong isolation:
  • No Cross-Session Access: Sandboxes cannot access files or processes from other sessions
  • Network Security: Outbound connections only, no inbound access
  • Process Isolation: Separate kernel namespaces for each sandbox
  • Resource Protection: Quotas prevent resource exhaustion attacks

Data Privacy

Security Best Practices

Sensitive Data: While sandboxes provide isolation, avoid storing long-term sensitive credentials in sandbox files. Use environment variables or secure parameter passing instead.

Troubleshooting

Common Issues

Problem: Session expired or invalidSolution: Create a new session or verify session ID
Problem: Sandbox reached 10GB storage limitSolution: Clean up large files or start new session
Problem: Sandbox running slowSolution: Check mode selection and resource usage

File System

Persistent storage within sandboxes

Computer

Full Linux environment inside sandboxes

Browser

Web automation within sandboxes

Sessions

Session management and persistence

Additional Resources

API Reference

Complete API documentation

Persistence Guide

Understanding state management

Best Practices

Production deployment patterns
Remember: Sandboxes are created automatically and managed transparently. Focus on your agent’s tasks, and Agentbase handles the infrastructure.