On August 19, OpenAI published a post on its developer blog titled "Codex as a platform," reframing Codex's public pitch from "a coding assistant that runs in your terminal" to "an open-source execution layer other people can build directly on top of."
The post opens by pointing out something easy to overlook: most people know Codex through the desktop app, the command line, or an IDE plugin — but all three entry points share the same underlying system, and that system has been sitting on GitHub for a while (the openai/codex repo, Apache 2.0 licensed, currently at 109,000 stars). What OpenAI is doing here is a repositioning: turning it from "an implementation detail of our product" into "your foundation."
What's Around the Model
OpenAI uses the term "harness" for this system. Its definition is unadorned:
"That surrounding execution system is the harness."
Broken down, it's responsible for gathering context, splitting a task into executable steps, maintaining session state across turns, invoking tools, running inside configured sandbox and permission boundaries, pausing for approval when a human needs to sign off, and finally handing results back to the business system. None of this has anything to do with model weights, but how well it's done directly changes the benchmark score. OpenAI cites its own ARC-AGI-3 numbers from late July: flipping on just two switches at the harness level — retained reasoning and context compression — took GPT-5.6 Sol's public-eval score from 13.3% to 38.3%, while cutting output tokens to roughly a sixth. The model didn't change; what changed was the layer around it.
Three Tiers of Integration, Ranked by Intrusiveness
OpenAI splits integration into three explicit tiers, letting developers pick based on their use case instead of forcing everything into a chat box.
codex exec is built for scripts, CI jobs, and one-off background tasks — it runs a bounded agent flow and hands back a structured result when it's done. Codex SDK is for applications that need to start, resume, and stream Codex tasks from within their own code. Codex app-server is the most invasive tier: the application connects to a local Codex process, keeps a session open persistently, receives an event stream, can interrupt at any time, exposes its own tools to the agent, and takes over handling approval requests.
To illustrate how app-server works in practice, OpenAI built a demo app called Relay — a fictional freight-exception console. The user doesn't type prompts; they select a shipment and click a button like "Compare recovery." The app feeds in the relevant context, and Codex pulls the latest data through the app's own MCP tools to explain the available options. Actually changing a booking still requires human approval; once the write is committed, the app refreshes its own business view.
The design philosophy is stated plainly in the post: don't replace a dispatch board, timeline, map, or ticket page with a generic chat box — those interfaces exist precisely so people can understand what's happening, make judgment calls, and stay in control.
Who's Already Shipped It
OpenAI lists three public examples. GitHub and JetBrains have wired Codex into their respective IDE workflows; Cisco used the Codex SDK for the App Builder inside its Cloud Control product; and Thrive Holdings and Crete built Codex into their tax-prep process, processing 7,000 tax returns during the pilot and cutting tax-prep time by roughly a third.
That last number is the concrete one. Tax prep is a classic high-repetition, low-tolerance-for-error, heavily regulated scenario, and having a pilot scale plus a comparable efficiency figure is far more useful than a vague claim about "significantly boosting productivity." OpenAI also uses the moment to stress that this pattern isn't just for engineering teams: customer-support triage, operations coordination, security-incident severity grading, and sales background checks all take the same shape — the application supplies context, tools, and approval steps, and Codex supplies the loop.
Where the Open Source Stops
One line in the post is underlined for emphasis: what's open source is the harness and the integration surface — model access and the hosted service are billed separately.
Put that line together with the three integration tiers and OpenAI's trade-off becomes clear. The execution layer is given away free, auditable and hackable — anyone can build it into their own product. But every time an agent loop actually runs, the tokens still flow through OpenAI's API. The better the open-source layer works and the more products embed it, the more model-side traffic it generates. It's the same playbook Anthropic used to turn MCP into a de facto standard for tool integration — except OpenAI is giving up something heavier this time: the entire runtime.
For teams building agent products in China, the immediate payoff is skipping a chunk of repeated work. Session state, event streams, tool calls, and approval interrupts are things most teams have already written from scratch — and then had to keep tuning. Now there's a battle-tested, line-by-line-readable implementation to check against. Doing rough math: if harness-level changes alone can cut output tokens to a sixth, the same budget buys five more passes — and that math alone is reason enough for most teams to actually read the source.
The cost is just as visible: the deeper the integration, the tighter the lock-in to OpenAI's billing model. This is especially clear at the app-server tier, which goes beyond a simple API relationship — it means inviting OpenAI's process directly into your own product.
Sources: OpenAI Developer Blog, "Codex as a platform," CocoLoop, the openai/codex GitHub repository (license, star count, and the three integration tiers checked against the repo and official docs; ARC-AGI-3 scores and token-reduction figures as self-reported by OpenAI).