Code Sandbox overview

The Code Sandbox is a locked-down, throwaway computer where your agent's Python code runs. This page explains what it is, when to use it, and how it compares to the equivalent products on AWS, Azure, and GCP.

What it is

When an AI agent decides it needs to run code — to do math, parse a file, transform data — it should not run that code inside its own process. Model-generated code is untrusted: it might loop forever, eat all the memory, or try to read the agent's API keys. The Code Sandbox solves this by running each snippet in a separate, disposable pod.

A pod is a small, isolated container the platform starts for you. Each sandbox pod:

• runs exactly one snippet, then is destroyed — never reused,
• runs as a non-root user with no cluster credentials,
• can reach nothing on the network except DNS (name lookups).

You never deploy, size, or manage the sandbox. It is always on and wired into every agent automatically.

The warm pool: why starts are fast

Starting a fresh pod takes time. So the platform keeps a small pool of pre-started "warm" pods (the target is 3) ready and waiting. When your agent runs code, the sandbox service claims a warm pod, runs the snippet, deletes the pod, and starts a replacement in the background. Your code starts in about a second instead of waiting for a container to boot.

30-second mental model

Two kinds of sandboxed runs

1. Code snippets (run_python): your agent sends Python source, the sandbox returns stdout, stderr, and an exit code. This is the common case. See Run code in the sandbox.
2. Sandboxed tool calls: when your agent calls one of your own tool functions, the platform can run that function in a one-use pod built from the agent's own container image — same code, but stripped of every platform credential. Untrusted or model-triggered code can never read the agent's API keys or reach internal services. This happens automatically; you don't call it yourself.

When to use it

• Your agent needs to compute, parse, or transform something reliably (LLMs are bad at arithmetic; Python is not).
• You want model-generated code to run where it cannot touch your credentials or your network.
• You want each run to start from a clean slate, with no state leaking between runs.

The sandbox is not a place to keep state. Files written during a run do not survive it. Keep multi-turn state in your agent's session instead.

How it compares

Cloud	Their product	Their model	How ours differs
AWS	Amazon Bedrock AgentCore Code Interpreter	Session-based sandbox in a micro-VM, driven through an SDK: start a session, invoke it repeatedly, stop it	One HTTP call, one throwaway pod. No session lifecycle to learn, and no session state that can leak between calls.
Azure	Azure Container Apps dynamic sessions	Prewarmed, Hyper-V-isolated session pools you address with a caller-supplied identifier; sessions are reused across calls	Similar warm-pool speed, but our pods are never reused — not even for the same caller. Single-use is the default and the only mode.
GCP	Gemini / Vertex AI code execution tool	A model feature, not a product: Gemini can emit and run Python inline during a generation, with a short cap and no file story	run_python is an explicit tool. Your agent (or the model, via tool calling) decides when code runs — it is directly invokable and returns structured output.

Honest trade-offs: AWS and Azure offer stronger hardware-level isolation (micro-VMs and Hyper-V) than our default container isolation, plus persistent sessions, more regions, and SLAs. What we guarantee that they don't: every run gets a fresh environment, always, with no reuse mode to configure or get wrong. Read the full isolation story in Security and limits.

In this section

• Run code in the sandbox — using run_python from an agent, and the raw API.
• Security and limits — the honest security model: what protects you and what doesn't.

Related: Agent tools · Invoke an agent