On September 10 OpenAI put the Codex harness behind a public Agents API. The launch post says you pick the compute: an OpenAI sandbox, your own machine, or a partner like E2B, Modal, Cloudflare, or Vercel. Superpower Daily and InfoWorld both flagged the data catch the next day. Today @DonizetiFerre16 restated it in one line, and @JennieTechWorld was still walking through the beta. OpenAI’s own overview is the source. Data residency is the United States only. Zero Data Retention is not supported. Choosing a self-hosted sandbox does not make the API ZDR-eligible.
I wrote on the 12th that a sandbox that can publish a gem is not a sandbox. This is the other hole. You can move the files. You cannot move the session.
What they let you host
The product is four objects: an agent, an environment, a session, and the events that session streams back. The environment is the part they will let you run. Self-hosted means you start codex exec-server in a laptop, a container, or a remote box. That process connects outbound to OpenAI for commands and results. Your application API key stays outside the box. A restricted executor key goes in.
That is a real split. Code and working files can sit in a VPC. Partners will run the same executor in their regions. OpenAI’s lifecycle docs tell you to delete the session and stop the compute as two separate acts. Deleting a session does not stop the environment. Stopping the environment does not delete the session.
Hosted sandboxes have a third copy. Files under the output directory become artifacts after a turn. Superpower Daily went through eleven configurations on the 11th. Workspace files last while the sandbox exists. Published artifacts last after it expires. Deleting one does not delete the other.
None of that is the session.
What they kept
The data controls table is the honest page. /v1/agents is not used for training. Abuse monitoring logs sit for 30 days. Application state is retained until you delete it. The Zero Data Retention column is No. Eyes Off is No. Chat completions can be ZDR-eligible. The Agents API is listed with Assistants and threads, the endpoints that exist to remember.
The overview says the same thing in prose. The API retains session state so you can continue work across turns without rebuilding context. That sentence is the product. Compaction, recovery, subagents, and resume only work if OpenAI holds the loop. A self-hosted sandbox still sends tool results back into that loop. The files can be yours. The diary of what the agent did is not.
I do not need a theory of Private Safety Processing for this. OpenAI previewed that in August for frontier models that do support ZDR. The Agents API is not on that list. @HarrisonAIx posted today that the launch unlocked the Codex harness under strict ZDR SLAs. The docs say the opposite.
US-only residency is the other constraint. If your contract says the prompts stay in the EU, this endpoint is the wrong product. Moving the executor to Frankfurt does not move the session.
The May agents I wrote about on the 12th already showed what a managed loop can reach when publish is on the allowlist. The new API is that loop as a product. The sandbox choice is where the shell runs. It is not where the memory lives.
Keep the loop off their disk
The useful control is not a partner logo on the sandbox. It is whether the agent loop is a process you can kill and a file you can delete.
Local models still do not give you Astra. They do give you a session that is a directory. If the work is a coding agent on a repo you already have, the harness can be the open Codex code on a machine you own, talking to a model you host, with a log you can shred. That is slower. It is also the only setup where “self-hosted” is a complete sentence.
If you still call the API, use the endpoints that are actually ZDR-eligible, and do not start a session object for a task that was a single completion. Durable is a synonym for retained.
A sandbox you run is not a session you hold. The table already said No.