codex-local-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_BIN | No | Absolute path to the Codex CLI. | codex |
| CODEX_MODEL | No | Model override. | |
| CODEX_MCP_ROOT | No | Root for all workspaces. Nothing is written outside it. | ~/.codex-mcp/workspaces |
| CODEX_TIMEOUT_SEC | No | Default timeout before a run is killed. | 300 |
| CODEX_NETWORK_ACCESS | No | Set false to deny Codex the network. | true |
| CODEX_MAX_TIMEOUT_SEC | No | Ceiling a caller may request. | 1800 |
| CODEX_MAX_OUTPUT_CHARS | No | Output cap; the head and tail are kept. | 40000 |
| CODEX_MAX_REPORTED_FILES | No | Cap on reported changed files. | 200 |
| CODEX_MAX_INLINE_IMAGE_BYTES | No | Above this, a downscaled preview is inlined instead. | 1048576 |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| codex_runA | Hand a natural-language task to the local Codex CLI coding agent. Codex can write and run code, install packages and call APIs inside an isolated workspace folder, then this returns its output plus any files it created. If Codex takes longer than wait_sec, this returns status: running and a job_id instead; call codex_job_result with it to collect the result. |
| codex_generate_imageA | Generate images with the local Codex CLI. The prompt is passed through as written. Returns the saved file paths and shows the images inline, downscaling a preview when a file is too large to inline. Defaults to a fast low-quality 1024x1024 draft; raise quality for final assets. Image generation often takes longer than wait_sec, in which case this returns status: running and a job_id; call codex_job_result with it to collect the images. |
| codex_job_resultA | Get the result of a codex_run or codex_generate_image call that returned status: running. Waits up to wait_sec for the job to finish; if it is still running, call again. Results stay available for 60 minutes after the job finishes. |
| codex_read_artifactA | Read one file from a Codex workspace, for artifacts that were too large to inline. Images come back as image content, everything else as text. |
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 4 tools
Each tool has a clearly distinct purpose: running a coding task, generating images, polling async job results, and reading workspace artifacts. There is no overlap or ambiguity between them.
All tools share the codex_ prefix, but the pattern is inconsistent: codex_run and codex_generate_image are verb-led, codex_read_artifact is verb_noun, while codex_job_result is noun_noun. The naming is readable but not uniform.
Four tools is a compact but reasonable set for a local Codex CLI integration. Each tool serves a necessary function in the workflow, though the surface is slightly minimal.
The core lifecycle of submitting a task, polling for results, and reading generated artifacts is covered. Minor gaps exist, such as no way to cancel a running job or list available workspace files, but these are not critical.