E2B Sandbox: Secure Code Execution for AI Agents

Every team building a code-executing AI agent eventually runs into the same wall: where does the model-generated code actually run? Running it on your host server is a liability. Running it inside Docker is better but not enough for untrusted LLM output at scale. E2B was built specifically for that problem, and it now has a documented OpenAI Agents SDK integration for running SandboxAgent workflows inside E2B sandboxes.

This guide covers what E2B is, how it works, how to integrate it with Python and the major LLM providers, and when it makes sense compared to alternatives like Modal and Daytona. If you are building the agents that will run this code, our OpenAI Agents SDK multi-agent tutorial and AI agent frameworks compared cover the orchestration side. Before you commit to a sandbox provider, our OpenAI Agents SDK sandbox provider readiness checklist lists what to verify first.

Effloow Lab note: Effloow Lab installed e2b-code-interpreter==2.6.2 and e2b==2.20.3, inspected the SDK surface, and confirmed the authentication boundary. Live sandbox execution requires an E2B API key, so this article does not claim a live E2B sandbox run. The public evidence note is at the E2B sandbox PoC lab note.

October 10 update and disclosure: We added independent Freestyle VM measurements collected on September 16–19, 2026 (UTC). Freestyle provided test credits and Hobby access; there were no conditions on coverage or conclusions. E2B remains SDK-inspected only, so these results do not establish a performance winner. The Freestyle evaluation note records methods, failed attempts, and limits. The E2B SDK examples below describe the earlier inspected versions; they were not cloud-executed or revalidated against a newer SDK in this update.

Why Sandboxed Code Execution Matters#

When an AI agent generates and executes code, several things can go wrong that simply don't happen with human-written code:

• The model generates import subprocess; subprocess.run(["rm", "-rf", "/"]) based on a prompt-injection attack
• A data analysis agent leaks API keys from environment variables into output files
• A code-generating chatbot causes a denial of service by spawning infinite threads
• Cross-tenant attacks expose one user's data to another in a multi-tenant deployment

Traditional containerization mitigates some of these, but containers share the host kernel — a kernel exploit in model-generated code could affect other workloads. The security gap between "containerized" and "isolated" matters when the code author is an LLM responding to arbitrary user input.

E2B documents Firecracker microVM isolation: a sandbox runs with a separate guest kernel rather than directly sharing the application's host kernel. This architecture reduces exposure; it is not proof that escapes or cross-tenant attacks are impossible. This guide did not conduct a security audit.

There is a second reason to sandbox that has nothing to do with malicious input. If your agent both writes code and runs the tests that grade it, what the sandbox hides matters as much as what it contains: the RHB benchmark found that hardening the environment — randomized inputs, unpredictable test paths, the verifier kept out of the agent's reach — cut the exploit rate by 5.7 percentage points, an 87.7% relative drop, without hurting genuine task success. Our write-up of reward hacking in LLM agents covers which agent shapes are exposed and includes a runnable demonstration. Isolation primitives like the ones below are where that hardening is actually implemented.

What E2B Is#

E2B is a managed sandbox platform with open-source SDKs for running AI-generated code in isolated environments. E2B describes the product as an open-source, secure environment for enterprise-grade agents. Each sandbox is designed to:

• Starts managed sandbox sessions for code execution
• Runs a Jupyter kernel for interactive, stateful code execution
• Supports Python, JavaScript/TypeScript, and other languages
• Provides filesystem access, internet access, and package installation
• Can run for up to 24 hours per public Pro session; Enterprise has separate duration terms

The platform is LLM-agnostic: you bring your own model (Claude, GPT, Gemini, Llama) and use E2B for the execution layer. It ships Python and TypeScript/JavaScript SDKs.

Source snapshot checked on 2026-06-20:

• E2B's pricing page lists a free Hobby tier with a one-time $100 credit, 1-hour sandbox sessions, and 20 concurrent sandboxes.
• E2B's billing docs list Pro at $150/month with 24-hour continuous runtime and 100 to 1,100 concurrent sandboxes depending on add-ons.
• E2B's homepage states that E2B is used by 94% of Fortune 100 companies, with 7M+ monthly downloads and 1B+ started sandboxes. Treat those as vendor-stated adoption figures, not independent market-share data.
• The E2B OpenAI Agents SDK page documents E2BSandboxClient, SandboxAgent, and RunConfig integration.
• The E2B code-interpreter repository remains the live source for SDK code and examples; this article does not freeze a GitHub-star number.

