Sandboxes

Sesame uses sandboxes to isolate agent session execution. Each sandbox provider offers different tradeoffs between security, performance, and ease of setup.

Security Overview

In addition to provider-level isolation, Sesame supports OS-level sandbox security via @anthropic-ai/sandbox-runtime. This adds filesystem and network restrictions regardless of which provider you use.

Security Layer	Protection	Availability
Provider Isolation	Process/container separation	All providers
Sandbox Security	Filesystem + network restrictions	macOS, Linux

Sandbox security is enabled by default on supported platforms. Configure it at /admin/sandbox or via SANDBOX_SECURITY_ENABLED.

What Sandbox Security Provides

Filesystem restrictions: Agents can only write to the project directory and /tmp. Sensitive paths like ~/.ssh and ~/.aws are blocked.
Network restrictions: Only agent-specific API domains are allowed (e.g., api.anthropic.com for Claude). Admins can configure additional allowed/denied domains.
Violation monitoring: Blocked access attempts are logged and streamed to the UI in real-time.

See Settings > Sandbox Security for configuration details.

Runtime & Dependency Management

Sesame uses mise to automatically detect and install the correct runtime versions and dependencies for each project.

Feature	What It Does
Runtime versions	Reads `.nvmrc`, `.node-version`, `.python-version`, `.tool-versions`, `mise.toml`
Dependencies	Auto-runs `npm install`, `pip install`, `bundle install`, etc. based on lockfiles
Isolation	Each sandbox gets its own mise installation

This means agents work with the exact versions specified in the project, without manual setup.

See How It Works > Mise Integration for technical details on how this works.

Sandbox Providers

Filesystem

Docker

Vercel

Daytona

E2B

Comparison

Overview

Provider	Isolation	Setup	Boot Time	Best For
Filesystem	Process	None	Instant	Development, trusted environments
Docker	Container	Docker installed	~2-5s	Production, untrusted code
Vercel	Cloud microVM	API credentials	Seconds	Vercel hosting, cloud-native
Daytona	Cloud sandbox	API key	Seconds	Cloud development, flexible resources
E2B	Cloud VM	API key	~150ms	Fast cloud sandboxes, simple setup

Features

Feature	Filesystem	Docker	Vercel	Daytona	E2B
Output streaming	Yes	Yes	Yes	Yes	Yes
stdin support	Yes	Yes	No	No	No
Port previews	localhost	Dynamic (socat proxy)	Declared upfront	Dynamic	Dynamic
Persistence	Full (host filesystem)	Optional (volume mounts)	None (ephemeral)	Until cleanup/auto-stop	Until cleanup/timeout
Native file operations	Shell commands	Shell commands (docker exec)	SDK (`@vercel/sandbox`)	SDK (`@daytonaio/sdk`)	SDK (`e2b`)
Custom images/templates	N/A	Custom Docker images	Runtime selection	Language selection	Custom E2B templates
Resource configuration	Host limits	Container limits	vCPUs, timeout	CPU, memory, disk	Template-based

Security

Feature	Filesystem	Docker	Vercel	Daytona	E2B
OS-level sandboxing	Yes (required)	Available	N/A (cloud isolation)	N/A (cloud isolation)	N/A (cloud isolation)
Filesystem restrictions	Via sandbox security	Container + sandbox security	Cloud VM isolation	Cloud isolation	Cloud VM isolation
Network restrictions	Via sandbox security	Container + sandbox security	Cloud VM isolation	Cloud isolation	Cloud VM isolation
Violation monitoring	Yes	Yes	No	No	No

OS-level sandboxing via @anthropic-ai/sandbox-runtime restricts filesystem and network access on the host. Cloud providers (Vercel, Daytona, E2B) don't need it because their VMs already provide full isolation.

The Docker provider uses the official sesame-sandbox image by default, which comes pre-loaded with mise, common runtimes (Node.js, Python, Go, Rust, Ruby, Bun), and all agent CLIs for fast session startup.

The Vercel provider requires ports to be declared at sandbox creation time. All other providers support dynamic port exposure.

Filesystem

Docker

Vercel

Daytona

E2B

On this page