Codex App Server MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_MCP_CODEX_BIN | No | Codex executable path | codex |
| CODEX_MCP_MAX_AGENTS | No | Maximum supervisor-managed workers in one MCP process | 256 |
| CODEX_MCP_APP_SERVER_CWD | No | App-server process working directory | |
| CODEX_MCP_ENABLE_RAW_RPC | No | Expose the unrestricted raw_rpc MCP tool | false |
| CODEX_MCP_MAX_TEXT_CHARS | No | Maximum retained live/final text, diff, or event payload | 32000 |
| CODEX_MCP_CODEX_ARGS_JSON | No | JSON array of app-server process arguments | ["app-server"] |
| CODEX_MCP_EXPERIMENTAL_API | No | Initialize with experimental app-server APIs enabled | true |
| CODEX_MCP_MAX_ACTIVE_AGENTS | No | Maximum simultaneously starting, running, or waiting workers | 32 |
| CODEX_APP_SERVER_MCP_COMMAND | No | Pi adapter override for starting this MCP server | current Node executable |
| CODEX_MCP_REQUEST_TIMEOUT_MS | No | RPC request timeout for cancellable calls | 30000 |
| CODEX_APP_SERVER_MCP_ARGS_JSON | No | Pi adapter command arguments | built server entry |
| CODEX_MCP_MAX_EVENTS_PER_AGENT | No | Per-worker reduced event retention | 250 |
| CODEX_MCP_THREAD_REQUEST_TIMEOUT_MS | No | RPC request timeout for thread/start, thread/resume, and thread/fork, which cannot be cancelled | 300000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| server_infoA | Check the Codex app-server process, worker counts, and any unscoped pending server requests. |
| agent_startA | Dispatch a Codex worker: creates an independent thread and starts its first turn. Returns as soon as the turn is accepted; the worker keeps running in the background whether or not you watch it. Treat this like spawning a background subagent — issue several in one message to run a fleet, alongside any host-native subagents you also want, then go do other work and collect with agent_result. Do not follow this call with agent_wait. The prompt should be a complete, self-contained task including the acceptance criteria, since the worker cannot see your conversation. Common fields are provided directly; threadOptions and turnOptions pass additional app-server fields through, with direct fields taking precedence. |
| agent_resumeB | Load and subscribe to a persisted Codex thread after an MCP-server restart or from another Codex client. |
| agent_forkA | Branch a managed agent or persisted Codex thread into a new independent worker. An optional prompt starts work immediately on the fork. |
| agent_sendA | Send guidance to a worker. In auto mode this steers its active turn, or starts a follow-up turn when it is idle. Use an explicit mode when the distinction matters. Returns once the message is delivered, not once the worker has acted on it; poll agent_status afterwards rather than blocking on agent_wait. |
| agent_steerB | Append guidance to the worker's current in-flight turn using turn/steer and its expected active turn id. |
| agent_interruptA | Interrupt a worker's active turn. Calling this on an idle worker is a no-op. |
| agent_statusA | Detailed non-blocking snapshot of one worker: reduced current state, final or live message, plan, diff, usage, and pending approval/input requests. Use agent_result instead when you just want results or are checking more than one worker; reach for this when a single worker needs a closer look. |
| agent_listA | List every worker known to this MCP process, including Codex-created descendant agents discovered from the event stream. Returns immediately with one compact line per worker and no full messages. Use this to see the shape of the fleet, including workers Codex spawned on its own; use agent_result when you want their output. |
| agent_eventsA | Read a bounded page of reduced worker events after a cursor. Returns immediately. Data is omitted by default to avoid flooding the supervisor context. Use this for detail after agent_status shows something worth inspecting. |
| agent_waitA | Block until watched workers are ready. This blocks your whole turn, so use it only once you have run out of other work — while you still have anything to do, dispatch it and poll with agent_result instead. Workers do not need this call to stay alive or make progress. When you do wait, always pass every outstanding worker in agentIds rather than waiting on one at a time: waiting serially multiplies the stall by the number of workers. Returns when the mode condition is met or the timeout expires, with a lean report for each ready worker and each one still running. |
| agent_resultA | Collect worker results. Returns immediately with a lean report per worker: status, whether it is done, its final message, any approval it is blocked on, and its token spend. Call with no arguments to sweep every worker at once — this is the normal way to check on a fleet, and it costs one call no matter how many workers are running. Use this rather than agent_status unless you need one worker's plan, diff, or event detail. |
| agent_request_resolveA | Answer a pending app-server approval, permission, user-input, dynamic-tool, or MCP elicitation request. For command/file approvals, decision is shorthand for {decision}. For other request types, pass the exact response object shown by the current app-server schema. |
| agent_goal_setC | Set or update the persistent app-server goal attached to a worker thread. |
| agent_archiveA | Archive an idle worker thread. Active turns must be interrupted first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/j-pollack/codex-app-server-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server