codex-app-server-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_BIN | No | Path to the Codex CLI. Useful if your MCP client can't find `codex` on its `PATH` (common with nvm), e.g. `-e CODEX_BIN="$(which codex)"`. | codex |
| CODEX_MODEL | No | Default model | from `~/.codex/config.toml` |
| CODEX_EFFORT | No | Default reasoning effort | from `~/.codex/config.toml` |
| CODEX_SANDBOX | No | Default sandbox for new threads: `read-only`, `workspace-write`, `danger-full-access` | workspace-write |
| CODEX_APPROVAL | No | Default approval policy: `untrusted`, `on-request`, `never` | on-request |
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 |
|---|---|
| codex_runA | Give Codex (OpenAI coding agent) a task. Starts a new thread, or continues an existing one when thread_id is given. Blocks up to wait_seconds, then returns status, Codex's latest message, files changed and commands run. status "inProgress" → codex_wait; "waitingForInput" → answer pending_requests with codex_respond. Run several threads in parallel by calling codex_run with wait_seconds: 0 for each, then codex_wait with all thread_ids. Review Codex's changes yourself before reporting them as done. |
| codex_waitA | Wait for turns on one or more Codex threads, then return their reports. mode "all" (default) returns when every thread is done or blocked on a request; "any" returns as soon as one is. |
| codex_statusA | Non-blocking snapshot of Codex threads in this session: status, what Codex is doing right now, pending requests. |
| codex_respondB | Answer a request Codex is blocked on (listed in pending_requests). Approvals take decision: accept | acceptForSession | decline | cancel. Questions take answers: { : "answer" }. Ask the user first when the request is something they should decide. |
| codex_steerC | Add instructions to the turn Codex is currently working on, without stopping it. |
| codex_interruptC | Stop the running turn on a Codex thread. |
| codex_reviewB | Run Codex's native code review (read-only) in a git repo. The review text comes back in the "review" field. Pass focus and/or adversarial: true for a steerable review that challenges the design, not just bugs. |
| codex_compactB | Summarize a long Codex thread's history to free up its context window. Runs in the background. |
| codex_modelsB | Models available to this Codex login, with supported reasoning efforts. |
| codex_threadsA | List recent Codex threads (including ones from the Codex app/CLI), newest first. Continue one with codex_run + thread_id. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a clearly distinct action in the Codex thread lifecycle. codex_run, codex_wait, and codex_status have explicit boundaries described in their docs, and codex_respond vs codex_steer are differentiated as answering blocked requests versus adding live instructions. No overlapping purposes that would cause misselection.
All tools use a consistent codex_ prefix with lower snake_case and a predictable verb/noun pattern. Names are immediately readable and follow the same convention throughout.
10 tools is well-scoped for managing Codex agent sessions. Each tool covers a necessary operation—run, wait, status, interrupt, review, compact, models, threads, respond, steer—without redundancy.
The surface covers a full agent-session lifecycle: start/continue, monitor, wait, interrupt, respond, steer, review, compact, and list models/threads. Minor gaps exist, such as no explicit thread deletion/archival or full transcript retrieval, but core workflows are covered.