Codex as a platform: build on the open agent harness | OpenAI Developers

Justy Okay, so OpenAI just open-sourced the thing that actually matters about Codex—not the app, not the CLI, but the harness underneath. The execution layer. And I think this is a big deal because it finally cuts the knot on the question we've been circling for like two years.

Cody Right.

Justy Which is: do agents live in a chat box, or do they live in the tools people already use?

Cody Mm-hm, yeah. So what's actually in the harness?

Justy It's the stuff between your application and the model. Conversation state, tool calls, sandbox policies, approval flows—all the plumbing that makes an agent work. Harness design actually changes results: on ARC-AGI-3, retained reasoning and context compaction took GPT-5.6 Sol from thirteen point three percent to thirty-eight point three percent while cutting tokens by a factor of six.

Cody That's a good signal that the engineering is real, not just cosmetic.

Justy Exactly. And they're shipping three integration paths. For a one-off job, you use codex exec—bounded workflow, returns structured output. For programmatic stuff, there's the SDK. For product work, app-server—that's where your application stays in control of the lifecycle and user experience.

Cody Okay, so the product story is: don't rip out your dashboard and replace it with a chat box.

Justy Exactly. A security analyst needs an investigation queue, recent alerts, affected services, and an approval step before opening a remediation ticket. The agent fits into that workflow, not the other way around.

Cody I see.

Justy They built a reference app called Relay—a shipment operations dashboard with an embedded agent and application-owned MCP tools. User selects a shipment, clicks 'Compare recovery,' the app feeds the agent context, agent retrieves the latest operational data, explains options, and anything consequential requires approval.

Cody So the pattern is: application owns the business logic and the interface, harness owns the agent loop.

Justy Right. And it's already shipping. GitHub and JetBrains are embedding it into IDE workflows. Cisco uses the SDK in App Builder. There's a tax-prep workflow—Thrive Holdings, Crete—that processed seven thousand returns and cut preparation time by about a third.

Cody That's not theoretical. Those are real workflows.

Justy Not theoretical at all. Which brings me to the thing I know you're going to poke at.

Justy The harness is open source now. Developers can inspect it, understand how it behaves, adapt it to their product. And I think that's the real move—not 'here's a finished thing,' but 'here's the abstraction we found that actually works, now make it yours.'

Cody Okay, but is that a simplification or just a different kind of work? Like, 'understand and adapt our harness' versus 'build your own agent loop'—I'm not sure the friction actually goes away.

Justy The open-source layer is the harness and integration surface—model access and managed services stay separate. So if you're building on Codex, you start with the repository, then pick the integration that fits: codex exec for noninteractive jobs, the SDK for programmatic workflows, or app-server for persistent conversations with approval handling.

Cody That's the real test, though—whether the open harness becomes the de facto standard the way MCP did for tools, or whether every team ends up customizing it so heavily that the abstraction doesn't actually save friction.

Justy Ask me in six months. But right now the signal is good.

Cody Mm.

Justy I mean, we've been saying forever that the boring infrastructure—the controls, the approval flows, the sandbox lifecycle—is load-bearing. This is basically that thesis shipping in concrete products instead of just being a thing we yell about on a podcast.

Justy Which, you know, good. That's the whole game.

Cody Yeah, no, it's solid. The harness abstraction wins if it actually collapses integration work. The jury's still out on whether that's true at scale, but the examples they're showing are real.

Justy So if you want to build with the Codex harness, start with the open-source Codex repository, then choose the integration that fits your product: codex exec for noninteractive jobs, the SDK for programmatic agent workflows, or app-server for applications that need persistent conversations, streamed events, and approval handling.

Cody And the fact that it's open means you can actually see how it works and adapt it instead of just trusting a black box.

Justy Right. That control over the integration layer is probably the thing that makes this stick.

Cody Agreed.

Justy Okay, Cody—real question. If every team ends up customizing the harness heavily, does the open-source move actually win, or does it just become 'here's a starting point that nobody actually uses as-is'?

Cody Honestly, I don't know yet. But the tax-prep people cutting preparation time by a third suggests the abstraction is solving a real problem, not just a theoretical one.

Justy That's fair. And the pattern across GitHub, JetBrains, Cisco—app owns the interface and business logic, harness owns the loop—is clean enough that I'd bet people keep using it as-is more often than they fork it.

Cody I'd take that bet.

Justy So this is basically our thesis shipping. Boring infrastructure is load-bearing, and this harness move proves it.