Source-Backed Fit Matrix#

This table is this guide's original-value asset. It separates what the sources verify from what Effloow's local lab note actually confirmed.

SDK Installation and Setup#

Install the Python SDK:

pip install e2b-code-interpreter

The May 2026 lab installation used e2b-code-interpreter==2.6.2 and e2b==2.20.3; an unpinned install today may resolve different versions. Get your API key from the E2B dashboard at e2b.dev/dashboard under the Team tab. Set it as an environment variable:

export E2B_API_KEY="e2b_..."

Or pass it directly in code:

from e2b_code_interpreter import Sandbox

with Sandbox.create(api_key="e2b_...") as sandbox:
    execution = sandbox.run_code("print('hello from sandbox')")
    print(execution.text)  # "hello from sandbox"

The with statement ensures the sandbox is killed when the block exits. For long-running agents, you can manage lifecycle manually:

sandbox = Sandbox.create()
# ... do work ...
sandbox.kill()

The run_code API#

The run_code method is the core of E2B's code interpreter. Its full signature:

def run_code(
    self,
    code: str,
    language: Optional[str] = None,
    context: Optional[Context] = None,
    on_stdout: Optional[Callable[[OutputMessage], Any]] = None,
    on_stderr: Optional[Callable[[OutputMessage], Any]] = None,
    on_result: Optional[Callable[[Result], Any]] = None,
    on_error: Optional[Callable[[ExecutionError], Any]] = None,
    envs: Optional[Dict[str, str]] = None,
    timeout: Optional[float] = None,
    request_timeout: Optional[float] = None,
) -> Execution:
    ...

The streaming callbacks — on_stdout, on_result, on_error — are particularly useful for agents that need to stream execution feedback to end users in real time rather than waiting for the full result.

A basic example with streaming output:

from e2b_code_interpreter import Sandbox

def handle_stdout(msg):
    print(f"[sandbox stdout] {msg.line}")

with Sandbox.create() as sandbox:
    # Stateful: variables persist within the same sandbox session
    sandbox.run_code("import pandas as pd\nimport numpy as np")

    execution = sandbox.run_code(
        """
df = pd.DataFrame({'x': np.random.randn(100), 'y': np.random.randn(100)})
print(f"Shape: {df.shape}")
print(df.describe())
        """,
        on_stdout=handle_stdout,
    )

    if execution.error:
        print(f"Error: {execution.error.name}: {execution.error.value}")
    else:
        print("Final text output:", execution.text)

Because the sandbox runs a Jupyter kernel, state is preserved between run_code calls within the same session. Imports, variables, and loaded data persist until the sandbox is killed or a new context is created.

Integrating E2B with Claude (Anthropic)#

E2B maintains an official cookbook with examples for major providers. The Anthropic pattern uses Claude's tool use API to generate code, then executes it in an E2B sandbox. Set ANTHROPIC_MODEL to a model available to your account; this illustrative flow was not executed in the lab:

import os
import anthropic
from e2b_code_interpreter import Sandbox

client = anthropic.Anthropic()

CODE_INTERPRETER_TOOL = {
    "name": "execute_python",
    "description": "Execute Python code in a secure sandbox. Use for data analysis, calculations, and visualization.",
    "input_schema": {
        "type": "object",
        "properties": {
            "code": {
                "type": "string",
                "description": "Python code to execute"
            }
        },
        "required": ["code"]
    }
}

def run_agent_with_sandbox(user_message: str):
    with Sandbox.create() as sandbox:
        messages = [{"role": "user", "content": user_message}]

        while True:
            response = client.messages.create(
                model=os.environ["ANTHROPIC_MODEL"],
                max_tokens=4096,
                tools=[CODE_INTERPRETER_TOOL],
                messages=messages
            )

            if response.stop_reason == "end_turn":
                # Extract final text response
                for block in response.content:
                    if hasattr(block, "text"):
                        return block.text
                break

            # Handle tool use
            tool_results = []
            for block in response.content:
                if block.type == "tool_use" and block.name == "execute_python":
                    execution = sandbox.run_code(block.input["code"])
                    result = execution.text if not execution.error else f"Error: {execution.error.name}: {execution.error.value}"
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": result
                    })

            # Append assistant turn and tool results
            messages.append({"role": "assistant", "content": response.content})
            messages.append({"role": "user", "content": tool_results})

