codex-mcp-bridge
Related Servers
Alternatives to codex-mcp-bridge
- AlicenseAqualityDmaintenanceMCP server that lets Claude Code drive the local Codex CLI as a sub-agent for concurrent queries and optional file/shell actions, using the CLI's existing login and sessions.484 npm1MIT
Related Servers
- AlicenseAqualityFmaintenanceMCP server that routes Claude Desktop chat into Claude Code, enabling headless execution and terminal handoff with session continuity.4MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that bridges Claude Desktop with Claude Code, allowing users to delegate tasks to Claude Code directly from Claude Desktop conversations, supporting both synchronous and background execution with session reuse.8 npmMIT
- AlicenseBqualityDmaintenanceMCP server for managing Claude Code conversation sessions1238 npmMIT
- FlicenseNot gradedqualityDmaintenanceLocal MCP server for Codex to send prompts to ChatGPT Web Pro extension and manage repository tasks safely.1-
- AlicenseAqualityBmaintenanceLocal MCP bridge that lets Codex operate local Claude Code sessions, including listing, starting, resuming, forking, prompting, and stopping conversations via the Remote Control CLI.14MIT
- AlicenseNot gradedqualityBmaintenanceA local MCP bridge that lets Claude Desktop delegate work to OpenAI API models, drive a locally installed Codex app-server, and call user-configured external MCP servers. It also provides persistent memory, context compaction, a task queue, and workspace file reading/search, with write and remote actions gated behind explicit confirmations.MIT
TDQS
Scored across 16 tools
Several tools have genuinely overlapping purposes: delegate_to_codex vs start_codex_thread vs send_to_codex_thread all create/send into Codex sessions, and inspect_bridge_project vs worker_status vs codex_bridge_status vs list_workers are all status/inspection tools with subtle distinctions. The verbose descriptions try to carve boundaries, but an agent could easily misselect among the thread-management and status tools.
Most tools follow a predictable snake_case verb_noun pattern (send_to_codex_thread, list_codex_threads, prepare_bridge_project). The main deviations are noun-first status tools (worker_status, codex_bridge_status) and a few verb_to_noun names, which are minor but break the pattern.
Sixteen tools is just above the comfortable 3-15 range but reasonable for a bridge that manages Codex threads, background workers, project trust, and app-server lifecycle. The count is slightly heavy but each tool maps to a real operation.
Coverage is broad: thread list/read/start/send/delegate/interrupt/open, worker send/read/list/status, project inspect/prepare, and bridge status/stop. Minor gaps exist (no thread archive/delete, no explicit worker task cancellation), but core lifecycles are covered.