
Codex Mcp Bridge
io.github.hampsterxPublished by GitHub account hampsterxv0.9.1Updated Oct 24, 2026
Wraps Codex CLI as MCP tools: codex, review, query, search, structured, ping, listSessions.
Overview
Wraps the Codex CLI as MCP tools so an assistant can run Codex prompts, code reviews, web searches, and schema-validated structured output.
- What you can do
- Spawns the Codex CLI as a subprocess and exposes it as tools: codex for general prompts with file context, session resume, sandbox levels and reasoning effort; review for native diff-aware review of uncommitted changes, a base branch or a commit; search for web search with source URLs; query for lightweight text analysis in an isolated temp directory; structured for JSON Schema-validated output; plus ping, mcpStatus and listSessions diagnostics. Responses carry execution metadata such as duration, model and fallback use.
- When to use it
- Useful when your MCP client has no shell access (Cursor, Windsurf, Claude Desktop, VS Code) but you still want Codex-driven analysis and review, or when you need schema-validated output, partial capture on timeout, automatic model fallback on quota errors, or multi-turn sessions. If your client already has a shell, calling the Codex CLI directly is faster and cheaper.
- Requirements
- Local Node.js runtime (npx codex-mcp-bridge) and the Codex CLI installed, for example via npm. An OpenAI credential is needed: the OPENAI_API_KEY environment variable or a completed codex auth login. Optional environment variables: CODEX_CLI_PATH, CODEX_DEFAULT_MODEL, CODEX_FALLBACK_MODEL, CODEX_MAX_CONCURRENT, CODEX_MCP_SERVERS. Desktop-only; network access required for model calls and web search.
Installation
In SourceWeft
- Open Codex Mcp Bridge in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
codex-mcp-bridge
[npm version] [npm downloads] [CI] [License: MIT] [Node.js] [TypeScript] [MCP]
MCP server that wraps Codex CLI as a subprocess, exposing code execution, web search, and structured output as Model Context Protocol tools.
Works with any MCP client: Claude Code, Gemini CLI, Cursor, Windsurf, VS Code, or any tool that speaks MCP.
Do you need this?
If you're in a terminal agent (Claude Code, Codex CLI, Gemini CLI) with shell access, call Codex CLI directly. It's faster, cheaper, and zero overhead:
Use this MCP bridge instead when:
- Your client has no shell access (Cursor, Windsurf, Claude Desktop, VS Code)
- You need structured output with JSON Schema validation (Codex CLI's
--jsonhas known bugs) - You need partial response capture on timeout and automatic model fallback on quota exhaustion
- You want subprocess isolation: explicit env allowlist, no shell escape,
secret redaction on output, FIFO-queued concurrency (max 3 parallel spawns,
configurable via
CODEX_MAX_CONCURRENT) - You need multi-turn conversations via session resume (
sessionId/resetSession, inspected vialistSessions)
Worktree note: Codex CLI issue #9084
breaks codex -C /path review .... Run codex review from inside the worktree to avoid it.
Quick Start
Prerequisites
- Codex CLI installed (
npm i -g @openai/codex) OPENAI_API_KEYenvironment variable set, orcodex auth logincompleted
Claude Code
Gemini CLI
Add to ~/.gemini/settings.json:
Cursor / Windsurf / VS Code
Add to your MCP settings:
Tools
codex
General-purpose execution. Supports multi-turn conversations via sessionId, sandbox levels (read-only, workspace-write, full-auto), and reasoning effort control. Pass resetSession: true to discard and start fresh. Use listSessions to inspect active sessions before resuming.
Key parameters: prompt (required), files, model, sessionId, sandbox, reasoningEffort, workingDirectory, timeout (default 60s).
search
Web search powered by OpenAI's native search infrastructure via Codex CLI's --search flag. Returns synthesized answers with source URLs.
Key parameters: query (required), model, workingDirectory, timeout (default 120s).
query
Lightweight, non-agentic text analysis. Spawns in an isolated temp directory so the bridge's repo context doesn't leak. Pass text to analyze in the context parameter. Supports reasoningEffort and maxResponseLength.
Key parameters: prompt (required), context, model, reasoningEffort, timeout (default 60s).
review
Thin wrapper around Codex CLI's native diff-aware review. The bridge passes the diff selector to codex exec review --json; upstream Codex owns the review prompt. Requires a real git repository via workingDirectory.
Key parameters: mode (required: uncommitted, base, or commit), workingDirectory (required), base (required for base mode), commit (required for commit mode), title, model, timeout (default 180s).
structured
Embeds a JSON Schema in the prompt and validates the response with Ajv. Returns clean JSON on success, validation errors on failure.
Key parameters: prompt (required), schema (required, JSON string), files, model, workingDirectory, timeout (default 60s).
ping
No parameters. Returns CLI version, auth status, model configuration, and concurrency diagnostics (activeCount, queueDepth).
mcpStatus
Reports per-server MCP state as Codex's own app-server protocol sees it. Unlike every other tool, it deliberately does not suppress Codex's MCP servers or harden the subprocess environment, because both would disable the thing being measured. It therefore boots the servers in ~/.codex/config.toml and is slower than a normal call. With diagnostics: true and a workingDirectory inside a trusted project, the thread it starts also boots that project's .codex/config.toml servers.
Key parameters: diagnostics (default false), workingDirectory, timeout (per-request, default 90s).
Reading the output:
unknownis not a failure. It means the inventory carried no server info and no explicit verdict was available. Onlydiagnostics: truecan reportfailed.- A
degradedwarning means don't trustunknown. Slow calls have been observed reporting healthy servers as uninitialized, so the tool reports how long the underlying call took and flags the result when it was slow enough to be suspect. builtInmarks a server Codex injects that is not in your config;configuredButUnreportedmarks one in your config that Codex never mentioned.
Example:
All tools attach execution metadata (_meta) with durationMs, model, fallbackUsed, and session info where applicable. See DESIGN.md for details.
Code review with this CLI
This bridge does not bundle reviewer prompts. There are three paths for code review:
Native upstream codex review
Diff-aware review built into Codex CLI. No bridge involvement. Use this when your client has shell access.
Bridge review tool for native diff-aware review
The bridge runs codex exec review --json from workingDirectory, captures the final review text, and returns review metadata such as threadId, event counts, and redacted command output. It does not accept a prompt.
Bridge codex tool with caller-supplied prompt
The bridge runs codex exec --sandbox read-only with the supplied prompt and returns stdout. Use this for free-form review prompts or review inputs that are not expressible as uncommitted, base, or commit diff selectors.
Representative review prompt
A starting point; adapt freely:
The bridge has no opinion on prompt content. See ADR-001 for the rationale.
Configuration
Running the bridge against a second Codex account
CODEX_HOME is a complete identity switch: auth, config.toml, skills and
thread history all live under the root, so a second root is a second install.
Every tool call this bridge makes is machine traffic rather than a session
someone is sitting in front of, which makes it a good candidate for a work or
team seat while interactive codex keeps a personal one.
Set it in the server registration rather than the ambient shell, so the choice does not depend on which terminal launched the client:
Three things to know before you do:
- Log in as that root first, since a root is only as usable as its
credentials:
CODEX_HOME=/home/you/.codex-work codex login(orcodex login --with-api-key). Check it withCODEX_HOME=/home/you/.codex-work codex login status. - A JSON
envblock has no conditional. If that root loses its login, every subprocess the bridge spawns targets it anyway, with no fallback to the default root the way a shell wrapper could offer one. - Set
CODEX_DEFAULT_MODELalongside it. The bridge resolvesconfig.tomlfromCODEX_HOME, so a freshly created root has none and the model drops to the CLI default. That absence also makes most ofCODEX_MCP_SERVERSinert: with nothing configured there is nothing to disable, nothing to inherit and no name to enable, which is what the default setting wants anyway. The one mode it does not disarm is a raw TOML override (a value starting{or[), which is passed straight through as-c mcp_servers=...and never readsconfig.toml.
Choosing a Codex MCP server
Performance
Codex CLI has minimal startup overhead (<100ms), so wall time is dominated by model inference.
Default timeouts (60-300s) are comfortable for typical workloads.
Bridge family
Two MCP servers, same architecture, different underlying CLIs. Each wraps a terminal agent as a subprocess and exposes it as MCP tools. Pick the one that matches your model provider, or run both for cross-model workflows.
Both share: subprocess env isolation, path sandboxing, output redaction (secret stripping), FIFO concurrency queue, MCP tool annotations, _meta response metadata, progress heartbeats.
Development
Further reading
- DESIGN.md - Architecture, MCP server control grammar, sessions, output parsing, response metadata
- SECURITY.md - Environment isolation, path sandboxing, output redaction, resource limits
- CHANGELOG.md - Release history
License
MIT
Source: README.md at commit bb14fad
Tools
0Version history
1- v0.9.1LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts