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:- Creates a new isolated sandbox environment (or resumes an existing one)
- Provisions the sandbox with necessary runtime tools and capabilities
- Executes your agent’s tasks within the isolated environment
- Persists the sandbox state for future requests in the same session
- Pauses the sandbox after 5 minutes of inactivity to save resources
- 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
Reuse Sessions for Related Tasks
Reuse Sessions for Related Tasks
Use New Sessions for Unrelated Tasks
Use New Sessions for Unrelated Tasks
Store Session IDs for Long-Running Workflows
Store Session IDs for Long-Running Workflows
Resource Optimization
Error Handling
Handle sandbox-related errors gracefully:Integration with Other Primitives
With File System
Sandboxes provide the execution environment for file operations:With Computer
Sandboxes host the full Linux computer environment:With Browser
Browser automation runs within the sandbox:With Sessions
Sessions manage sandbox lifecycle and persistence: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
Troubleshooting
Common Issues
Session Not Found
Session Not Found
Problem: Session expired or invalidSolution: Create a new session or verify session ID
Disk Space Exceeded
Disk Space Exceeded
Problem: Sandbox reached 10GB storage limitSolution: Clean up large files or start new session
Slow Performance
Slow Performance
Problem: Sandbox running slowSolution: Check mode selection and resource usage
Related Primitives
File System
Persistent storage within sandboxes
Computer
Full Linux environment inside sandboxes
Browser
Web automation within sandboxes
Sessions
Session management and persistence