codexmcp
让 Claude Code 与 Codex 无缝协作的多智能体 MCP 桥接工具,支持会话持久化、推理追踪和并行任务
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
让 Claude Code 与 Codex 无缝协作的多智能体 MCP 桥接工具,支持会话持久化、推理追踪和并行任务
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象这样一个日常:你正在开发一个复杂的 RESTful API 服务,Claude Code 帮你完成了整体的架构设计和模块划分——路由、认证、中间件、数据库连接池,一切都井井有条。但当涉及到某些具体的算法实现时,Claude Code 的回答虽然正确,却总是缺少一些"直觉感"——毕竟它是通用模型,而 Codex 在特定编程任务上的深度调优让它在细节实现上更加得心应手。
传统的做法是:复制粘贴、在两个工具之间来回切换、人工同步上下文。这不仅割裂了工作流,还容易引入错误。CodexMCP 正是为解决这个问题而生——它不是一个新的 AI 编程工具,而是一个让 Claude Code 和 Codex 协同工作的"通信协议层"。
CodexMCP 由独立开发者团队 GuDaStudio 创建和维护,项目托管于 GitHub,采用 MIT 许可证开源。项目首次提交于 2025 年 11 月,至今已获得近 2000 颗 Stars 和 106 次 Fork,社区活跃度相当可观。
这个项目的诞生背景,折射出了 2025 年 AI 编程工具生态的一个重要趋势:从"一个模型包打天下"转向"多模型协同"——让擅长不同任务的模型各司其职,通过标准化协议互联互通。MCP(Model Context Protocol)协议正是这个趋势的基础设施,而 CodexMCP 则是该协议在 Claude Code ↔ Codex 场景下的具体实现。
作者在 README 中明确指出了两者的分工定位:
这种"架构师 + 工程师"的双人协作模式,理论上比单一模型的工作质量更高,尤其适合中大型项目的迭代开发。
CodexMCP 并非简单的命令行封装,它在官方 Codex MCP 实现的基础上增加了多个企业级特性:
官方版 Codex MCP 不支持多轮对话——每次调用都是一次独立会话,AI 无法记住之前的上下文。CodexMCP 通过 SESSION_ID 参数支持会话恢复,允许在不同任务之间保持连续上下文。这对于大型重构或需要多步骤迭代的工作流至关重要。
官方版不会返回模型的推理过程(thinking/reasoning chain),开发者只能看到最终答案。CodexMCP 通过 return_all_messages=True 参数,可以获取完整的推理链,包括工具调用、中间步骤和思考过程,便于调试和分析模型的决策逻辑。
CodexMCP 支持同时发起多个 Codex 执行任务,由 MCP server 统一管理队列和结果聚合。官方版完全不支持并行,每次只能执行一个任务。
项目实现了精细化的安全控制策略:
read-only:只读模式,Codex 只能读取文件,不能修改,适合代码审查workspace-write:工作区写模式,允许修改代码,但限制危险操作danger-full-access:完整访问权限,配合 --yolo 标志,无任何限制官方版对网络波动和 session 失效处理极为简陋,CodexMCP 实现了自动重连机制(检测 "Reconnecting..." 模式)、JSON 解析容错、以及分层错误信息收集,大幅提升了工具的可靠性。
从代码结构看,CodexMCP 的设计哲学是"保持最小化"——整个项目只有 3 个 Python 源文件:
src/codexmcp/
├── __init__.py # 包定义(仅含版本号)
├── cli.py # 命令行入口(仅一行调用)
└── server.py # 核心实现(~300行)
| 组件 | 技术选型 | 说明 |
|---|---|---|
| MCP 框架 | FastMCP 1.20+ | 标准化 MCP server 框架 |
| 数据验证 | Pydantic v2 | 参数校验和类型标注 |
| 进程管理 | subprocess + queue + threading | 异步流式读取 codex 输出 |
| 构建工具 | Hatchling | 现代 Python 打包方案 |
| 包管理 | uv | 极速 Python 包管理器 |
server.py 中的 run_shell_command() 函数是整个项目的心脏:
subprocess.Popen 启动 codex exec 子进程queue.Queueturn.completed 事件后优雅关闭进程这种"流式处理 + 生成器"模式避免了大量内存占用,也保证了输出的实时性。
@mcp.tool(name="codex", ...)
async def codex(
PROMPT: Annotated[str, "任务指令"],
cd: Annotated[Path, "工作区根目录"],
sandbox: Literal["read-only", "workspace-write", "danger-full-access"],
SESSION_ID: str, # 会话恢复
return_all_messages: bool, # 推理追踪
image: List[Path], # 图片输入
model: str, # 模型选择
yolo: bool, # 无沙箱模式
profile: str, # Codex 配置profile
)
接口设计非常克制,没有引入过多抽象,每参数都有清晰的用途说明。
| 维度 | 评分 |
|---|---|
| 代码结构 | 清晰简洁,模块化良好 |
| 错误处理 | 分层捕获,容错完善 |
| 类型标注 | Pydantic + Annotated,类型安全 |
| 文档质量 | README + docs/README_EN.md,中英双语 |
| 测试覆盖 | 需进一步确认 |
CodexMCP 的安装极为简单,一行命令搞定:
claude mcp add codex -s user --transport stdio -- \
uvx --from git+https://github.com/GuDaStudio/codexmcp.git codexmcp
依赖通过 uvx 动态安装,无需手动配置虚拟环境。
然而,这个"简单"背后有隐含门槛:
这意味着:CodexMCP 的核心用户是已经同时使用 Claude Code 和 Codex 的开发者——这是一个相对垂直的群体。
安装后,Claude Code 会自动识别 Codex 作为一个可用的 MCP 工具。在对话中,Claude Code 可以主动调用 Codex 来处理特定任务,用户也可以手动指定使用 Codex。
CodexMCP 本质上是一个 Claude Code 的插件,不是一个独立运行的服务。没有 Web UI,不支持 Docker,无法在纯云端环境中使用。对于没有同时配置 Claude Code 和 Codex 的团队,使用门槛较高。
当 Claude Code 和 Codex 在同一会话中来回切换时,上下文管理的复杂性会显著增加——两个模型对同一代码的理解可能存在差异,如果缺乏有效的摘要和同步机制,反而可能引入更多混乱。
Codex 基于 OpenAI API,每一次任务调用都会消耗 OpenAI 的额度。如果 Claude Code 频繁调用 Codex,长会话的成本会快速累积。需要用户自行权衡成本与效率的平衡。
项目最近更新(2026-06-11)与首次提交(2025-11-05)间隔约 7 个月,正处于活跃维护期。这意味着 API 可能会随上游 Codex CLI 的更新而变化,用户需要关注版本兼容性。
CodexMCP 的出现代表了 AI 编程工具领域的一个新兴方向:工具间互操作性。
过去,AI 编程工具都是"孤岛"——Claude Code 就是一个 Claude Code,Codex 就是一个 Codex,各自封闭。用户被锁定在单一生态中。CodexMCP 通过 MCP 协议打破了这一壁垒,让不同供应商的 AI 工具可以协同工作。
从增长数据看:项目在不到一年内获得近 2000 Stars,106 次 Fork,30 个 open issues——对于一个相对垂直的工具类项目,这个数据相当亮眼。它反映的真实需求是:在复杂项目中,单一 AI 模型的"一刀切"方案已经不够用了,市场需要更细粒度的专业化分工。
MCP 协议正在成为 AI 工具互联的事实标准。Anthropic 官方支持 MCP,OpenAI 也通过 Codex CLI 间接支持类似能力。CodexMCP 的成功,预示着未来会出现更多跨生态的"桥梁工具"——让 Claude 和 Gemini、Claude 和 Copilot、Claude 和开源模型之间都能无缝协作。
如果你已经是 Claude Code + Codex 的双重重度用户,CodexMCP 值得一试。对于更广泛的开源社区,它也是一个观察多智能体 AI 协作模式演进的绝佳样本。