codex mcp-server runs Codex over stdio as an MCP server so another agent or host can delegate a coding task to it. This is the reverse direction compared to codex mcp add, where Codex itself consumes external tools. The distinction is fundamental: in one case Codex is a client pulling others' capabilities, in the other a server providing its ability to write code to another orchestrator. Understanding which role Codex is in is necessary, because on it depend who trusts whom and who is responsible for what.
It helps to separate both schemes in a table once, because their risks differ. codex mcp add makes Codex an MCP client calling an external server - and the risk here is in the external tool's permissions and data sharing. codex mcp-server makes Codex a server performing a coding task - and the risk is that the host can assign it actions, and Codex will perform them with its own hands. These are two opposite trust boundaries, and confusing them means misjudging where the danger runs.
| Scheme | Codex role | Risk |
|---|---|---|
| codex mcp add | MCP client, calls an external server | External tool permissions and data sharing |
| codex mcp-server | MCP server, performs a coding task | The host delegates actions; the orchestrator sets the boundaries |
Launching in the server role is simple but opens delegation. Below is the codex mcp-server command. After it, Codex is available as a tool that an external agent can call. The simplicity of the command must not hide the essence: you give the ability to write and execute code under the control of another orchestrator. This is powerful for building multi-agent systems but also requires clarity about who this orchestrator is and what tasks it is entitled to delegate to Codex.
When integrating with the Agents SDK the division of responsibility becomes explicit. The host creates an MCP process, calls the exposed Codex tool and gets the result. But everything around the call is the external orchestrator's concern: the working directory, authentication, the sandbox, the timeout and the final verification of the result. The Codex server performs the task but is not responsible for the boundaries it was launched in - that is the host's responsibility. The division is clear: the server does the work, the orchestrator sets the frame and checks the result.
The orchestrator's responsibility is not a formality but a real security boundary. cwd determines where Codex will work; auth on whose behalf; the sandbox what it can touch; timeout how long; the final verification whether to accept the result. If the orchestrator sets these frames carelessly, delegating a task to the Codex server becomes a hole: the server will honestly do what it was assigned within the boundaries it was given, and if the boundaries are wide, so are the consequences.
The point of this reverse scheme is to embed Codex's ability to write code into another agent architecture. When you already have an orchestrator on the Agents SDK coordinating several tools, the Codex server becomes one of them - the one that can make sense of a repository and make a change. This is a composition of agent systems, not a single run. But composition also strengthens the requirements for boundaries: a delegated task needs a narrow sandbox and verification of the result as much as any other.
The choice between the schemes is a choice of Codex's role in your architecture. You need external tools inside Codex - that is codex mcp add, Codex as a client. You need to give Codex's ability to write code to an external orchestrator - that is codex mcp-server, Codex as a server. Both schemes are legitimate, but they have opposite directions of trust, and the first question in design is which role Codex is in here and, consequently, who sets the boundaries and checks the result.
The typical failures around this topic are predictable. Confusing codex mcp add and codex mcp-server and misjudging the direction of trust. Giving Codex as a server to an orchestrator without consciously setting cwd, auth, sandbox and timeout. Relying on the server to limit itself - though the host sets the frame. And not checking the result of a delegated task as strictly as your own. Understand Codex's role, set the boundaries on the orchestrator's side and check the delegation's result like any other.
# Codex as an MCP server: another agent/host delegates a coding task
codex mcp-server
# the reverse direction to codex mcp add (where Codex is a client of external tools)
# when integrating with the Agents SDK: the host is responsible for cwd, auth, sandbox, timeout, verification