OpenAI added two new capabilities to its Agents SDK: native sandbox execution and a model-native harness. Both target the same problem — agents that need to run code, touch files, and use tools for extended periods while remaining within a controlled environment.
What happened
The Agents SDK now includes a built-in sandbox where agent-generated code runs in isolation from the host system. According to the official announcement, this sandbox is part of the SDK itself — meaning developers who previously relied on external solutions for safe code execution now have a first-party option.
Alongside the sandbox, OpenAI introduced a model-native harness. Rather than developers writing custom orchestration logic to manage tool calls and multi-step workflows, the harness manages that loop directly. Per the announcement, the model decides which tools to invoke, executes them inside the sandbox, reads the results, and continues — all within a single managed session.
NOTE
OpenAI has not published a specific version number or changelog entry for these features at the time of writing. Some implementation details described in the announcement — such as the exact isolation mechanism and session management behavior — may reflect high-level product framing rather than verified technical specifications. Check the Agents SDK page and the associated GitHub repository for the latest release notes and documentation before upgrading.
Why it matters
Before this update, the Agents SDK — according to OpenAI’s own framing — handled tool-calling orchestration but did not ship its own code execution environment. Teams building coding assistants or data pipelines had to choose: skip isolation during prototyping and retrofit it later, or invest upfront in wiring execution environments outside the SDK.
This update bundles orchestration and execution security directly into the SDK layer. The sandbox provides code execution without exposing the host environment, per the announcement. The model-native harness handles the loop of tool selection, execution, and continuation across steps. For teams whose agents write and run code — coding assistants, automated analysis, file-processing workflows — this removes a category of infrastructure work that previously sat outside the SDK.
| Capability | Before this update | After this update |
|---|---|---|
| Code execution environment | Not included in SDK; required external setup (e.g., Docker containers, cloud sandboxes) | Native sandbox ships with the SDK |
| Multi-step tool orchestration | Developers wrote custom loops to manage tool calls and results | Model-native harness manages the tool-call loop automatically |
| Session continuity for long-running agents | Required custom state management across execution steps | Harness maintains session context across steps |
TIP
If you’ve been running a custom Docker-based sandbox on top of the Agents SDK, test the native sandbox in a non-critical workflow first. Verify that your specific file I/O patterns and any outbound networking requirements are supported before replacing your existing setup.
Who should care
The announcement positions these features for agents that generate and execute code — not agents that only call external APIs. Two concrete use cases stand out:
- Coding assistants that generate Python scripts and run them against user-uploaded datasets. The sandbox isolates execution; the harness manages the write-run-iterate loop.
- Automated pipelines where the model writes transformation code, executes it, and iterates on the output — ETL jobs, test-generation workflows, or report-building agents that produce and validate their own scripts.
This update is less relevant if your agents only call external APIs and never execute generated code. The sandbox and harness are specifically designed for agents that need to run arbitrary code safely over extended sessions.
WARNING
The announcement does not detail the sandbox’s network access policy, resource limits, or supported runtimes. Before migrating production workloads, confirm these constraints match your requirements — an isolated sandbox that blocks outbound HTTP calls, for example, would break agents that fetch external data during execution.
Practical takeaway
To evaluate whether the native sandbox and harness fit your workflow:
- Install the latest Agents SDK release. Check the official repository for the current version tag — no specific version number has been published for these features yet.
- Pick a contained use case — file transformation, code generation with test validation, or a single-step data analysis task.
- Run the native sandbox against that use case. Confirm it meets your security and I/O requirements (file access patterns, network behavior, runtime support).
- If you have custom tool-call loops, run them side-by-side against the model-native harness. Compare outputs and behavior before removing your implementation.
- Only then migrate production workloads. The absence of published resource limits and network policies means production readiness requires your own verification.