1# Sandbox Agents
2
3A sandbox gives an agent an isolated, Unix-like execution environment with a
4filesystem, shell, installed packages, mounted data, exposed ports, snapshots,
5and controlled access to external systems.
6
7Agent workflows get brittle when the model needs that kind of workspace but
8only receives prompt context. Large document sets, generated artifacts,
9commands, previews, and resumable work all need an environment the agent can
10inspect and change.
11
12Sandbox agents are currently only available in the Python Agents SDK.
13
14Use sandboxes when the agent needs to manipulate files, run commands, mount a
15data room, produce artifacts, expose a service, or continue stateful work
16later.
17
18The key split is the boundary between the harness and compute. The harness is
19the control plane around the model: it owns the agent loop, model calls, tool
20routing, handoffs, approvals, tracing, recovery, and run state. Compute is the
21sandbox execution plane where model-directed work reads and writes files, runs
22commands, installs dependencies, uses mounted storage, exposes ports, and
23snapshots state.
24
25Keeping those boundaries separate lets your application keep sensitive control
26plane work in trusted infrastructure while the sandbox stays focused on
27provider-specific execution. The sandbox can run code against files with narrow
28credentials and mounts; the harness can keep auth, billing, audit logs, human
29review, and recovery state outside any one container.
30
31<div className="not-prose my-8 grid gap-4 lg:grid-cols-2">
32 <figure>
33 <figcaption className="mt-3 text-sm text-gray-600 dark:text-gray-400">
34 Running the harness inside the sandbox can be convenient for prototypes,
35 but it puts orchestration and model-directed execution in the same compute
36 boundary.
37 </figcaption>
38 </figure>
39
40 <figure>
41 <figcaption className="mt-3 text-sm text-gray-600 dark:text-gray-400">
42 The harness can run in your infrastructure while the sandbox handles
43 provider-specific, stateful execution.
44 </figcaption>
45 </figure>
46</div>
47
48## When to use a sandbox
49
50Use a sandbox when the agent's answer depends on work done in a sandbox
51workspace, not just reasoning over prompt context.
52
53Common pain points include:
54
55- The task needs a directory of documents, not a single prompt.
56- The agent should write files that your application can inspect later.
57- The agent needs commands, packages, or scripts to complete the work.
58- The workflow produces artifacts such as Markdown, CSV, JSONL, screenshots, or generated websites.
59- A service, notebook, or report preview needs to run on an exposed port.
60- Work pauses for human review and then resumes in the same workspace.
61
62If your workflow only needs a short model response and no persistent workspace,
63call the [Responses API](https://developers.openai.com/api/reference/responses/overview) directly or use the
64basic Agents SDK runtime without a sandbox.
65
66If shell access is only one occasional tool, start with the hosted shell tool in
67[Using tools](https://developers.openai.com/api/docs/guides/tools#usage-in-the-agents-sdk). Use sandbox
68agents when workspace isolation, sandbox provider choice, or resumable
69filesystem state is part of the product design.
70
71## What sandboxes add
72
73`SandboxAgent` is still an `Agent`. It keeps the usual agent surface, including
74`instructions`, `prompt`, `tools`, `handoffs`, `mcp_servers`, `model_settings`,
75`output_type`, guardrails, and hooks. What changes is the execution boundary:
76the runner prepares the agent against a live sandbox session that owns files,
77commands, ports, and provider-specific isolation.
78
79| Piece | What it owns | Design question |
80| ------------------ | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
81| `SandboxAgent` | The agent definition plus sandbox defaults | What should this agent do, and which sandbox defaults travel with it? |
82| `Manifest` | The fresh-session workspace contract | What files, directories, repos, mounts, environment, users, or groups start out in the workspace? |
83| Capabilities | Sandbox-native behavior attached to the agent | Which sandbox tools, instructions, or runtime behavior does this agent need? |
84| Sandbox client | The provider integration | Where should the live workspace run: Unix-local, Docker, or a hosted provider? |
85| Sandbox session | The live execution environment | Where do commands run, files change, ports open, and provider state live? |
86| `SandboxRunConfig` | Per-run sandbox session source, client options, and fresh inputs | Should this run inject, resume, or create the sandbox session? |
87| Saved state | `RunState`, `session_state`, and snapshots | How should later runs reconnect to work or seed a new workspace? |
88
89Sandbox-specific defaults belong on `SandboxAgent`. Per-run sandbox-session
90choices belong in `SandboxRunConfig`.
91
92Sandbox agents also don't change what a turn means. A turn is still a model
93step, not a single shell command or sandbox action. Some work may stay inside
94the sandbox execution layer. The agent runtime consumes another turn only when
95it needs another model response after sandbox work has happened.
96
97## Create the workspace
98
99`Manifest` describes the desired starting contents and layout for a fresh
100sandbox workspace. Use it for the files, repos, input artifacts, helper files,
101mounts, output directories, and environment setup the agent should see.
102
103Treat the manifest as a fresh-session contract, not the full source of truth for
104every live sandbox. The effective workspace for a run can instead come from a
105reused live sandbox session, serialized sandbox session state, or a snapshot
106chosen at run time.
107
108Manifest entry paths are workspace-relative. They can't be absolute paths or
109escape the workspace with `..`, which keeps the workspace contract portable
110across local, Docker, and hosted clients.
111
112| Manifest input | Use it for |
113| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------- |
114| `File`, `Dir` | Small synthetic inputs, helper files, or output directories. |
115| `LocalFile`, `LocalDir` | Host files or directories to materialize into the sandbox. |
116| `GitRepo` | A repository to fetch into the workspace. |
117| `S3Mount`, `GCSMount`, `R2Mount`, `AzureBlobMount`, `S3FilesMount` | External storage to make available inside the sandbox. |
118| `environment` | Environment variables the sandbox needs when it starts. |
119| `users` and `groups` | Sandbox-local OS accounts and groups for providers that support account provisioning. |
120
121Good manifest design means:
122
123- Put repos, input artifacts, and output directories in the manifest.
124- Put longer task specs and repo-local instructions in workspace files such as `repo/task.md` or `AGENTS.md`.
125- Use relative workspace paths in instructions, for example `repo/task.md` or `output/report.md`.
126- Keep mounted storage scoped to the inputs the agent should read or write.
127- Treat mount entries as ephemeral workspace entries: snapshot and persistence flows skip mounted remote storage instead of copying it into saved workspace contents.
128
129### Mount files and storage
130
131Useful data often already lives somewhere else. Instead of pasting large
132documents into context, mount them into the sandbox and let the agent work with
133files.
134
135Examples:
136
137- Mount a due-diligence data room and ask the agent to produce a cited summary.
138- Mount a support export and ask the agent to cluster issues into a report.
139- Mount generated artifacts so another system can review them.
140
141Provider integrations expose their own mount helpers, credential handling, and
142persistence behavior. Keep the application contract the same: mount only the
143inputs the agent should use, tell the agent where to read and write, and check
144generated artifacts before using them.
145
146### Handle secrets and credentials
147
148Treat sandbox credentials as runtime configuration, not prompt content. The
149agent may need access to credentials for package managers, storage mounts, or
150provider APIs, but those credentials shouldn't appear in user prompts,
151agent instructions, task files, committed manifests, or generated artifacts.
152
153Use these rules:
154
155- Prefer provider-native secret systems for hosted sandbox providers.
156- Keep cloud storage credentials scoped to the mount or provider option that needs them.
157- Use `Manifest.environment` for values the sandbox process needs at startup, and mark sensitive or generated entries as ephemeral when you want to rebuild them instead of persisting them.
158- Avoid saving secrets, generated mount config, local tokens, or files that shouldn't survive the run.
159- Review artifacts before moving them out of the sandbox, especially when the agent can read private documents or mounted storage.
160
161The SDK supports manifest environment values and provider-specific mount
162credentials. General secret-store integration is provider-specific, so keep this
163page focused on the contract: your runtime or sandbox provider should inject
164credentials instead of teaching them to the model as instructions.
165
166## Give the agent capabilities
167
168Capabilities attach sandbox-native behavior to a `SandboxAgent`. They can shape
169the workspace before a run starts, append sandbox-specific instructions, expose
170tools that bind to the live sandbox session, and adjust model behavior or input
171handling for that agent.
172
173| Capability | Add it when | Notes |
174| --------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------ |
175| `Shell` | The agent needs shell access. | Adds command execution and, when supported by the sandbox client, interactive input. |
176| `Filesystem` | The agent needs to edit files or inspect local images. | Adds `apply_patch` and `view_image`; patch paths are workspace-root-relative. |
177| `Skills` | You want skill discovery and materialization in the sandbox. | Prefer this over manually mounting `.agents` or `.agents/skills`. |
178| [`Memory`](#persist-memory-across-runs) | Follow-on runs should read or generate memory artifacts. | Requires `Shell`; live memory updates also require `Filesystem`. |
179| `Compaction` | Long-running flows need context trimming. | Adjusts model behavior and input handling after compaction items. |
180
181By default, a `SandboxAgent` uses `Capabilities.default()`, which includes
182`Filesystem()`, `Shell()`, and `Compaction()`. If you pass a `capabilities`
183list, it replaces the default list, so include any default capabilities the
184agent still needs.
185
186Prefer built-in capabilities when they fit. Write a custom capability only when
187you need a sandbox-specific tool or instruction surface that the built-ins don't
188cover.
189
190### Load skills
191
192Some tasks need repeatable instructions, scripts, references, or assets before
193the agent starts. Use the `Skills` capability so the agent can discover that
194working context during the run.
195
196```python
197from agents.sandbox import SandboxAgent
198from agents.sandbox.capabilities import Capabilities, Skills
199from agents.sandbox.entries import GitRepo
200
201agent = SandboxAgent(
202 name="Tax prep assistant",
203 instructions="Use the mounted skill before preparing the return.",
204 capabilities=Capabilities.default() + [
205 Skills(from_=GitRepo(repo="owner/tax-prep-skills", ref="main")),
206 ],
207)
208```
209
210Choose the skill source based on how you want it materialized:
211
212- Use `Skills(lazy_from=LocalDirLazySkillSource(...))` for larger local skill directories when you want the model to discover the index first and load only what it needs.
213- Use `Skills(from_=LocalDir(src=...))` for a small local bundle to stage up front.
214- Use `Skills(from_=GitRepo(repo=..., ref=...))` when the skills bundle has its own release cadence or many sandboxes use it.
215
216### Expose previews and ports
217
218Sometimes the artifact isn't a file; it's a running process. Use an exposed
219port when the agent creates a local app, notebook, report server, browser
220preview, or other service that you need to inspect outside the sandbox.
221
222Port setup is provider-specific, but the product contract is the same: the
223agent starts the service inside the sandbox, the sandbox client exposes the
224port, and your application shares or inspects the resulting preview URL.
225
226## Run a sandbox agent
227
228The shortest useful sandbox loop is:
229
2301. Build a `Manifest` that describes the workspace.
2312. Create a `SandboxAgent` with the capabilities the model needs.
2323. Choose a sandbox client for the environment where work should run.
2334. Run the agent with `RunConfig(sandbox=SandboxRunConfig(...))`.
2345. Inspect, copy, resume, or snapshot the artifacts that matter to your application.
235
236Start with Unix-local for local development on macOS or Linux. It gives you the
237smallest local loop because the runner can create a temporary workspace from the
238agent's `default_manifest` and clean it up after the run.
239
240```python
241import asyncio
242
243from agents import Runner
244from agents.run import RunConfig
245from agents.sandbox import Manifest, SandboxAgent, SandboxRunConfig
246from agents.sandbox.capabilities import Shell
247from agents.sandbox.entries import File
248from agents.sandbox.sandboxes.unix_local import UnixLocalSandboxClient
249
250manifest = Manifest(
251 entries={
252 "account_brief.md": File(
253 content=(
254 b"# Northwind Health\n\n"
255 b"- Segment: Mid-market healthcare analytics provider.\n"
256 b"- Renewal date: 2026-04-15.\n"
257 )
258 ),
259 "implementation_risks.md": File(
260 content=(
261 b"# Delivery risks\n\n"
262 b"- Security questionnaire is not complete.\n"
263 b"- Procurement requires final legal language by April 1.\n"
264 )
265 ),
266 }
267)
268
269agent = SandboxAgent(
270 name="Renewal Packet Analyst",
271 model="gpt-5.4",
272 instructions=(
273 "Review the workspace before answering. Keep the response concise, "
274 "business-focused, and cite the file names that support each conclusion."
275 ),
276 default_manifest=manifest,
277 capabilities=[Shell()],
278)
279
280
281async def main():
282 result = await Runner.run(
283 agent,
284 "Summarize the renewal blockers and recommend the next two actions.",
285 run_config=RunConfig(
286 sandbox=SandboxRunConfig(client=UnixLocalSandboxClient()),
287 workflow_name="Unix-local sandbox review",
288 ),
289 )
290 print(result.final_output)
291
292
293asyncio.run(main())
294```
295
296For a complete local example, see [`unix_local_runner.py`][sdk-example-unix-local-runner].
297
298### Switch providers
299
300The provider is part of the run configuration, not the agent definition. Keep
301the `SandboxAgent`, manifest, and capabilities stable, then swap the sandbox
302client and provider options for the environment you want.
303
304This example uses Docker for local container isolation. Hosted providers follow
305the same pattern with their own client classes and options.
306
307```python
308from docker import from_env as docker_from_env
309
310from agents import Runner
311from agents.run import RunConfig
312from agents.sandbox import SandboxRunConfig
313from agents.sandbox.config import DEFAULT_PYTHON_SANDBOX_IMAGE
314from agents.sandbox.sandboxes.docker import DockerSandboxClient, DockerSandboxClientOptions
315
316docker_run_config = RunConfig(
317 sandbox=SandboxRunConfig(
318 client=DockerSandboxClient(docker_from_env()),
319 options=DockerSandboxClientOptions(image=DEFAULT_PYTHON_SANDBOX_IMAGE),
320 ),
321 workflow_name="Docker sandbox review",
322)
323
324result = await Runner.run(
325 agent,
326 "Summarize the renewal blockers and recommend the next two actions.",
327 run_config=docker_run_config,
328)
329```
330
331For runnable examples, see [`basic.py`][sdk-example-basic] for provider
332selection, [`docker_runner.py`][sdk-example-docker-runner] for Docker, and
333[`main.py`][sdk-example-dataroom-qa] for a data-room flow in the SDK
334repository.
335
336### Advanced patterns
337
338Once the basic loop works, sandboxes become useful for workflows where the
339agent needs a sandbox workspace instead of more prompt context. These
340examples are workflow patterns, not separate APIs: the same harness can route, pause,
341resume, and trace the workflow while each sandbox keeps execution close to the
342files, tools, and ports it needs.
343
344| Example | Description |
345| ------------------------------------------------------ | ------------------------------------------------------------- |
346| [Data room Q&A][sdk-example-dataroom-qa] | Answer questions over a mounted data room. |
347| [Data room table extraction][sdk-example-dataroom] | Extract a table from a mounted data room. |
348| [Repository code review][sdk-example-repo-code-review] | Clone a repo, inspect it, and produce code review artifacts. |
349| [Vision website clone][sdk-example-vision-clone] | Clone a website using the Vision API and screenshot feedback. |
350| [Sandbox resume][sdk-example-sandbox-resume] | Resume work in a pre-existing sandbox. |
351
352## Resume or seed future work
353
354Useful agent work often outlives one request. A user reviews an artifact, a
355step needs approval, or the next step depends on a later event.
356
357Keep three state concepts separate:
358
359| State surface | Restores | Use when |
360| --------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
361| `RunState` | Harness-side state such as model items, tool state, approvals, and active agent position. | The runner should carry the workflow forward across pauses. |
362| `session_state` | A serialized sandbox session that a client can reconnect to. | Your app or job system stores provider session state directly. |
363| `snapshot` | Saved workspace contents used to seed a fresh sandbox session. | A new run should start from saved files and artifacts, not an empty workspace. |
364
365In practice, the runner resolves the sandbox session in this order:
366
3671. If you pass `run_config.sandbox.session`, the runner reuses that live sandbox session directly.
3682. Otherwise, if the run is resuming from `RunState`, the runner resumes from the stored sandbox session state.
3693. Otherwise, if you pass `run_config.sandbox.session_state`, the runner resumes from that explicit serialized sandbox state.
3704. Otherwise, the runner creates a fresh sandbox session. For that fresh session, it uses `run_config.sandbox.manifest` when provided, or `agent.default_manifest` if not.
371
372The sandbox resume example serializes the stopped session state, resumes it
373through the same client, and then passes the resumed session back into the next
374run:
375
376```python
377async with session:
378 first_result = await Runner.run(
379 agent,
380 "Build the first version of the app.",
381 max_turns=20,
382 run_config=RunConfig(
383 sandbox=SandboxRunConfig(session=session),
384 workflow_name="Sandbox resume example",
385 ),
386 )
387
388conversation = first_result.to_input_list()
389frozen_session_state = client.deserialize_session_state(
390 client.serialize_session_state(session.state)
391)
392
393conversation.append(
394 {
395 "role": "user",
396 "content": "Continue from the existing workspace and add tests.",
397 }
398)
399
400resumed_session = await client.resume(frozen_session_state)
401try:
402 async with resumed_session:
403 second_result = await Runner.run(
404 agent,
405 conversation,
406 max_turns=20,
407 run_config=RunConfig(
408 sandbox=SandboxRunConfig(session=resumed_session),
409 workflow_name="Sandbox resume example",
410 ),
411 )
412finally:
413 await client.delete(resumed_session)
414```
415
416Fresh-session inputs such as `manifest` and `snapshot` only apply when the
417runner creates a new sandbox session. If you inject a live `session`, capability
418processing can add compatible non-mount entries, but it can't change root,
419environment, users, or groups; remove existing entries; replace entry types; or
420add or change mount entries on the already-running sandbox.
421
422This split lets the harness resume the agent loop while the sandbox provider
423restores or recreates the workspace. Current sample code for these paths lives
424in [`main.py`][sdk-example-sandbox-resume],
425[`sandbox_agent_with_remote_snapshot.py`][sdk-example-remote-snapshot].
426
427## Persist memory across runs
428
429Sandbox memory lets future sandbox-agent runs learn from prior runs. It's
430separate from SDK-managed conversational `Session` memory: sessions preserve
431message history, while sandbox memory distills useful lessons from prior
432workspace runs into files the agent can read later.
433
434Use memory when the agent should carry forward user preferences, corrections,
435project-specific lessons, or task summaries without replaying every previous
436turn. Resume and snapshots preserve workspace state; memory preserves reusable
437guidance about work that happened in the workspace.
438
439```python
440from agents.sandbox.capabilities import Filesystem, Memory, Shell
441
442agent = SandboxAgent(
443 name="Memory-enabled reviewer",
444 instructions="Inspect the workspace and retain useful lessons for follow-up runs.",
445 default_manifest=manifest,
446 capabilities=[Memory(), Filesystem(), Shell()],
447)
448```
449
450`Memory()` enables both reads and generation by default. Memory reads require
451`Shell` so the agent can search and open memory files. By default, live memory
452updates also require `Filesystem`, so the agent can repair stale memory or
453update memory when the user asks.
454
455Memory reads use progressive disclosure. The SDK injects `memory_summary.md` at
456the start of a run, the agent searches `MEMORY.md` when prior work looks
457relevant, and it opens rollout summaries only when it needs more detail.
458
459| Memory mode | Use it when |
460| ----------------------- | ----------------------------------------------------------------------- |
461| `Memory()` | The agent should read existing memory and generate new memory. |
462| `Memory(generate=None)` | The agent should read memory but not generate new memory after the run. |
463| `Memory(read=None)` | The run should generate memory without using existing memory. |
464| `MemoryReadConfig` | You need to disable live updates with `live_update=False`. |
465| `MemoryGenerateConfig` | You need to tune generation, such as `extra_prompt`. |
466| `MemoryLayoutConfig` | Agents need isolated memory layouts in the same sandbox workspace. |
467
468By default, memory artifacts live in the sandbox workspace:
469
470```text
471workspace/
472 sessions/
473 <rollout-id>.jsonl
474 memories/
475 memory_summary.md
476 MEMORY.md
477 raw_memories.md
478 phase_two_selection.json
479 raw_memories/
480 <rollout-id>.md
481 rollout_summaries/
482 <rollout-id>_<slug>.md
483 skills/
484```
485
486The runtime appends run segments during the sandbox session. When the session
487closes, memory generation first extracts conversation summaries and raw
488memories, then consolidates those raw memories into `MEMORY.md` and
489`memory_summary.md`. To reuse memory in a later run, preserve the configured
490memory directories by keeping the same live sandbox session, resuming from
491session state, starting from a snapshot, or mounting persistent storage such as
492S3.
493
494For multi-turn sandbox chats, use a stable SDK `Session` such as
495`SQLiteSession(...)` together with the same live sandbox session. Memory groups
496runs by `conversation_id`, then SDK `Session.session_id`, then
497`RunConfig.group_id`, and finally a generated per-run ID. The sandbox session
498ID identifies the live workspace; it's not the memory conversation ID.
499
500For runnable examples, see [`memory.py`][sdk-example-memory] for a local
501snapshot flow, [`memory_s3.py`][sdk-example-memory-s3] for S3-backed memory
502storage, and [`memory_multi_agent_multiturn.py`][sdk-example-memory-multi-agent]
503for separate memory layouts across agents.
504
505## Compose sandbox agents
506
507Sandbox agents compose with the rest of the SDK.
508
509Use a handoff when a non-sandbox intake agent should delegate only the
510workspace-heavy part of a workflow to a sandbox agent. The top-level run
511continues, but the sandbox agent becomes the active agent for the next turn.
512
513Use `agent.as_tool()` when an outer orchestrator should call one or more
514sandbox agents as nested tools. Each sandbox tool-agent can have its own
515`RunConfig(sandbox=SandboxRunConfig(...))`, sandbox client, manifest, and
516provider options.
517
518For examples, see [`handoffs.py`][sdk-example-handoffs] and
519[`sandbox_agents_as_tools.py`][sdk-example-agents-as-tools].
520
521## Sandbox providers
522
523Start with Unix-local for fast local iteration or Docker when you want local
524container isolation. Move to a hosted provider when the task needs managed
525execution, provider-specific isolation, scaling, previews, storage mounts,
526snapshots, or credentials that should live outside your application server.
527
528Use provider docs for provider-specific setup, credentials, isolation, storage,
529previews, and persistence behavior.
530
531| Provider | SDK client | Documentation and examples |
532| ---------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
533| Blaxel | `BlaxelSandboxClient` | <a href="https://docs.blaxel.ai/Sandboxes/Overview">Sandbox overview</a> |
534| Cloudflare | `CloudflareSandboxClient` | <a href="https://developers.cloudflare.com/sandbox/">Sandbox documentation</a><br /><a href="https://docs.cloudflare.com/sandbox/tutorials/openai-agents/">OpenAI Agents tutorial</a><br /><a href="https://github.com/cloudflare/sandbox-sdk/tree/main/bridge/examples">Sandbox Bridge examples</a> |
535| Daytona | `DaytonaSandboxClient` | <a href="https://www.daytona.io/docs/en/sandboxes/">Sandbox documentation</a><br /><a href="https://www.daytona.io/docs/en/guides/openai-agents/openai-agents-sdk-with-sandboxes">OpenAI Agents SDK guide</a> |
536| Docker | `DockerSandboxClient` | <a href="https://docs.docker.com/">Docker documentation</a><br /><a href="https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/docker/docker_runner.py">Docker SDK example</a> |
537| E2B | `E2BSandboxClient` | <a href="https://e2b.dev/docs">Sandbox documentation</a><br /><a href="https://e2b.dev/docs/agents/openai-agents-sdk">OpenAI Agents SDK guide</a><br /><a href="https://e2b.dev/blog/e2b-is-now-in-agents-sdk">Launch blog</a> |
538| Modal | `ModalSandboxClient` | <a href="https://modal.com/docs/guide/sandboxes">Sandbox guide</a><br /><a href="https://modal.com/blog/building-with-modal-and-the-openai-agent-sdk">Integration blog</a><br /><a href="https://github.com/modal-labs/openai-agents-python-example">Example repo</a><br /><a href="https://github.com/modal-labs/openai-agents-python-example?tab=readme-ov-file#modal-extension-reference">Modal extension reference</a> |
539| Runloop | `RunloopSandboxClient` | <a href="https://docs.runloop.ai/docs/devboxes/overview">Devbox overview</a><br /><a href="https://docs.runloop.ai/docs/devboxes/tunnels">Tunnels</a> |
540| Unix-local | `UnixLocalSandboxClient` | <a href="https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/unix_local_runner.py">Local SDK example</a> |
541| Vercel | `VercelSandboxClient` | <a href="https://vercel.com/docs/vercel-sandbox">Sandbox documentation</a><br /><a href="https://vercel.com/kb/guide/building-an-agent-with-openai-agents-sdk-and-vercel-sandbox">OpenAI Agents SDK guide</a><br /><a href="https://vercel.com/templates/template/openai-agents-sdk-with-fastapi">FastAPI template</a><br /><a href="https://github.com/vercel-labs/openai-agents-fastapi-starter">Sample app</a> |
542
543[sdk-example-agents-as-tools]: https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/sandbox_agents_as_tools.py
544[sdk-example-basic]: https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/basic.py
545[sdk-example-dataroom]: https://github.com/openai/openai-agents-python/tree/main/examples/sandbox/tutorials/dataroom_metric_extract
546[sdk-example-dataroom-qa]: https://github.com/openai/openai-agents-python/tree/main/examples/sandbox/tutorials/dataroom_qa
547[sdk-example-docker-runner]: https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/docker/docker_runner.py
548[sdk-example-handoffs]: https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/handoffs.py
549[sdk-example-memory]: https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/memory.py
550[sdk-example-memory-multi-agent]: https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/memory_multi_agent_multiturn.py
551[sdk-example-memory-s3]: https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/memory_s3.py
552[sdk-example-remote-snapshot]: https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/sandbox_agent_with_remote_snapshot.py
553[sdk-example-repo-code-review]: https://github.com/openai/openai-agents-python/tree/main/examples/sandbox/tutorials/repo_code_review
554[sdk-example-sandbox-resume]: https://github.com/openai/openai-agents-python/tree/main/examples/sandbox/tutorials/sandbox_resume
555[sdk-example-unix-local-runner]: https://github.com/openai/openai-agents-python/blob/main/examples/sandbox/unix_local_runner.py
556[sdk-example-vision-clone]: https://github.com/openai/openai-agents-python/tree/main/examples/sandbox/tutorials/vision_website_clone
