Unlocking the Codex harness: how we built the App Server

OpenAI just published a deep look at the Codex App Server, the piece of infrastructure that lets developers wire the Codex coding agent into their own apps rather than just using it inside OpenAI's own interfaces. The mechanism is a bidirectional JSON-RPC API, which sounds dry until you realize what it actually enables: an editor, IDE plugin, or internal dev tool can now talk to Codex in real time, watch it think, and interrupt it mid-task.

The core trick is that the connection runs both ways. Most APIs are request-in, response-out. Codex's App Server keeps a persistent channel open so the agent can push updates back to the client as it works, streaming progress on a task instead of making the developer poll for a finished result. That matters a lot for coding agents specifically, because a single request can spin off many small actions: reading files, running commands, proposing edits. Without a live feed, the user experience is a black box with a spinner.

OpenAI's writeup walks through how the server exposes tool use, meaning Codex can call out to shell commands, file operations, or other functions mid-session, and how it handles approvals — the checkpoints where a human has to say yes before the agent executes something risky, like modifying code or running a script. Diffs get first-class treatment too, letting the client render exactly what changed rather than forcing developers to reconstruct that from raw output.

What's notable here isn't a flashy new model or benchmark. It's plumbing. OpenAI is essentially handing over the internal harness that Codex itself runs on, so third parties can build their own Codex-powered products without reinventing session management, streaming, and permissioning from scratch. It's the kind of infrastructure move that rarely gets headlines but ends up shaping how many products actually get built on top of a given agent.