result = run_agent_with_sandbox(
    "Load the iris dataset from sklearn, compute correlation matrix, and summarize key findings."
)
print(result)

This pattern gives Claude persistent, stateful code execution that spans multiple tool calls within a single agent turn. The sandbox outlives any individual request and carries state across the full conversation.

Integrating E2B with OpenAI Agents SDK#

E2B documents an OpenAI Agents SDK sandbox integration. Treat this as a source-backed integration path: this article's original lab inspected the E2B code-interpreter SDK, not the agent adapter, and the Freestyle evaluation did not run either provider through an agent framework.

Use the official integration page for the current imports, configuration, and lifecycle behavior. The earlier unexecuted illustrative adapter snippet has been removed rather than presented as a validated implementation.

Execution Isolation With Code Contexts#

E2B provides code contexts for separating interpreter namespaces within one sandbox. These are execution-state boundaries, not a demonstrated security boundary between untrusted tenants:

with Sandbox.create() as sandbox:
    # Create isolated contexts for two users
    ctx_alice = sandbox.create_code_context()
    ctx_bob = sandbox.create_code_context()

    # Alice's code doesn't affect Bob's namespace
    sandbox.run_code("secret = 'alice_secret_value'", context=ctx_alice)
    sandbox.run_code("secret = 'bob_secret_value'", context=ctx_bob)

    # Each context has its own namespace
    result_alice = sandbox.run_code("print(secret)", context=ctx_alice)
    result_bob = sandbox.run_code("print(secret)", context=ctx_bob)

    print(result_alice.text)  # "alice_secret_value"
    print(result_bob.text)    # "bob_secret_value"

This separates interpreter variables within a trusted workload. Use separate sandboxes for untrusted tenants; this example does not establish isolation of files, processes, network access, or secrets.

Pause, Resume, and Persistence#

E2B's current persistence documentation describes pausing a sandbox and reconnecting to resume it. By default, pause preserves filesystem and memory state; filesystem-only mode is a separate option. Killing a sandbox permanently deletes it. These are documented behaviors, not results from our E2B lab.

For a repeated workspace, persist the sandbox ID, distinguish pause from kill, and reconnect using the supported SDK API. Verify that the required process state, files, and network clients recover in your application. A prebuilt template and a paused live workspace solve different setup problems. The earlier unexecuted create_snapshot() / Sandbox.create(snapshot=...) example has been removed because this update does not validate that API path.

MCP Gateway Integration#

E2B's MCP gateway quickstart documents configured MCP servers running inside a sandbox. An external MCP client connects using the sandbox's MCP URL and an authentication token. The current examples configure servers through the sandbox's mcp option; use the official page for your language's exact setup and token retrieval.

This guide's May lab recorded older MCP-related SDK exports, but did not execute the gateway or a GitHub integration. Exported names alone do not establish a working connector. We removed the earlier unexecuted GitHubMcpServer snippet rather than treating it as a validated current integration. Keep gateway tokens and downstream service credentials scoped, and test tool availability and cleanup before relying on the gateway in production.

Async Support#

For production FastAPI or async Python applications, use AsyncSandbox:

import asyncio
from e2b_code_interpreter import AsyncSandbox

async def analyze_data(user_code: str) -> str:
    async with await AsyncSandbox.create() as sandbox:
        execution = await sandbox.run_code(user_code)
        if execution.error:
            return f"Error: {execution.error.name}"
        return execution.text

result = asyncio.run(analyze_data("print(sum(range(1000)))"))
print(result)  # "499500"

The asynchronous interface follows the synchronous workflow; await creation and execution before using their results. Use AsyncSandbox whenever your application is already async (FastAPI, Starlette, etc.) to avoid blocking the event loop on sandbox operations.

E2B vs. Alternatives#

Read this as an evidence map, not a benchmark leaderboard. Freestyle describes full hardware virtualization and a VM-oriented lifecycle; those architectural statements are vendor documentation. Our measurements verify selected operations, not the hypervisor's isolation strength. Modal, Daytona, and local Docker remain unmeasured alternatives here.

