Cloud Sandbox Toolkits
Why cloud sandboxes?
Most “code interpreter” agents execute model-generated code locally. That’s fine for trusted personal use but a problem in production:- A bug or prompt injection can read your filesystem, hit your internal network, or shell-fork-bomb the process.
- Multiple concurrent sessions step on each other’s state.
- You can’t enforce CPU/memory/network limits cleanly across platforms.
CloudSandbox interface so they’re interchangeable.
CloudSandbox interface
E2BSandboxToolkit
npm install @e2b/sdk. Get an API key at e2b.dev.
Tools exposed
E2BSandboxToolkit.getTools() returns four tools:
| Tool | Parameters | Returns |
|---|---|---|
sandbox_e2b_run | { code, language?, timeoutSeconds? } | JSON { output, exitCode } |
sandbox_e2b_shell | { command, timeoutSeconds? } | JSON { output, exitCode } |
sandbox_e2b_write_file | { path, contents, encoding? } | "ok" |
sandbox_e2b_read_file | { path, encoding? } | The file content or "[file not found]" |
Direct access
toolkit.getSandbox() returns the underlying E2BSandbox if you need to call it programmatically (e.g. seed files before the first agent call):
Templates
E2B sandbox templates control which language runtimes, libs, and tools are preinstalled. Pass the template ID viatemplate:
| Template | Includes |
|---|---|
"base" (default) | Python 3.10, Node 20, common Linux utilities |
"data-science" | + pandas, numpy, matplotlib, scipy, scikit-learn |
| Custom | Build your own at e2b.dev/dashboard/templates |
DaytonaSandboxToolkit
Same interface, different backend:
npm install @daytonaio/sdk. Hosted Daytona or self-hosted both work; pass baseURL for self-hosted.
Tool names: sandbox_daytona_run, sandbox_daytona_shell, sandbox_daytona_write_file, sandbox_daytona_read_file.
When to use which
| You want | Pick |
|---|---|
| Fast onboarding, generous free tier | E2B |
| Self-hosted control plane | Daytona |
| Custom OS image | Both support it |
| Both in the same agent | Yes — give the agent both toolkits’ tools |
Compose with SandboxAgent
If you want a persistent workspace that survives across turns AND lives in a cloud VM, plug a CloudSandbox into SandboxAgent:
Lifecycle and cost
- Sandboxes are created lazily on the first tool call.
- They live until you call
toolkit.close()(or the provider’s idle timeout fires, usually 5–10 min). - Always
await toolkit.close()at the end of a request to free the sandbox. - For multi-tenant deployments, one sandbox per session is the right model. Don’t reuse across users.
Failure modes
| Failure | Behavior |
|---|---|
| API key missing | Constructor throws "missing API key" |
| SDK package not installed | Constructor throws "@e2b/sdk is required..." |
| Timeout | run() returns { timedOut: true, exitCode: 124, output: "..." } |
| Network error to provider | run() rejects; LLM sees the error string and can retry |
See also
SandboxAgent— persistent workspace agent that can use these as a backend- Computer Use Agent — for GUI control, not code execution
- Code Interpreter Toolkit — local-only alternative for trusted environments