Pydantic AI adds native E2B sandboxes for coding agents

Keeping the agent off your machine

Pydantic argues that a coding agent which runs commands such as python -m unittest and edits files on a laptop is a liability. It would run as the user, with SSH keys and production .env files within reach, and nobody reviews each command before it runs. In the company's words, an agent that waited for review would not be an agent.

With E2B as a native provider, the commands run in a microVM, and according to Pydantic nothing from the user's environment reaches the sandbox. The sandbox can pause when a run ends and resume at the next one with its filesystem and memory intact. The workspace is identified by a credential-free reference, which lets a durable workflow carry it across a worker crash.

Setup uses the harness with the E2B and Temporal extras, plus provider and Logfire extras for tracing. The user sets E2B_API_KEY and the model provider key. E2BSandbox supplies execution only. The Coder capability, or the narrower Shell and FileSystem capabilities, supply the tools, and those tools now run in the sandbox. Pydantic says there is no custom E2B adapter and no template to build, because E2B's default template ships with Python and git.

Defaults and the pause-and-resume example

Pydantic lists several defaults. A sandbox lives for an hour unless sandbox_timeout is set, and when the time runs out E2B pauses it rather than killing it. Internet access is on unless allow_internet_access=False is passed. Pydantic AI never kills a sandbox when a run ends: the application that created it owns its lifetime, and a forgotten sandbox is one you keep paying for. The default template has pip but not uv.

The first example from the E2B cookbook uses a small Python CLI that summarizes JSONL API request logs. Its tests fail because it counts server errors and computes p95 latency incorrectly. The first agent run reads the code and tests and writes diagnosis.md without touching the source. The application then pauses the sandbox and attaches a new backend using only the reference. A second run fixes the bug using the saved diagnosis and the first run's conversation history.

The cookbook narrows the tool surface on purpose: Shell exposes only run_command, FileSystem exposes three file tools, and internet access is off. Pydantic notes that a narrow tool list makes the boundary cheaper to reason about.

The example also verifies the agent's work rather than trusting its summary. It restores the test file from a trusted host fixture, confirms the input logs were not edited, and runs the tests itself. Four tests pass and the CLI prints the right counts. The script asserts the same sandbox id and SHA-256 checksums before and after the pause, then kills the sandbox and confirms it is gone from the account.

Surviving a killed worker with Temporal

The second example runs the same task inside a Temporal workflow. Between the two agent runs, the demo sends SIGKILL to the worker, with no graceful shutdown. A new worker starts on the same task queue, Temporal replays the recorded history, and the workflow continues the repair in the sandbox the dead worker left behind.

The only change to the agent is adding TemporalDurability to the capability list, with activity settings such as a 45-second start_to_close_timeout and a retry policy of two maximum attempts.

What it means for developers

For teams building coding agents with Pydantic AI, the change offers a one-line route to isolated execution, with sandbox state that can outlast both a run and the process driving it. Developers still own cleanup and lifetime, and should decide deliberately about internet access and the breadth of tools they hand the agent.