单活跃请求复用机制codex-plugin-cc 为何让并发审查排队一文讲清【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址: https://gitcode.com/GitHub_Trending/co/codex-plugin-cccodex-plugin-cc 是官方出品的 Claude Code 插件让你在自己的 Claude Code 工作流里直接调用 Codex 做代码审查/codex:review或任务委托/codex:rescue。它后台有一套单活跃请求复用机制同一个仓库里所有命令共享一个 broker 进程同一时刻只放行一个活跃请求所以并发发起的多份审查不会同时开跑而是排队串行执行。这篇文章带你快速理解这套机制的设计动机与实现细节。为什么并发审查要排队如果你同时触发/codex:review和/codex:adversarial-review最直觉的做法是各起一个 Codex app-server 进程。但这样会带来三个问题进程爆炸每个 Claude Code 会话都拉起独立进程资源浪费、状态互相割裂⚖️用量放大多路并发会同时消耗 Codex 的 usage limits状态竞争多个进程对同一份本地认证、配置和会话状态并发读写容易出错。因此插件选择「单入口 单活跃请求」的复用策略所有命令共用一个 broker谁先来谁先跑后来者要么被拒后走兜底直连要么在任务队列里等位。共享 Broker所有命令共用的 app-server 入口复用的第一步是「把 broker 复用起来」。插件在需要连接 Codex 时会先检查是否已有健康的 broker 会话broker-lifecycle.mjs 中的ensureBrokerSession会读取仓库状态目录里的broker.json如果记录的端点仍然存活就直接复用否则才拉起新的 broker 进程端点地址由 broker-endpoint.mjs 生成Linux/macOS 用 Unix socketWindows 用命名管道文件都放在系统临时目录的独立会话目录中互不干扰broker 主逻辑在 app-server-broker.mjs它自己持有一条到 Codex app-server 的连接disableBroker: true直连其余所有客户端各个/codex:*命令都通过 socket 找它转发请求。这样无论你在几个 Claude Code 会话里并发操作底层始终只有一条Codex app-server 连接这就是「复用」的由来。单活跃请求槽broker 只放行一个客户端 真正的「排队」发生在请求转发环节。broker 内部维护了两个关键变量见 app-server-broker.mjs变量含义activeRequestSocket当前正在执行请求的客户端连接activeStreamSocket当前持有流式会话审查/对话进行中的客户端连接处理规则很直白收到一个带id的 JSON-RPC 请求时若activeRequestSocket或activeStreamSocket已被别的连接占用broker 立即回一个错误码-32001BROKER_BUSY_RPC_CODE定义于 app-server.mjs报错信息是 Shared Codex broker is busy.见 app-server-broker.mjs只有抢到这个「槽位」的客户端才能真正执行请求对turn/start、review/start、thread/compact/start这类流式方法槽位会被一直持有直到收到对应会话线程的turn/completed通知才释放app-server-broker.mjs。也就是说一次完整的审查跑完之前这个槽位不松手。这就是「单活跃请求」的字面含义不是简单的限流而是同一时刻只有一个请求在 Codex 运行时里活着。被拒之后怎么办Busy 错误与直连兜底你可能会问第二个并发审查被拒了它就干等吗不会。客户端侧有兜底逻辑codex.mjs 的withAppServer当错误来自 broker 传输且错误码恰好是-32001时客户端会关闭 broker 连接、改走直连 app-serverdisableBroker: true用同样的逻辑重跑一遍任务如果 broker 端点文件不存在ENOENT或连不上ECONNREFUSED同样降级为直连。效果上两路并发审查不会互相挂死一路走共享 broker另一路直连绕开最终在 Codex 运行时层面被「错峰」执行——这正是标题里「并发审查排队」的实际表现逻辑上都能跑物理上被串行化避免了多进程竞争同一份状态。后台任务如何排队queued → running → done对长时间任务插件还提供了显式的任务队列/codex:rescue --background等codex-companion.mjs 的enqueueBackgroundTask先把任务写成queued状态的任务文件再spawn一个脱离终端的 worker 子进程执行任务状态由 tracked-jobs.mjs 的runTrackedJob全生命周期维护running时落盘 pid、线程 id结束后写completed/failedjob-control.mjs 负责状态查询与取消/codex:status按最新优先展示任务若同时存在多个活跃任务/codex:cancel会明确要求你带上 job id防止误杀想继续上一段 Codex 任务时如果已有任务在跑插件会直接拒绝still running强制你先查状态——这也是排队机制的一部分见 codex-companion.mjs。所以后台任务天然是先进先出前一个任务不结束后一个任务拿不到执行权。唯一的例外中断请求可以插队排队不等于「卡死」。broker 对turn/interrupt请求开了绿色通道app-server-broker.mjs只要没有别的活跃请求、当前是流式会话任何客户端都能直接发起中断。这样/codex:cancel即使在审查正在流式输出时也能及时叫停并释放槽位避免被取消的任务一直霸占 broker。这套设计带来什么维度单活跃请求复用的效果进程开销✅ 全仓库共享一个 broker 与一条 app-server 连接并发安全✅ 单槽位串行化消除状态竞争用户体验⚠️ 并发审查被排队错峰长任务建议--background跑可恢复性✅ Busy 时自动降级直连中断可插队一句话总结codex-plugin-cc 用「共享 broker 单活跃请求槽 busy 降级直连 显式任务队列」四件套把并发审查从「多路抢跑」变成「有序排队」。理解了 app-server-broker.mjs 里的两个 socket 变量你就理解了整套机制的核心配合 commands/review.md 与 commands/status.md 的说明可以完整掌握从发起到排队再到取结果的全流程。【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址: https://gitcode.com/GitHub_Trending/co/codex-plugin-cc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考