Update — August 31, 2026: Simon Willison's ChatGPT Work tools & skills reference dumps 232 tool interfaces and 44 bundled skills from a live Work session — a practical inventory of what this harness exposes to end users before you embed it via app-server.
Update — August 25, 2026: Tan's August 24 thread argues systems of record must ship AI harnesses or lose to agents — the same embed-the-loop thesis OpenAI pitched here, applied to vertical SaaS.
Most developers who've used Codex have used it through the app, the CLI, or the IDE extension — three different front doors onto the same building. On August 19, 2026, OpenAI Developers published Codex as a platform: build on the open agent harness, by Nicolas Bonamy and Derrick Choi, making the case that the building itself — the open-source Codex harness — is the thing worth building on, not the three doors.
The framing matters because it's a different pitch than "use our coding assistant." It's "embed our agent loop in the product you already have." That's the same territory explainx.ai has been tracking since our agent harness explainer and harness engineering roundup — and it puts Codex in more direct comparison with Anthropic's Claude Agent SDK than the standalone CLI ever was.
TL;DR — codex exec vs Codex SDK vs Codex app-server
| Question | Answer |
|---|---|
| What's actually open source? | The Codex CLI, the app-server, and the official Codex SDK. Model access and managed services are separate. |
| Do I need a subscription? | Yes, for inference — the harness code is free to inspect and modify, but you still authenticate to a model. |
codex exec — what's it for? | Scripts, CI jobs, one-off bounded background tasks that need structured output and no persistent UI. |
| Codex SDK — what's it for? | Application code that needs to programmatically start, resume, or stream Codex tasks. |
| Codex app-server — what's it for? | The agent is part of the product itself: persistent conversations, streamed events, interruption, exposed tools, approval-request handling. |
| How is this different from just calling the OpenAI API with function calling? | The harness already handles context-gathering, multi-turn state, sandboxing, and approval flows — you'd otherwise build all of that yourself on top of raw function calling. |
| Comparable to Claude Agent SDK? | Directionally yes — both let an app own the interface/tools while the harness runs reasoning, tool use, and approvals. See explainx.ai's Claude Code commands reference for the Anthropic-side equivalent surface. |
| Comparable to MCP? | Not a competitor — MCP is the tool-exposure protocol both Codex and Claude-based agents can call into. Read what MCP actually is. |
What the harness actually does
OpenAI's post is explicit that the model is not the whole story: "A capable agent is more than a prompt and a model response. It needs a way to understand a task, maintain context over time, inspect relevant information, call tools, expose progress, handle failures, request human approval when necessary, and return a useful result." That's the harness's job, not the model's — context-gathering, reasoning through tasks, tool use, operating within configured boundaries, requesting approval, and carrying work forward across turns.
The claim that this layer materially matters — not just architecturally, but for raw benchmark performance — comes with a number. On ARC-AGI-3, adding retained reasoning and context compaction to the harness lifted GPT-5.6 Sol's score from 13.3% to 38.3%, while cutting output tokens 6x. Same model. Different harness. That's the strongest piece of evidence in the post for why "harness engineering" deserves the same attention as prompt engineering or model selection — a theme explainx.ai covered from the framework side in Terminal-Bench and harness engineering.
The three integration layers, in practice
OpenAI splits developer access into three tiers depending on how deeply the agent needs to live inside a product:
codex exec— a single CLI invocation for scripts, CI pipelines, or bounded background jobs. You get structured output back; there's no persistent session to manage. This is the right layer if a workflow just needs "run this task, give me the result" without a UI.- Codex SDK — the official SDK for application code that needs to start, resume, or stream Codex tasks programmatically, without owning the full conversation protocol. This sits between a one-shot CLI call and a fully custom UI.
- Codex app-server — the documented client protocol for when the agent is a first-class part of the product: creating threads, starting turns, receiving streamed events, and handling approval requests. The app-server manages conversation state, streams execution, enforces sandbox and approval policies, and carries work across turns — the full harness, exposed as a protocol your app talks to directly.
Because the harness is open source, developers can inspect the layer sitting between their app and the model and adapt it. OpenAI frames that control across three axes: the interface (keep your existing dashboards, editors, or ticket queues instead of forcing users into a generic chat window), context and tools (expose the systems, documents, and actions that actually matter, including app-owned MCP services), and operational boundaries (where the agent runs, what it can touch, what needs a human approval, how work gets observed, and how results land back in the system of record).
Relay: OpenAI's own worked example
To make the pattern concrete, OpenAI built Relay, a sample operations app on top of Codex app-server. It sits an agent beside a fictional shipment dashboard, wires it to app-owned MCP tools, and requires human approval before any consequential action — like rebooking a shipment — actually executes.
The interaction model is deliberately not a blank prompt box. A user clicks a suggested action, such as "Compare recovery options," and the app supplies the relevant context. Codex retrieves live operational data through the MCP tools, explains the available options, and any write action routes through an approval step before it runs. Once approved, the app refreshes its own view of the record. The underlying data is seeded and fictional, but OpenAI describes the integration pattern as general — the same shape could power incident response, account operations, or research workflows for other teams.
How this compares to Claude Agent SDK and MCP
Readers who've built with Anthropic's tooling will recognize the shape immediately. The Claude Agent SDK and Claude Code's own command surface (covered in explainx.ai's Claude Code commands reference) solve a nearly identical problem: let an application keep its own interface and own its own tools, while a harness runs the reasoning loop, manages multi-turn state, and gates consequential actions behind approval.
MCP isn't a rival architecture to either — it's the tool-exposure protocol that both ecosystems can plug into. OpenAI's own post name-checks "app-owned MCP services" as one of the three levers developers control, which lines up with how explainx.ai has covered MCP as the standard for exposing tools to agents and the practical tradeoffs of MCP tool descriptions on selection reliability. The real decision for a builder isn't "Codex or MCP" — it's which harness's approval and context model fits the product, and whether MCP is how you'll wire in tools either way.
The genuinely new piece here, versus OpenAI's earlier Codex coverage, is the app-server protocol as a documented, stable target. explainx.ai has tracked Codex's CLI and plugin surface before — see the Codex plugin for Claude Code and Codex slash commands reference — but those are about using Codex as a tool inside another harness, not embedding Codex's own harness inside a third-party product. This post is squarely about the latter.
Real deployments cited
OpenAI names several production integrations beyond Relay's demo:
- GitHub and JetBrains bring Codex into existing IDE workflows rather than a separate app.
- Cisco uses the Codex SDK inside "App Builder," part of Cisco Cloud Control.
- Thrive Holdings and Crete built a tax-preparation workflow around Codex that incorporates practitioner feedback loops. The pilot processed 7,000 returns and cut prep time by roughly a third — the most concrete productivity number in the post.
OpenAI frames the pattern as applicable well beyond engineering teams: support teams investigating customer issues, ops teams coordinating workflows, security teams triaging incidents, sales teams researching accounts, and marketing teams developing campaigns. In each case, the application owns context, tools, and approvals, while Codex runs the agent loop underneath.
What people are asking
"Why not just use the Codex app for this?" Because the app is one specific interface choice — a general-purpose chat window. OpenAI's actual argument is that dashboards, timelines, maps, and record systems are how people already understand and stay in control of their work; replacing them with a universal chat box is a regression, not an upgrade. The opportunity is giving those existing interfaces an agent, not replacing the interfaces.
"Is app-server overkill for what I'm building?" If the task is a single bounded job with a clear output — a CI check, a batch migration, a scheduled report — codex exec is the right layer and app-server is overkill. App-server earns its complexity when the agent needs to persist across a session, stream progress, and pause for human approval mid-task, the way Relay does.
"Does this replace function calling against the raw OpenAI API?" Not exactly — it sits above it. Raw function calling still requires you to build multi-turn state management, sandboxing, retry logic, and approval gating yourself. The harness bundles that scaffolding; you're trading some control for not re-implementing it.
"Is this locked to GPT models?" The post is scoped to Codex and OpenAI's own models — it doesn't claim model portability. If you need harness code that's model-agnostic by design, that's a differentiator worth checking against alternatives before committing.
The bottom line
The News here isn't a new model or a new UI — it's OpenAI formally endorsing a build pattern that developers were already reverse-engineering: treat Codex's harness as infrastructure, not as a locked-in app. Combined with the ARC-AGI-3 harness-design number, it's a signal that OpenAI expects the next round of competitive differentiation to happen at the orchestration layer, not just the model layer — the same bet Anthropic has been making with the Claude Agent SDK and MCP.
Related reading
- Update — Aug 28, 2026: Code for a new "Persistent mode" always-on agent surfaced in the Codex CLI repo — the next step past the open-harness model this post covers.
- NVIDIA AVO hits 100% on ARC-AGI-3 (public set) — same memory + supervisor harness pattern, applied to GPU kernels first
- ChatGPT Sites team editing — invite editors, Git versions, URL rename (Aug 21)
- What is an agent harness? The scaffolding layer explained
- Agent harness engineering: Terminal-Bench and LangChain
- What is MCP? The Model Context Protocol guide
- Claude Code commands: complete reference guide
- OpenAI Codex plugin for Claude Code
- Codex Multi-Agent V2: delegation changes
- Codex slash commands: complete reference
- Official source: Codex as a platform, developers.openai.com
Version specs, cited figures, and integration details reflect OpenAI's August 19, 2026 announcement as understood at the time of publication; check OpenAI's developer docs for the current state of the Codex SDK and app-server protocol.