codex-subagent-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_BIN | No | Path to the Codex executable, if it is not codex on PATH. | |
| CODEX_SUBAGENT_MAX_EFFORT | No | Ceiling on reasoning effort. Useful for keeping ultra off the table. | |
| CODEX_SUBAGENT_MAX_SANDBOX | No | Ceiling on what a delegation may do. Set to read-only to forbid writing outright. | |
| CODEX_SUBAGENT_DEFAULT_MODEL | No | Stops the server asking which Codex model to use. Sets the default model for delegations. | |
| CODEX_SUBAGENT_ALLOWED_MODELS | No | Comma-separated allow-list of Codex models. Any model not in the list is refused. | |
| CODEX_SUBAGENT_DEFAULT_EFFORT | No | Reasoning effort used when a delegation call specifies none. |
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
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| codex_doctorA | Check whether the local Codex CLI is installed, recent enough and signed in, and report the exact steps to fix it if not. Run this when any other tool reports the CLI is unavailable, or before relying on delegation for the first time. It only inspects the installation; it never installs or changes anything. |
| list_codex_modelsA | List the Codex models available on this machine, with the reasoning-effort levels each one supports. Read from the installed Codex CLI, never hardcoded. Call this before codex_delegate when choosing a model explicitly. |
| codex_recommendA | Given a task description, recommend which Codex model and reasoning effort to delegate it with. Runs no model call; applies a documented matrix reconciled against the installed catalog. |
| codex_delegateA | Delegate a coding or analysis task to the local Codex CLI, choosing model and reasoning effort. Codex runs read-only by default: it investigates and reports. Set sandbox to workspace-write to let it edit files. Codex cannot see this conversation, so pass everything it needs in prompt, context, and target_files. |
| codex_follow_upA | Send a follow-up message to a previous delegation using its thread_id. Codex still has the earlier context, so this is much cheaper than re-sending it with codex_delegate. |
| codex_job_statusA | Report the state and recent activity of a background delegation started with mode=background. Call it with no job_id to list every known job. |
| codex_job_resultA | Return the full output of a finished background delegation. Errors if the job is still running. |
| codex_job_cancelB | Terminate a running background delegation. |
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 8 tools
Each tool targets a clearly distinct operation: delegation, follow-up on a thread, diagnostics, and three separate job-management actions (cancel/result/status) that are well differentiated by their descriptions. The only near-overlap is codex_recommend vs list_codex_models, but one advises and the other enumerates, which the descriptions make explicit.
Most tools follow a consistent codex_<action> or codex_job_<action> snake_case pattern, which is predictable and readable. list_codex_models deviates by putting the verb first (list_) instead of the codex_ prefix used elsewhere, a minor inconsistency in an otherwise coherent scheme.
Eight tools is well-scoped for a delegation wrapper: one core action, one follow-up, three job-lifecycle controls, one diagnostic, and two model-selection helpers. Nothing feels padded or redundant.
The surface covers the full delegation lifecycle (run, follow-up, background status/result/cancel) plus setup diagnostics and model discovery, which is solid coverage of the stated domain. Minor gaps remain, such as no explicit way to enumerate or resume prior threads beyond a job_id from status.