Sandboxes let agents run user code without exposing other users, local machines, or server secrets to the same risks.
2
E2B templates preserve a running VM's memory and filesystem, so a sandbox can resume with its processes and files intact.
3
Sandbox fleets need explicit lifecycle and assignment policies, because idle resources, orphaned processes, and lost workspace mappings become expensive at scale.
Summary
Matt Brockman teaches sandbox operations through a capture-the-flag workshop built from deliberately broken environments. The early exercises use Linux commands to find a sandbox ID, kill a process consuming 99.7% of CPU, reduce memory pressure, and locate a file filling the disk. Each challenge runs in a separate sandbox, so participants can reset a mistake by starting from a template. Brockman explains that E2B templates capture a running VM's memory and filesystem, which makes returning to an agent's previous state fast but also brings back forgotten processes. The later exercises address fleet management: give long-running tasks enough time to finish, shorten the idle timeout afterward, map users to stable sandbox IDs, clean up orphaned processes, and separate template files from runtime cache writes. Audience questions extend the discussion to volumes, distributed workloads, GPUs, Kubernetes, local development, and network restrictions.
Sandboxes isolate arbitrary agent code from the rest of the application
Brockman describes a sandbox as a place to run user-specific code without affecting other users. Agents can use a local machine's CPU, spawn processes, delete files, or access environment variables when given broad permissions. A server does not remove all of those risks because it can still contain secrets and must be configured with the right environment. Sandboxes provide a separate environment for this work. E2B aims to start them in less than 100 milliseconds, which supports running several tasks at once. The workshop uses this model to let participants break an environment without breaking the initial setup.
A template resumes a running system, including its memory and filesystem
E2B snapshots the sandbox's memory and filesystem, then saves that state to storage so the system can resume later. Brockman compares this with a Docker image, where processes start after the image is built. In E2B's model, processes are started before the template is saved, so they are already running when a sandbox resumes. He demonstrates how one prepared capture-the-flag environment can become many copies. The same pattern can fork a data science state into several experiments, each starting with the same data frame and files.
Separate sandboxes make operational failures safe to reset
Each capture-the-flag level starts a new sandbox from a prepared template. Brockman points out that participants can deliberately break the current environment without damaging the earlier levels. A reload action creates a fresh copy from the snapshot. This matters for debugging because the workshop itself contains resource failures, including runaway CPU use, memory pressure, and a full disk. The browser dashboard provides a terminal connected to the sandbox, while the sandbox ID identifies the particular environment and lets a user return to it.
Resource debugging starts with ordinary process and filesystem inspection
The first operational challenges use Linux tools and instructions rather than application code. One process consumes 99.7% of the CPU, so participants inspect the process list, find its process ID, and kill it. The next exercise asks them to find what is using memory and terminate it. A disk-fill challenge requires locating the path consuming the disk, then submitting that path to a cleanup action. Brockman accidentally removes the wrong thing during the demonstration and resets the sandbox, which illustrates why isolated, reproducible environments help during troubleshooting.
Sandbox lifetimes should follow the task, then become short
At small scale, leaving a sandbox running is easy to overlook. At thousands or tens of thousands of users, giving every visitor a sandbox for a fixed period can waste capacity when many users never interact with it. Brockman's lifecycle exercise gives a task a long runtime so data processing or web scraping can finish, then reduces the sandbox timeout to a short period after the task completes. The sandbox can remain available briefly for another command and then pause or shut down. He frames this as a speed and cost trade-off: running systems respond quickly, while paused systems consume fewer active resources.
Resumed state makes cleanup part of sandbox management
A resumed sandbox brings back the state that was saved, including processes that were left running. Brockman calls these leftover processes orphans and shows a challenge with three orphan workers. Participants search for the processes, kill them, and check again until the sandbox is clean. He says that a large part of sandbox management becomes finding and removing resources that are no longer being managed. The same issue appears when applications lose track of which sandboxes they created, so lifecycle systems need records of active environments and cleanup rules.
Stable user-to-sandbox mapping preserves a user's workspace
The workspace exercise begins with a naive round-robin allocator. A user can receive a different sandbox on each request, which prevents reliable continuation of work. Brockman changes the handler to store an assignment from user ID to sandbox ID and return the existing ID when that user comes back. In a real system, he would generally keep this mapping in a database along with active sandbox information and historical data. The exercise uses an in-memory assignment dictionary and tests to demonstrate the basic mapping.
Templates and runtime caches need different filesystem permissions
Agents should not write to every part of a sandbox filesystem. Brockman describes a template cache containing files prepared when the template is built, alongside a runtime cache intended for writes made while the sandbox is running. The configuration exercise changes the cache path so runtime output goes to the writable runtime location rather than the template data. He connects this to agent instructions that specify which parts of the filesystem an agent may read or write. The distinction prevents runtime work from modifying the base material that other sandboxes inherit.
Sandbox fleets raise storage, networking, and orchestration problems
In the discussion, Brockman says that creating many sandboxes raises questions about where their state is stored, how to prune resources, and how to handle compression. Shared volumes can hold resources used by several sandboxes. E2B does not support GPUs in this setup, and Brockman says the company is working through Kubernetes-related technical issues while using Nomad at the time of the talk. Sandboxes can run agents such as Claude Code or Codex, and network rules can restrict what they send out. Access to secrets therefore needs matching network controls.
