Skip to content

Codex as an MCP server — the other direction

The last lesson pointed Codex outward — it became a client of the rate API. MCP runs the other way too. Codex can itself stand up as a server, exposing its own ability to run a coding task as a tool that some other program calls. The wiring is symmetric; only the direction of the arrow changes.

You make Codex a server with one command:

codex mcp-server

Note the hyphen — it’s codex mcp-server, the inverse of the codex mcp subcommand you used to manage servers in the last lesson. It runs Codex over stdio, waiting for an MCP client to connect and drive it. The exact handshake and the tools it exposes are on the Codex CLI reference.

For most of your week on budgetcli, it isn’t. You sit at the Codex TUI and Codex is the thing in charge — it’s the host, reaching out to servers like the rate API. Running Codex as a server inverts that: now Codex is the tool, and something else owns the loop. That’s the right shape in a narrow set of cases:

  • Another agent orchestrates, Codex executes. A larger automation — a different agent, or a script you’ve built — owns the high-level plan and wants to hand off a concrete coding task: “regenerate the March report in budgetcli and commit it.” It calls Codex as a server, Codex does the focused work in the repo, and hands back the result. The outer system never has to reimplement what Codex already does well.
  • You want Codex’s repo-scoped work as a callable capability, not an interactive session. Anything that can speak MCP — including agents built on other stacks — can then treat “do a coding task in this repo” as one more tool alongside its others.

The thing to hold onto is that serving Codex is a delegation pattern, not a default. When Codex serves, the caller decides how much rope it gets — the same approval and sandbox dials from the approvals chapter still apply to the work Codex does on the other end of that connection. A server invocation that runs with wide-open approvals on your real budgetcli repo is exactly as dangerous as it sounds, and now there’s no human watching the TUI to catch it. Scope it the way you’d scope any unattended run.

For the work in this course you’ll stay the host — Codex reaching out, not being reached. But knowing the protocol is bidirectional matters the moment you start chaining agents together, which is squarely where the automation chapter heads.

That covers reach in both directions. The other half of this chapter is the opposite instinct: not widening what the agent can do, but drawing a hard line it can’t cross. That’s a hook.