E2B's documented code-interpreter and agent integration paths make it a candidate to evaluate. Freestyle's measured state restoration makes it a candidate when a workspace must survive days of inactivity. Choosing between them still requires the same workload, network path, resource sizing, and acceptance criteria on both providers.

Resuming Work Days Later: Freestyle Measurements#

A saved file is not enough to prove that a paused workspace retained its process state. We tested Freestyle with a service holding a nonce, process ID, boot ID, original start time, open-file offset, memory hash, disk hash, and counter. After restoration, identity and state fields had to match and the counter had to continue. This is narrower than proving that an entire agent application resumes correctly.

We used Freestyle SDK 0.2.13 from a macOS client, a pinned Ubuntu snapshot, and VMs with 2 vCPU, 4 GiB RAM, and 16 GiB disk. No region was explicitly selected. Times include client network and SDK overhead. The public lab note includes the full result table and failure ledger.

The actual long pauses were 48.4739–48.4743 and 72.2142–72.2146 hours. Restoration timings include state verification, not only API acknowledgement. The 30 first-response samples had a nearest-rank p95 of 513.3 ms; three warmups were excluded, and the three blocks ran about five minutes apart. This does not establish a regional p99 or cache-empty cold-start guarantee.

Snapshot creation and clone mutation controls also passed: each snapshot produced two clones, and changing one clone left the source and other clone unchanged in our checks. Snapshot completion medians were 7.72 s for 10 MiB disk and 11.48 s for 256 MiB disk, with 512 MiB memory in both conditions. These were compressible repeated-byte payloads, not representative production data; snapshot creation is separate from VM startup or an independently measured fork operation.

Same-VPC port policies/TLS and domain allow/deny controls passed three trials each. Cross-VPC isolation remains inconclusive: even the allowed positive control did not connect, so a failed connection cannot establish isolation. Docker was already installed in the tested image. Its preparation median of 3.43 s covers daemon startup and the pinned image pull; it is not a fresh Docker installation benchmark. Preparation required explicit root execution and DNS rules.

Three 45-minute jobs produced verified completion files and accumulated hashes after at least 60 seconds of WebSocket disconnection. The original test, which also required a clean PTY exit code, passed 0/3. Exit status was not successfully observed. Only the third sample has a saved empty PTY list; the first two lack that diagnostic record. We retained the FAIL results rather than turning artifact success into a complete test pass. The missing exit code does not itself prove abnormal termination.

For an approval-driven agent that sleeps between sessions, these state-continuity results justify a workload-specific Freestyle trial. They do not justify migration on performance grounds: E2B was not cloud-executed, billing was not reconciled, and neither provider's security or SLA was validated by this test.

Pricing Snapshot#

E2B's pricing page, rechecked October 10, 2026, says the service charges per second while a sandbox is running. Re-check the live pricing page before procurement, because plan limits and per-second rates can change.

• Hobby (free): $100 one-time usage credit, no credit card required, up to 1-hour sandbox sessions, and up to 20 concurrent sandboxes.
• Pro ($150/month): 24-hour sessions, CPU/RAM customization, up to 100 concurrent sandboxes, and paid concurrency add-ons up to 1,100 according to the current E2B page.
• Enterprise: custom terms, including multi-day/persistent sessions and BYOC. These are separate from public Hobby/Pro session caps and were not tested here; request a workload-specific quote.

At the current listed CPU rate of $0.000014/second for 1 vCPU, CPU alone would make $100 cover about 7.1 million vCPU-seconds. That is not a full workload cost estimate because RAM, storage, plan limits, idle time, and paid add-ons also matter.

A rough production calculator should use: average sandbox runtime, average CPU count, average memory, number of runs, pause/kill behavior, and concurrent-session limits. Without those inputs, monthly production cost is [DATA NOT AVAILABLE].

For Freestyle, pricing checked October 10 lists $0.04032/vCPU-hour, $0.0129/GiB-hour RAM, $0.000086/GiB-hour storage, and $0.02/GB transfer. Paused VMs retain storage charges while releasing compute reservations. Free has hard allowances; Hobby has a $50 monthly minimum including $50 usage, and Pro $500 including $500 usage. Included allowances and plan minimums matter alongside unit rates.

