OpenAI Releases Agents API in Public Beta, Offering a Managed Codex Agent Runtime

OpenAI’s Agent Sandbox Docs Show Three Separate File Cleanup Lifecycles

OpenAI’s Agents API environment documentation divide file storage and cleanup across different systems, a Superpower Daily review of 11 execution configurations found. Hosted sandboxes keep working files while the environment exists, publish separate output artifacts that can outlive it, and can use Files API objects with their own retention rules. Self-hosted files instead stay outside OpenAI’s Artifacts API. OpenAI manages the agent harness while customers select where code executes, so a builder’s cleanup policy must account for both the managed service and the chosen environment.

The analysis covered OpenAI-hosted execution, generic self-hosted customer infrastructure, and nine named integrations: Modal, Cloudflare, Vercel, Daytona, Blaxel, E2B, Runloop, DigitalOcean, and Oracle Cloud Infrastructure. It was limited to public documentation available by September 11 and excluded private contractual controls, so the finding describes the documented launch choices rather than every possible commercial arrangement. This is a comparison of documented behavior, not a live test of deletion guarantees. It does not assume that a provider’s available regions determine where OpenAI retains session data, or that ending a compute session removes every output copy. The review treats execution, session storage, and published files as separate questions.

The OpenAI-hosted option is the more integrated route for file work. It gives each session a Linux workspace, lets agents receive files and produce outputs, and publishes files saved under its output directory as immutable artifacts after a turn completes. Workspace files persist across turns while the sandbox exists, while published artifacts remain downloadable after the sandbox expires.

A published artifact is separate from its source file: deleting the artifact does not remove the file that remains in the environment. Conversely, the expiry of the sandbox does not remove published output artifacts. Teams handling sensitive inputs and outputs therefore need to inventory both the working files and the copies exposed for download, rather than treating a completed agent turn as evidence that its files have disappeared.

The hosted sandbox itself can be deleted after an hour without activity and keep-alives, according to OpenAI’s documentation. Deleting a session requests sandbox cleanup, but published output artifacts survive expiry and must be deleted separately when they are no longer needed.

Self-hosted and partner environments offer a different file arrangement. Their files are retrieved through the provider’s file interface or a mounted filesystem, not through OpenAI’s Artifacts API. That keeps the execution environment’s filesystem outside that OpenAI artifact service, while leaving the customer or provider to manage its own storage and cleanup process.

That responsibility extends to lifecycle management. OpenAI’s Cloudflare integration, for example, says an application must clean up the provider sandbox and delete the Agents API session separately for immediate cleanup. It also cautions that reconnecting an offline executor does not itself restore files from a previous container. A customer-managed runtime can therefore offer placement and storage control, but it requires explicit provisioning, recovery, and deletion policies.

OpenAI directs teams that need their own image, compute, or private network toward self-hosting rather than an OpenAI-hosted sandbox. That gives customers a concrete execution-side choice without requiring an assumption about what every partner offers. The documentation describes the hosted option as a managed Linux workspace; the self-hosted route instead requires the customer to provision and run an executor.

OpenAI hosts and maintains the Agents API harness, while customers choose where the agent executes. In a self-hosted deployment, a customer runs an executor in its selected environment. That executor runs shell commands, reads and writes files, and connects outbound to OpenAI to receive commands and return results.

The customer’s environment also needs its own access boundary. OpenAI advises isolating environments by user or workload because agents that share one can access the same files and credentials. It requires a restricted executor key and says to keep the broader application API key outside the workspace. That restricted key can be read by agent-generated code, but it only permits connecting environments.

The compliance boundary remains important context, though it is not a new promise in these environment guides. OpenAI’s launch documentation already states that Agents API sessions and its managed harness are U.S.-resident and not eligible for Zero Data Retention. Selecting a different place to execute code does not change those terms. The documented file-handling choices explain an additional operational question: which system holds each copy, and which deletion action reaches it.