Local Environment (Primary Support)
Only Supported Environment: According to the current schema, only ‘local’ execution is supported. The environment field only accepts the string ‘local’, not an object.
Characteristics
✅ Fully supported and actively maintained- Fast execution with no container overhead
- Direct file system access to your project
- Simple setup with no additional dependencies
- Native performance for all tool operations
Use Cases
Local execution is ideal for:- Development and testing environments
- Trusted environments where security isolation isn’t critical
- Performance-critical applications requiring minimal overhead
- Simple deployments without container infrastructure
Setup
No additional setup required beyond installing the SDK:Docker Environment (Limited Support)
Limited Support: While the Docker execution adapter exists and may work, it’s not currently the development team’s priority. Use with caution and expect potential issues.
Characteristics
🔒 Isolated execution environment- Consistent runtime across different systems
- Security isolation from the host system
- Reproducible environments for testing
- Slower startup due to container initialization
- Additional complexity in setup and maintenance
- Resource overhead from containerization
Use Cases
Docker execution might be suitable for:- Security-sensitive environments requiring isolation
- Multi-tenant applications with untrusted code
- Consistent deployment environments across teams
- Testing scenarios requiring clean environments
Setup Requirements
Docker execution requires additional setup:- Docker Installation: Ensure Docker is installed and running
- Container Configuration: Set up appropriate Docker images
- Volume Mounting: Configure project directory access
- Network Configuration: Set up container networking if needed
Remote Environment (Limited Support)
Limited Support: The remote execution adapter (E2B integration) exists but is not actively maintained. Current schema restrictions only allow local execution.
Characteristics
☁️ Cloud-based execution in managed sandboxes- Maximum isolation from your local system
- Scalable infrastructure managed by the provider
- Consistent environments across different clients
- Network dependency for all operations
- Latency overhead for tool execution
- External service dependency on cloud providers
- Additional costs for cloud sandbox usage
Use Cases
Remote execution could be useful for:- Maximum security isolation requirements
- Scalable multi-tenant applications
- Environments without local compute resources
- Compliance scenarios requiring external execution
Environment Selection Guidelines
Recommendation: Use the local execution environment unless you have specific security or isolation requirements. It provides the best performance and is the only fully supported option.
Local Environment
- ✅ Best for: Development, testing, most production use cases
- ✅ When: Performance is critical and security isolation isn’t required
- ✅ Advantages: Fast, simple, fully supported
- ⚠️ Consider: Security implications of running tools with application permissions
Docker Environment
- ⚠️ Best for: Security-conscious environments willing to handle potential issues
- ⚠️ When: Isolation is required and you can manage container complexity
- ⚠️ Advantages: Security isolation, consistent environments
- ❌ Drawbacks: Limited support, performance overhead, setup complexity
Remote Environment
- ❌ Not recommended: Due to limited support and schema restrictions
- ❌ Current status: Not actively maintained
- ❌ Limitations: Schema only allows ‘local’ environment type
Execution Adapter Interface
All environments implement the sameExecutionAdapter
interface, ensuring consistent tool behavior:
Performance Considerations
Local Environment Performance
- Fastest execution with no overhead
- Direct file system access for optimal I/O
- Native process execution for commands
- Minimal memory footprint
Docker Environment Performance
- Container startup overhead for each session
- File system mounting may impact I/O performance
- Network overhead for container communication
- Additional memory usage for container runtime
Remote Environment Performance
- Network latency for all operations
- Bandwidth limitations for large file operations
- Service availability dependency
- Potential rate limiting from cloud providers
Security Considerations
Local Environment Security
- Tools run with application permissions
- Direct access to file system and network
- No isolation from host system
- Trust required in tool implementations
Docker Environment Security
- Process isolation from host system
- Limited file system access through volume mounts
- Network isolation capabilities
- Container escape risks (though minimal)
Remote Environment Security
- Maximum isolation from local system
- Managed security by cloud provider
- Network-only attack surface
- Data transmission security considerations
Troubleshooting
Local Environment Issues
- Permission errors: Check file system permissions
- Path issues: Verify working directory settings
- Tool failures: Check tool-specific error messages
Docker Environment Issues
- Container startup failures: Check Docker configuration
- Volume mounting problems: Verify path mappings
- Network connectivity: Check container networking
- Image compatibility: Ensure proper base images
Remote Environment Issues
- Connection failures: Check network connectivity
- Authentication problems: Verify API credentials
- Service availability: Check provider status
- Rate limiting: Monitor usage quotas
Migration Between Environments
While the interface consistency allows for environment switching, consider these factors:From Local to Docker
- Performance impact: Expect slower execution
- Setup complexity: Requires Docker configuration
- File path changes: May need path adjustments
- Limited support: Prepare for potential issues
From Local to Remote
- Currently not possible: Schema restrictions prevent remote environment
- Future consideration: May become available in future versions
- Network dependency: Would require stable internet connection
- Cost implications: Cloud sandbox usage fees
Best Practices
Local Environment
- Monitor permissions: Be aware of what tools can access
- Validate inputs: Sanitize tool parameters carefully
- Error handling: Implement robust error recovery
- Resource monitoring: Watch for resource usage
Docker Environment (if used)
- Container management: Properly clean up containers
- Volume security: Limit mounted directories
- Image maintenance: Keep base images updated
- Resource limits: Set appropriate container limits
General Recommendations
- Start with local: Use local environment for development
- Test thoroughly: Validate tool behavior in your chosen environment
- Monitor performance: Track execution times and resource usage
- Plan for scaling: Consider environment implications for production
Next Steps
- Learn about Agent Architecture to understand how environments integrate with agents
- Explore Session Management to see how environments affect session state
- Understand the Tool System to see how tools execute in different environments
- Check out Getting Started for practical environment setup examples