
Codex Supervisor Mcp
io.github.zriyoxv0.7.3Updated Oct 7, 2026
Parallel Codex CLI workers from any MCP client: one git worktree each, state in SQLite, web board.
Overview
Lets an assistant dispatch and supervise several parallel Codex CLI coding workers, each in its own Git worktree, with state in SQLite and a local web board.
- What it does
- A main MCP client session creates Codex CLI workers, each with its own Git worktree, declared ownedPaths and a goal, and runs them in parallel. Tools wait for workers, return their reports, diffs, events and status, ask a worker a read-only side question, resume the same Codex session, and cherry-pick a worker's commits into the integration branch. State is stored in SQLite and raw JSONL under a state directory, and a separate local web board shows sessions, workers, commands and diffs.
- When to use it
- Use it when one repository needs several coding agents working at once and you want file-level isolation, durable state across restarts, and a main session that stays small by reading summaries and diffs instead of full worker output. It suits multi-step tasks where each worker does one step and the main session reviews and lands the result. It is not needed for single-agent or single-file edits.
- Requirements
- Local process over stdio; Node.js 22.13.0 or newer and the codex CLI on PATH (or CODEX_BIN set to its path). Install from npm; postinstall registers the MCP server and skill, which GUI clients must configure manually. State lives under SUPERVISOR_HOME (default ~/.codex-supervisor); the web board uses SUPERVISOR_WEB_PORT and SUPERVISOR_WEB_HOST. No authentication is declared.
Installation
In SourceWeft
- Open Codex Supervisor Mcp 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-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
Source: README.md at commit efbd4a8
Tools
0Version history
1- v0.7.3LatestOct 7, 2026


