Cloudflare says OpenAI Codex can run on Durable Objects. Its developer account posted about it on 11 November and reached for a familiar line from the Agents SDK docs: Codex can run “the way it runs on your laptop.” The code attached to that post belongs to another experimental example, the one that landed in a 9 November changelog.
“Run OpenAI Codex on Cloudflare, with its tools and configuration, the way it runs on your laptop.”
— Cloudflare, in the Codex harness docs
What a Durable Object is
A Durable Object is a special kind of Cloudflare Worker that pairs compute with its own storage. Like a regular Worker, it starts near the first request, comes up quickly, and shuts down when idle. You can have millions of them. What sets one apart is that it has a name, and it can remember.
Each object has a globally unique ID. Requests for that ID, from anywhere, go to the same instance, and only one of those IDs runs at a time. The instance is single-threaded. It can pause mid-task to let other work in, much as a web browser does, and that is how it coordinates work without a separate lock service. New objects use a SQLite-backed store that is private to that instance, transactional and strongly consistent. In-memory values can speed things up, but they’re wiped if the object hibernates, so anything that has to last belongs in storage.
A plain Worker is stateless. Each request may run on a different instance, with no shared memory. The usual pattern is simple: the Worker handles auth and routing, then hands the stateful work to a Durable Object.
Think of a Durable Object as a named office with one clerk and a locked filing cabinet. Anyone can find that office by its number. The clerk deals with one job at a time, so two people can’t overwrite the same file at once. The cabinet stays put even when the clerk steps out.
When the object has been idle for a short time and is eligible, the runtime can hibernate it. Clients can stay connected over WebSockets while the object itself leaves memory. Duration charges don’t accrue during that sleep. A later message or request wakes it, and the constructor runs again. Alarms let the object schedule a wake-up of its own, so you can do work later without a separate job runner. Alarms don’t repeat by themselves, and the docs say they can run a little late if maintenance or failover is under way.
How builders use them
Cloudflare tells builders to model each object around one “atom” of coordination: a chat room, a game session, a document, a user’s data, or a tenant’s workspace. Official examples include chat rooms and multiplayer games, where one object holds the room and WebSockets fan updates out to everyone in it.
Liveblocks, in a Cloudflare customer story, built collaboration rooms this way. When users connect over a WebSocket, they’re forwarded to a Durable Object that holds the room’s state, and an update is shown to everyone in the room. In that story, Jonathan Rowny, a principal software engineer at Liveblocks, said developers don’t have to design CRDTs or operational transforms for that path.
PartyKit was built on Durable Objects to make the same room-and-connection model easier to use. Cloudflare acquired the project in 2024, and PartyServer now runs as a regular Worker with Durable Objects.
For a strict rate limit across locations, Cloudflare’s Workers docs recommend a Durable Object per credential, with the counter checked and updated together in storage.
The Agents SDK treats each agent as a Durable Object. Routing sends the request to the right one. The agent gets a durable identity and local SQL storage. It can hold real-time connections, schedule work through the Lifecycle and a Scheduler, and recover after eviction. MCP can sit alongside this. The current recommended MCP handler is stateless, and anything that must survive a request can live in a Durable Object or an Agent. An older API, McpAgent, put the MCP server itself on a Durable Object. Cloudflare has deprecated it.
How Codex runs on them
Codex’s own docs were last touched on 10 November. They describe an experimental ContainerHarness and a codex() preset, where the official OpenAI Codex CLI runs in a Linux container and a Durable Object drives it. The CLI owns the loop, so you get its native tools, plugins, settings and session format. The Durable Object owns the record: sessions, operations, transcripts and the CLI’s session files, held in the object’s SQLite database.
Credentials stay outside the container. The CLI is handed a placeholder host and key, and ContainerEgress adds the real credentials after the request has left. There’s no Dockerfile. The harness boots from cloudflare/debian-trixie, installs Codex the first time it’s used, then snapshots the filesystem.
If the Durable Object is evicted or redeployed, Lifecycle reattaches to the running container and replays missed events. After five minutes idle, the harness takes a snapshot and stops the container. The next prompt restores that snapshot and picks the CLI session back up. Should the container die mid-turn, the session itself survives, with status “unanswered” and reason “container_lost”. Set onContainerLost to “retry” and the harness reruns the turn when side effects are safe. Files written after the last snapshot can still be lost, so anything that has to last belongs in separate durable storage.
Cloudflare treats the container as the sandbox. The Codex path, and a claudeCode() preset on the same harness, run without the CLIs’ usual permission prompts. According to the docs, everything in the container should be treated as readable by the agent, credentials should stay out, and every route to the harness should sit behind auth. Each prompt can run commands and spend model credit. Tokens used in setup stay in the snapshot.
The setup needs Node.js 24 or later, the Cloudflare CLI, an OpenAI API key, and Docker for local containers. AI Gateway is optional, and Unified Billing works with it. Cloudflare’s agents repository already has a container harness example. The API is experimental and may change.
The 9 November changelog is a different design. It walks through an experimental Agents SDK example that takes Codex’s Rust turn-processing, compiles it to WebAssembly, and runs the loop inside the Durable Object. Tasks, Sessions, Streams and a Workspace come with it, and the sample calls a model such as openai/gpt-6.1-sol through AI Gateway. That’s the design in the code Cloudflare posted on 11 November.
Matt Carey works on agents and MCP at Cloudflare. On 9 November he called getting the harnesses running “a fun challenge,” and said he’d “had to pull out the wasm for OpenAI Codex.” The next day he added that he wasn’t sure people should use the wasm version yet. Pi Durable, he said, would be more stable on Durable Objects.
Back in September, Cloudflare wrote up Cloudflare Containers as execution environments for the OpenAI Agents API. In that arrangement OpenAI still manages sessions and orchestration.
The harness comparison page was updated on 10 November as well. It lists Codex as experimental: a Linux container driven by a Durable Object. Durability is mixed. The object can reattach after a restart, but if the container is lost the run fails or retries. This path has no built-in Cloudflare Computer integration.
Container path or Wasm path
| Path | Where the loop runs | What persists | Limits |
|---|---|---|---|
| Container CLI | The official Codex CLI in a Linux container, driven by a Durable Object | Sessions, transcripts and CLI session files in the object’s SQLite store, plus filesystem snapshots | Experimental. Idle snapshot after five minutes. Files written after the last snapshot can be lost. No built-in Cloudflare Computer integration. |
| Wasm loop | Codex turn-processing compiled to WebAssembly, run inside the Durable Object | The 9 November changelog says conversations and files survive restarts | Experimental. Matt Carey has said this path may be less stable than Pi Durable. |
What running Codex on Durable Objects makes possible
These are patterns the documented APIs already allow, within their limits. Cloudflare and OpenAI haven’t shipped them as products.
Give the object a user ID, and you have a per-user coding agent. The Durable Object keeps that person’s sessions, transcripts and CLI session files in its SQLite store. On the container path, an idle agent can snapshot and stop, then come back on the next prompt.
Alarms, and the Agents SDK Scheduler, make background or scheduled runs possible. The object can wake later to continue a job, check a pull request, or retry work. Alarm handlers should be safe if they fire twice, and the Codex container docs warn that a retry can rerun a turn if side effects aren’t safe.
Because the record lives with the object, an agent can keep state between sessions, even if the Durable Object is evicted and later reattached. The Wasm changelog makes the same claim for conversations and files across restarts. On the container path, files written after the last snapshot can still vanish, so anything that must survive belongs in separate durable storage.
Multi-tenant sandboxes follow the same rule. You give each tenant, repo or pull request its own object, and on the container path its own container, each with private storage. Funneling every tenant through a single object is the bottleneck the docs warn against. Every route to the harness should sit behind auth, and everything in the container should be treated as readable by the agent.
A pull-request bot can be a Worker that receives a webhook and routes it to a Durable Object for that repo or PR, then uses alarms for follow-ups. The Agents SDK already documents Slack, email and webhook channels. That’s a pattern, not a Codex bot Cloudflare has shipped.
Storage is colocated with the object and private to it. On the container path the CLI still runs in a Linux sandbox driven by the Durable Object, and that path has no built-in Cloudflare Computer integration. Keep credentials out of the container. Model credit is still spent whenever a prompt runs.
An idle Durable Object that is eligible for hibernation isn’t billed for duration. The container path also snapshots and stops the container after five minutes idle, so a running sandbox isn’t sitting there while nobody is prompting. Once work starts again, duration and model usage resume. Tokens placed in setup stay in the snapshot.
In short
A Durable Object is a named, single-instance Worker with its own SQLite-backed storage. There’s one per ID, it’s globally unique, and it’s single-threaded. Builders already use that primitive for chat rooms, multiplayer, collaboration, rate limits, agents and per-tenant state.
Codex can run on it in two experimental ways: the official CLI in a container driven by the object, or a WebAssembly port of the loop inside the object. Persistent, scheduled and multi-tenant coding agents are possible from those APIs, within the published limits.
Discover more from Sulat AI & Tech News
Subscribe to get the latest posts sent to your email.
