How I Learned to Stop Worrying and Love the Sandbox — Matt Brockman, E2B

An agent with permission to run code can consume CPU, spawn processes, delete files and read environment variables. Moving that agent from a laptop to a server carries those problems into an environment that may also hold secrets. Matt Brockman, an engineer at E2B, starts with this practical reason for sandboxes: give user-specific code an environment where its actions do not interfere with other users.

The workshop makes those failures deliberate. A capture the flag lab presents a sequence of broken environments; solving one challenge produces a flag that unlocks the next. The early exercises require Linux inspection and configuration rather than application code. Later exercises simulate management problems that become harder with hundreds or thousands of sandboxes.

E2B’s approach combines quick creation with restoration of existing state. Brockman gives a startup target of less than 100 milliseconds; this is an aim, rather than a measured result established by the workshop. The state model resembles closing and reopening a laptop: snapshot memory and the filesystem, save them, then resume where work stopped. An agent returning from another task can find the processes and files it expected to leave behind.

That changes what a template contains. In Brockman’s comparison, a Docker image supplies the built environment, then its start command launches the process. An E2B template captures a VM after processes have already started, preserving disk and RAM so a new sandbox can resume that prepared running state. The distinction will make the lab easy to reset—and later explain why forgotten background processes survive.

The first challenge asks for the current sandbox’s ID. The dashboard already connects to a sandbox running a web server for the lab, and the ID can be copied from its URL. Setup takes longer than the challenge because the room’s Wi-Fi struggles; participants pair up where necessary. Running the code remotely does not eliminate the need for a working connection to its terminal and web interface.

The URL encodes two useful pieces: the service port and the sandbox ID, in the form port-sandboxID.e2b.app. The port identifies a listening service; the ID identifies the environment to reconnect to. Keeping that ID is the first step toward returning to a particular workspace rather than simply creating another machine.

Each subsequent challenge gets a separate sandbox. A mistake in the CPU exercise can therefore leave the initial lab intact. The browser terminal connects through a PTY—a pseudoterminal session—and the prepared template supplies the challenge’s running processes. Participants receive separate copies of the prepared VM state, rather than all modifying one shared environment.

The same mechanism can fork useful work. A data scientist with a populated dataframe could copy that state into five sandboxes and run five different mutations in parallel. A template ID identifies the starting state to copy; a sandbox ID identifies one resulting instance. An agent can also connect programmatically using an API key and the instance ID, though Brockman advises reviewing its work: “Do what I say, not what I do.”

The CPU challenge supplies a concrete inspection-and-repair loop. A process listing shows one process consuming 99.7% CPU, alongside its process ID and memory usage. Killing the identified process removes the runaway task; the lab then produces a flag and unlocks level three. The useful sequence is to locate the resource consumer, identify the process responsible and act on that process.

The next failures involve different resources, so their remedies differ:

• Memory pressure. Inspect memory use and terminate the process consuming it. Adding resources has fleet consequences: CPU and RAM quotas limit how many instances can run at once, so a larger allocation to one sandbox reduces capacity available elsewhere.
• Disk pressure. Find the file taking up space, then remove it through the challenge’s cleanup flow. Terminating a process and deleting its accumulated output are different operations; the disk exercise asks for a path rather than a process ID.

The disk challenge becomes a better demonstration when the first attempt goes wrong. Brockman finds the offending file and deletes it directly, then discovers that the lab expected him to submit its path before clicking cleanup. Removing the file bypasses the expected completion sequence. “I broke the demo. That’s okay, we can just start a new one.” A fresh copy restores the challenge’s original state.

The corrected flow finds a temporary disk-fill file occupying 512 MB, submits the discovered path to the checker, and lets the cleanup button run deletion and issue the flag. When a participant cannot find the expected file, the remedy is again to reload the snapshot into a new copy. This reset is distinct from resuming the participant’s modified environment: it returns to the prepared starting state.

The browser is a convenient debugging view, not a requirement for operating the sandbox. Most interactions can happen programmatically. These first exercises establish what to inspect when arbitrary code consumes resources; the next exercises ask how to avoid wasting resources even when the code behaves correctly.

Giving every visitor a sandbox for 20 minutes sounds simple until thousands of visitors arrive, try one command or never interact at all. Their idle environments occupy capacity that other users could use. Yet a uniformly short lifetime creates the opposite failure: data science, scraping or video processing may need substantially longer to finish.

The lab separates active work from the wait for another command. Its simulated policy first allows an hour for the task, runs that task, then reduces the remaining lifetime to one minute. The hour is an allowed runtime, not a requirement to keep the machine busy for an hour. Task completion is the event that switches the policy to a short idle window.

Where does the lifetime change belong? The flow below places it after completion, so a long task retains its execution window while an unused sandbox stops occupying compute shortly afterward. Pausing preserves state for a later return; shutting down frees the running resources. Brockman discusses both choices, so the exercise’s central lesson is the timing of cleanup rather than a single mandatory retention policy.