Our evaluation's conservative reservation estimate was $5.4328, using resource TTLs, maximum run windows, and transfer allowances. This is neither actual consumption nor an invoice. Vendor credits and Hobby access funded the test, and actual deductions were not reconciled. Resource inventory on September 30 showed zero VMs, snapshots, VPCs, TLS rules, and firewall rules remaining.

Failure and Limitation Table#

FAQ#

Q: Does E2B work with local/self-hosted models like Ollama or vLLM?#

Yes. E2B is completely LLM-agnostic — it handles the execution layer only. You point your agent at any model (Ollama, vLLM, Groq, self-hosted) and use E2B to run the code that model generates. The SDK doesn't care what produced the code string.

Q: Can I install custom packages in an E2B sandbox?#

Yes. E2B sandboxes have internet access by default, so you can run pip install or npm install inside a run_code call. For repeated use, consult the template and persistence documentation and verify your chosen reuse path. This lab did not execute package installation or measure setup savings in E2B.

Q: How does E2B compare to running code in a subprocess locally?#

A plain local subprocess is not a security sandbox: generated code may inherit filesystem, network, and environment access. E2B's documented microVM architecture provides a separate guest kernel, but this guide does not establish escape resistance. Select isolation against your threat model and keep credentials, tenants, and network permissions scoped.

Q: What languages does E2B support?#

The run_code API supports Python and JavaScript by default (the language parameter selects between them). R, Bash, and other languages can be run via subprocess inside the Python environment. Custom language support is possible with custom sandbox templates.

Q: Is there an open-source self-hosted option?#

E2B publishes code in its repository, but this guide did not evaluate a self-hosted deployment or its operating cost. Review the current deployment documentation, licenses, and support terms for the components you intend to run. A local mock does not establish production isolation; managed BYOC is also a separate deployment and procurement question.

Key Takeaways#

E2B solves a real production problem that every code-executing agent eventually faces: where does LLM-generated code run safely? The answer isn't "in a container on your server" when the code author is an AI responding to arbitrary user prompts.

The SDK design reflects this clearly. run_code supports streaming callbacks for real-time output, code contexts for separate execution state, and documented pause/resume for persistent workspaces. MCP server support means MCP-capable agent frameworks can use E2B as the execution machine when configured correctly. The OpenAI Agents SDK integration in April 2026 makes E2B a documented sandbox option, not proof that it is the best provider for every production Python agent.

When to Use / When to Skip#

Use E2B when an AI agent executes code produced from external user prompts, when you need a stateful workspace with filesystem and terminal access, or when the OpenAI Agents SDK sandbox path is more valuable than maintaining your own execution fleet. It is also a good fit for data-analysis assistants, code-interpreter features, MCP tool execution, and agent workflows that need snapshots or repeatable sandbox templates.

• Skip it if your agent never runs untrusted code. If the code your agent executes is your own, pinned, and reviewed, a local container is simpler and cheaper — E2B's isolation earns its cost specifically when an LLM writes the code from a user prompt.
• Skip the managed cloud if you need full data residency control. Where every byte must stay inside your own VPC, weigh self-managed Firecracker or a provider you fully control against E2B's hosted sandboxes.
• Skip it for a quick local prototype. For a one-off script on trusted input, the SDK and per-second sandbox billing are overhead you do not need yet.
• Skip it until you can run a real sandbox acceptance test. If you cannot create an E2B account or use an API key in a disposable project, keep the integration as a source-verified candidate rather than a production-approved dependency.

What Effloow Added#

E2B's docs explain the SDK; they don't tell you whether you need a sandbox at all, or how it compares to running code locally. We added the decision and explicit evidence boundaries:

• A bounded SDK walkthrough. Effloow Lab installed the SDK, inspected the run_code signature, recorded context/persistence/MCP API names in the May SDK inspection, and captured the missing-key authentication error. It did not run live E2B sandbox code.
• An evidence-scoped alternatives table (E2B, Freestyle, Modal, Daytona, local Docker), without ranking unmeasured providers.
• Independent Freestyle VM measurements. First-command response, actual 48/72-hour pause restoration, snapshots, Docker, and network controls, with support disclosure, failed attempts, and the incomplete PTY exit-status result.
• A source-backed fit and limitation matrix that tells teams when the official docs are enough and when they still need a live sandbox acceptance test.

The value is the "do you even need a sandbox, and if so which one" decision, not a re-paste of the SDK reference.