codex-mcp-thirdparty
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_MCP_CONFIG | No | Bridge configuration file. The installer creates ~/.config/codex-mcp-thirdparty/config.json by default. | |
| CODEX_MCP_STATE_DIR | No | Directory for logs, session metadata, configuration backups, and pinned runtimes. Defaults to ~/.local/state/codex-mcp-thirdparty. |
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| codexA | Run a task in a new Codex conversation. Returns threadId for codex-reply. Uses your existing Codex login and model. Set cwd to the project; use sandbox=workspace-write for edits. Long tasks emit progress. A failed/cancelled task may already have made changes: inspect before retrying. |
| codex-replyA | Continue a Codex conversation across MCP/Claude restarts. Pass threadId from codex. Legacy conversationId is also accepted. Only one turn may run per conversation. |
| codex-statusA | Check Codex executable, compatibility, login state, fallback runtime, and active tasks without making a model request. |
| codex-sessionsA | List recent conversations created by this bridge (metadata only) to recover threadId for codex-reply. |
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 distinct role: codex starts a new task, codex-reply continues an existing thread, codex-sessions lists recoverable threads, and codex-status reports health. The only potential confusion is between codex and codex-reply, but the descriptions make the new-vs-continue boundary clear.
Names use a consistent codex-prefixed namespace: codex, codex-reply, codex-sessions, codex-status. The bare 'codex' tool does not follow the same suffix pattern as the others, but it reads naturally as the primary action and the overall convention is predictable.
Four tools is well-scoped for a Codex bridge: one to start work, one to continue work, one to recover sessions, and one to diagnose the environment. Each tool earns its place without redundancy.
The surface covers the core lifecycle: start a task, continue a thread, list recoverable sessions, and check status. There is no explicit cancel/abort or delete-session tool, which are minor gaps an agent can generally work around.