A running sandbox responds immediately; a paused one must resume, but does not occupy the same active CPU capacity. That tradeoff matters when an agent uses several environments and its next visit is unpredictable. Persistent daemons and always-on web servers are a different fit: they can run in a sandbox, including for a day, but Brockman points toward potentially cheaper traditional hosting for long-running services.

Templates can also shorten development setup. Install base dependencies once, preserve that prepared environment, then fork it for separate work. This carries forward expensive preparation in much the same spirit as a dependency cache in GitHub Actions, while leaving each copy room to develop independently.

Resumption preserves unfinished work, including work nobody intended to keep. A process starts, its user moves on, and later sessions accumulate more background processes. Returning to a snapshot restores those processes alongside everything useful. This is the downside of finding things exactly where you left them.

The exercise begins with three leaked workers. A search finds them by a deliberately convenient name; after one is killed, the count drops to two. Removing the remaining workers clears the challenge and produces the next flag. Real leaked processes are rarely labeled so helpfully, so the lab simplifies identification while retaining the inspect, terminate and recheck loop.

Cleanup operates at two scales. Inside a sandbox, remove processes that no longer serve a task. Across the fleet, track the sandboxes themselves so environments that fall out of application management can be found and removed. Losing an instance ID can turn a whole sandbox into an abandoned resource.

The first Python exercise changes a router that hands out sandboxes in round robin order. That policy distributes assignments without remembering which environment a user previously received. A returning user needs a stable workspace, so the router must instead keep a mapping from user ID to sandbox ID.

The assignment function has a small but consequential sequence: check whether the user already has an entry; if so, return the saved sandbox ID. Otherwise obtain a sandbox ID, store it under that user and return it. The lab uses a dictionary and mocked sandbox operations to exercise this behavior without creating an unnecessary fleet.

The live edit initially returns the ID without saving the assignment. The test fails, and an audience member identifies the missing write. Adding the sandbox ID to the dictionary makes the test pass. The causal difference is persistence between calls: returning an ID serves the current request; recording it lets the next request find the same workspace.

For an application, Brockman recommends a database that tracks users and their active sandboxes. Persistent records also make assignment history inspectable: excessive reassignment can be investigated rather than disappearing with an in-memory dictionary. The lab demonstrates the mapping mechanism, while the database recommendation addresses keeping that knowledge beyond one process.

The filesystem exercise separates what an agent can read from where it should write. A template cache contains information prepared while building the template and may be read-only. A runtime cache supplies a separate destination for writes made during execution. The fix changes the cache-store configuration to point at the runtime cache.

This is a configuration decision with an operational consequence: code that needs to update its cache must target a writable location, even if it can read useful files elsewhere. Brockman mentions describing intended locations in AGENTS.md, but the demonstrated change hard-codes the cache destination. The exercise does not implement a general filesystem permission system.

The closing discussion moves beyond the lab. One participant wants to distribute a locally prepared environment across GPUs from different providers and bring the whole sandbox back afterward. E2B did not support GPUs at the time described in the recording. Sending results home in a POST request is offered as a common output-return pattern, but it does not establish a solution for transferring the participant’s complete GPU execution state; Brockman leaves that question unresolved.

Fleet operations introduce problems beyond a single runaway process:

• Logging and assignment. Keeping track of many environments creates management overhead even when each environment works correctly.
• Network capacity. Hosts can communicate with only so many sandboxes at a time, making connections another resource to manage.
• Stored state. Creating and retaining many sandboxes raises pruning, compression and storage-growth questions. Brockman describes these as active engineering challenges rather than presenting a finished retention policy.
• Shared files. Volumes provide a place for resources that multiple environments can share, though that capability alone does not answer every question about accumulated snapshots.

The execution environment and the agent can be placed separately. Claude Code or Codex can run inside a sandbox, or a local agent can talk to a remote sandbox. Underneath, Brockman describes E2B as Firecracker-based and running Nomad, with Kubernetes integration still facing technical issues at that point. These are the deployment choices described in the recording, rather than requirements imposed on every sandbox system.

An orchestrator can also use one sandbox to create others for a team of agents. The workshop already has a simpler version of that arrangement: the participant acts as coordinator and clicks to start a challenge from its template. Automated orchestration was omitted to avoid API-key setup and the risk of displaying a key during the recording. The same creation mechanism can be driven programmatically.

Whether templates develop into a Docker-like ecosystem remains an open question. Their immediate value is more concrete: one prepared running environment can be reused by many people. Local development also remains useful inside E2B, especially for testing, where cloud execution adds friction.

The final question returns to the risk that motivated the workshop: what can code send out? E2B sandboxes offer configurable network rules. If an environment can read secrets, its outbound access deserves corresponding restriction. A sandbox gives code a separate place to run; the application still has to decide which files, credentials and network destinations belong within its reach.