
Codex Supervisor Mcp
io.github.zriyoxv0.7.3更新于 Oct 7, 2026
Parallel Codex CLI workers from any MCP client: one git worktree each, state in SQLite, web board.
概览
让助手并行派发并监管多个 Codex CLI 编码 worker,每个 worker 一个 Git worktree,状态存入 SQLite,并附带本地网页看板。
- 功能
- 主 MCP 客户端会话可以创建多个 Codex CLI worker,每个 worker 拥有独立的 Git worktree、声明的 ownedPaths 和目标,并行执行任务。工具可等待 worker、返回其汇报、diff、事件与状态,向 worker 发起只读旁问,接回同一个 Codex 会话,并把 worker 的提交 cherry-pick 到集成分支。状态以 SQLite 和原始 JSONL 保存在状态目录中,另有本地网页看板展示 session、worker、命令和改动。
- 适用场景
- 当一个仓库需要多个编码 agent 同时工作,且希望有文件级隔离、重启后仍可恢复的状态,并让主会话只读摘要和 diff 而不被 worker 输出撑爆时使用。适合多步骤任务:每个 worker 只做一步,主会话负责核对并落地结果。单 agent 或单文件修改不需要它。
- 运行要求
- 以 stdio 方式在本机运行;需要 Node.js 22.13.0 以上,以及 PATH 中的 codex CLI(或用 CODEX_BIN 指定路径)。通过 npm 安装,postinstall 会注册 MCP 与 skill,GUI 客户端需手动配置。状态存放在 SUPERVISOR_HOME(默认 ~/.codex-supervisor),看板使用 SUPERVISOR_WEB_PORT 和 SUPERVISOR_WEB_HOST。未声明认证。
安装
在 SourceWeft 中
- 打开 控制台中的 Codex Supervisor Mcp,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
README
codex-supervisor-mcp
English | 中文
[npm version] [npm downloads] [license] [CI] [node]
官网 codex-supervisor.zriyo.com · 给模型读的 llms.txt
让几个 agent 同时改一个仓库,结果是互相覆盖、没人说得清谁改了什么,主线程的上下文还被 worker 的输出塞满。
codex-supervisor-mcp 是一个 Codex MCP server,把「派单」和「记账」从模型上下文里拿出来放到磁盘上:一个主线程(Claude Code、Codex 或任何 MCP 客户端)同时指挥多个 Codex CLI worker,一个 worker 一个 Git worktree,状态落盘到 SQLite,附一个网页看板。
[演示:一个 Claude Code 主线程同时派 3 个 Codex worker,各自独立 worktree,并行跑完后合并提交]
30 秒真跑:create_codex_worker ×3,三个 worker 各自 worktree 并行,主线程收 3 份 diff 合成一次 commit。
解决什么
worker 跑的是 codex exec,model 透传:主线程留在 Claude,worker 可以挂 DeepSeek 或任何 Codex 配了 provider 的模型,账单分开算。
五分钟跑起来
前置:Node.js 22.13.0 以上,codex CLI 在 PATH 里。macOS、Linux、Windows 都行。
1. 装
postinstall 装 skill、注册 MCP。claude mcp list 里没看到(npx、pnpm、--ignore-scripts 不跑 postinstall)就手动补:
重启 Claude Code / Codex。以后不用再手动更,见「更新」。只要 skill 不要 MCP:npx skills add zriyox/codex-supervisor-mcp。
2. 派第一批活
在 Claude Code 里直接说人话,skill 会让它走正确的流程:
把这三个模块的单测补齐,用 codex-supervisor 分三路并行跑,session 叫「补单测」。
主线程背后做的事(你也可以自己调工具):
每路的改动在各自的 codex/<taskId> 分支上,合不合、怎么合由主线程定。
3. 开看板
打开 http://127.0.0.1:7877。状态目录按 SUPERVISOR_HOME、最近的 .mcp.json、~/.codex-supervisor 的顺序找;端口用 SUPERVISOR_WEB_PORT 改。看板只看,不派单不取消。
我自己怎么用
能连 MCP 的都能当主线程,这里只是我的用法。我开两个 Claude Code 会话,一个只管文档,一个只管派活:一个会话又写详设又盯 worker,上下文两小时就满。
两个会话之间只传一段文字,粘进主脑会话用 /goal 接上。结构固定:
主脑一轮下来调的工具:
上一块活 25 步,主脑会话一个人从第 1 步盯到第 25 步,上下文里只有任务书和每路交回来的汇报,没被 worker 的过程撑爆。
为什么一个 worker 只做一步:第 5 步做错了,让做第 5 步的那个 worker resume_codex_worker 一下,改完 --amend 并回它自己那个提交,主脑再核一次,过了才落进集成分支。要是一个 worker 连做了 5、6、7 三步,第 5 步错了就没法这样改,6 和 7 的提交已经叠在 5 上面,改 5 得连 6、7 一起重做。
看板里有什么
浅色深色跟系统走,没有外网资源。
工具
19 个。
必填的两个:ownedPaths(派单前和在跑的 worker 求交集,重叠就拒,只在派单时查)和 goal.objective(worker 会建成 Codex 原生 goal)。session_id 不传就归不了组,一批活传同一个值。
和 Claude Code 的 subagent 有什么区别
文件隔离不是差别:subagent 自己也能开 worktree。差别在模型和进程。
状态机
终态分两步落盘:turn.completed 先把 status 置成 completed,进程退出后才写 exit_code;wait_codex_workers 等到 exit_code 落了才返回。Windows 没有信号,外部 kill 只报 failed 加退出码。Codex 原生 goal 的 paused / blocked 算 running 并进 needs_attention,usageLimited / budgetLimited 算 failed。
状态存储
默认在 ~/.codex-supervisor/:
changed_files 按 worktree 的真实 diff 算,worker 用 shell 改的、自己 commit 过的都能看到。中文文件名原样返回。老版本的库第一次打开自动迁移。
环境变量
GUI 客户端(Claude Desktop、Cursor、Windsurf)不跑 postinstall,自己把这段加进它的 MCP 配置文件,PATH 里常常没有 codex,显式给 CODEX_BIN:
更新
不用手动更。server 启动时后台查一次 registry,有新版就起独立进程 npm i -g 到同一个全局路径;正在跑的会话不受影响,下一个新会话就是新版。只对 npm i -g 装的那份生效,git 源码和 npx 起的不碰。skill 也一样,每次启动刷到已有的 skill 目录,改过的先备份成 SKILL.md.bak-<时间戳>。
装失败(全局目录要 sudo)时 update 字段带原因,手动 npm install -g codex-supervisor-mcp@latest。0.6.1 及以前只提醒不自动装,手动升一次就进自动了。换了 Node 版本注册的路径会失效,claude mcp remove -s user codex-supervisor、codex mcp remove codex-supervisor 后重装。重跑安装:codex-supervisor-setup(--skill-only / --mcp-only / --dry-run)。
卸载:
Windows
- npm 装的 CLI 是
codex.cmd,Node 拒绝直接 spawn 它。这里绕到node_modules/@openai/codex/bin/codex.js用node起,不用shell: true,那样取消时只杀得掉 shell。 - 跨进程取消用
taskkill /PID <pid> /T /F杀整棵树,先确认那个 pid 跑的是 codex。 - 除
PATH外还探%APPDATA%\npm、%LOCALAPPDATA%\pnpm、%LOCALAPPDATA%\Volta\bin、%ProgramFiles%\nodejs。
排查
已知限制
- worker 是 MCP 进程的子进程。MCP 被 kill,worker 跟着没了,结算成
lost;worktree 和thread_id都在,resume_codex_worker接回。让它不跟着死要常驻 daemon,在 Roadmap 里。 - 默认
workspace-write沙箱里 worker 提交不了(Codex 把.git设成只读)。要么收活时land_codex_worker带commitMessage替它提交,要么派单用danger-full-access。 - worktree 从一个提交切,你工作区里没 commit 的东西不在里面。
- 只隔离工作目录。临时目录、数据库、端口是共用的。
ownedPaths只在派单时查,拦不住 worker 新建清单外的文件。收活看 diff。- 只管「跑完了」不管「对不对」,验收得主线程自己做。
- 一次
wait_codex_workers等不到底,客户端的 MCP 工具超时是硬墙,靠反复调。 search_works是子串匹配,几百条够用。
Roadmap
做完的:CODEX_BIN / SUPERVISOR_HOME / GIT_BIN;status 和 phase 拆开;ownedPaths / goal / dependsOn;thread_id 落库 + resume_codex_worker;并发和多进程写库;session_id、search_works、原生 goal;Windows;网页看板;baseRef;收活三件套 get_worker_diff / ask_codex_worker / land_codex_worker;后台自动更新。
下一个:常驻 daemon,派单和进程生命周期从 MCP 进程里拿出来。
不做的:向量检索(子串匹配在这个规模更快、零维护)、usage_count 排序(实测 80 个 work 里只有 2 个被回头引用过)。
开发
CI 跑 Ubuntu / macOS / Windows,另加一个 Node 22.13.0 的 job 卡 engines 下界。
参与贡献
看 CONTRIBUTING.md。安全问题走 私密通道,见 SECURITY.md。
License
MIT
来源:README.md,提交 efbd4a8
工具
0版本历史
1- v0.7.3最新Oct 7, 2026


