Running Codex as an MCP server inside Claude Code

I keep two coding agents within reach — Claude Code and OpenAI's Codex — and for a while I switched terminals depending on which I wanted. Then I wired Codex into Claude Code as an MCP server, so Claude can hand it a task without me leaving the session. It's about four lines of config. Here's the whole thing, the one command everyone gets wrong, and — worth more than the config — where this pattern belongs and where it doesn't.

MCP, in one sentence

The Model Context Protocol is a standard way for an AI client to talk to external tool servers. Claude Code is a client; anything that speaks the protocol can expose tools to it. Project-scoped servers live in a .mcp.json at the repo root, so the wiring is committed and every clone gets it — with an approval prompt before Claude will touch a server it hasn't seen.

The config

This is the entire .mcp.json that puts Codex inside Claude Code:

{
  "mcpServers": {
    "codex": {
      "type": "stdio",
      "command": "codex",
      "args": ["mcp-server"]
    }
  }
}

A stdio server, the codex binary, one argument. That's the lot.

codex mcp-server, not codex mcp

The argument is the part to get right, because Codex ships two similarly-named commands that do opposite things. codex mcp-server runs Codex itself as an MCP server over stdio — what you want when another agent is going to consume Codex. codex mcp, with subcommands like add and list, manages the servers Codex itself connects to. There is no codex mcp serve. Copy the wrong one and the server starts and does nothing useful.

What you get

Once connected, Codex shows up as a couple of tools — mcp__codex__codex to start a task and mcp__codex__codex-reply to continue one. Claude calls them like any other tool: describe the job, Codex works it in its own process, the result comes back. There are no secrets in that config, which is why it's safe to commit — Codex reuses your local codex login, and the credentials stay in your home directory. The one hard requirement is the codex CLI on your PATH; without it the server just reports as disconnected and nothing else breaks. Confirm it with claude mcp list, or /mcp inside a session.

Where it belongs, and where it doesn't

Here's the part the four-line config buries. MCP is having its over-adoption moment — the reflex right now is to put everything behind an MCP server, and for production that's the wrong reflex. Perplexity's CTO has described pulling back from MCP internally for the reasons you'd expect: every tool's schema is paid for in tokens before a single one is called, and the protocol leaves auth, rate-limiting and audit as your problem. Anthropic's own fix for the token bloat is almost subversive — have the agent write code against the tools instead of calling them one at a time, which in their worked example took a task from 150,000 tokens to 2,000.

None of that argues against the four lines above. It argues for them. Wiring Codex into Claude Code over MCP is the pattern used where it fits: local, on your own machine, one trusted tool, you in the loop. That's MCP at its best. 'Everything is an MCP server in production' is MCP at its most cargo-culted. Same protocol, opposite call.

Is it worth it?

For me, in two situations. One is a genuine second opinion: when Claude and I have been circling the same bug, handing it to a model with different training sometimes breaks the deadlock. The other is parallel grunt work — Codex chews through something self-contained while Claude and I keep moving. The caveats are the obvious ones. Output from a delegated agent is untrusted until you've read the diff, and a second agent is a second meter running, so don't reach for it on work one session would handle fine. If you want Claude coordinating many agents rather than one, that's a different tool — dynamic workflows — and a different scale of problem.