OpenRig：用 YAML 把 Claude Code 与 Codex 组织成可恢复团队
一个把 Claude Code 和 Codex 终端组织成可恢复协作团队的本地工具，不再靠散乱 tmux 会话管理。
GitHub mvschwarz/openrig 更新 2026-09-28 分支 main 星标 976 分叉 104
TypeScript 多智能体编排 Claude Code Codex tmux Node.js 20/22/24 SQLite MCP

🧭 决策指南

为什么现在热： 无法从材料判断

适合，如果你

  • 你要在一个仓库里让 Claude Code 与 Codex 分工，并需要 owner、checker 两个 seat 的交接。
    README「Install and first run」展示了 first-project、dev-owner@first-project 与 dev-check@first-project 的两座席流程。
  • 你需要用 YAML 固化 pods、edges、continuity policies，并在重启后恢复拓扑。
    README「What It Does」明确支持 RigSpec YAML、rig down --snapshot 和按名称恢复。
  • 你希望在 TUI 查看拓扑、项目、feed、Spec 和 instance health，同时保留 tmux 终端访问。
    README「What It Does」与「How It Works」分别描述 TUI topology table/graph 和可直接 attach 的 tmux session。
  • 你需要由 agent 通过 MCP 管理自己的 rig，例如执行 rig_up、rig_ps 和 rig_send。
    README「How It Works」列出了 MCP 工具 rig_up、rig_ps、rig_send 和 rig_chatroom_send。

不适合，如果你

  • 你的环境不能安装 Node.js 20、22 或 24，或没有 tmux。
    README「Requirements」将 Node.js 20/22/24 与 tmux 列为要求。
  • 你不能接受 rig setup 修改 provider hooks 或 workspace trust settings。
    README「Install and first run」说明启动 rig 会写入这些配置，并要求先阅读变更章节。
  • 你需要成熟的 React Web UI，而不是 TUI、CLI 或 tmux 工作流。
    README「How It Works」说明旧 React Web UI 处于 maintenance mode，best-effort 支持。
  • 你不希望自行运行基础设施，倾向由服务商托管 agent 团队。
    README「Comparison with Claude Managed Agents」将 OpenRig 描述为 open source、self-hosted、运行在自有基础设施上。

前置条件

  • Node.js 20, 22, or 24
  • tmux
  • starter requires tmux and authenticated Codex
  • Optional: herdr or cmux for terminal workspaces
  • Optional: Docker for service-backed rigs and managed apps
  • Launching a rig writes provider hooks and workspace trust settings

第一步命令（README 原文）

npm install -g @openrig/cli

要注意

  • 使用 Bun 安装时，package 的 postinstall 可能被阻止。
    README「Install and first run」明确说明 Bun may block this package's postinstall script。
  • 已接管的既有 session 可能需要重启，才能加载新写入的 runtime config。
    README「Setup and Troubleshooting」说明 already-running adopted sessions may need restart。
  • rig setup 前要区分核心 setup 与 rig setup --full，后者还会尝试安装 jq、gh。
    README「Setup and Troubleshooting」列出两种 setup 路径及其差异。
  • 关闭查看终端不会停止 dashboard，也不应因此重新启动团队。
    README「Install and first run」说明 closing a viewing terminal does not mean relaunch the team。

替代方案

  • Claude Managed Agents：当你不想在自有基础设施上运行 OpenRig，或希望使用托管式 agent 团队时更合适。
    README「Comparison with Claude Managed Agents」
  • tmux 原生会话：当需求只是直接创建和查看终端会话，不需要 RigSpec、TUI 拓扑、MCP 或 rig send 等团队管理能力时更简单。
    通用领域知识

材料未说明

  • README 未说明支持的操作系统及各平台差异。
  • README 未提供可管理的最大 agent、pod 或 seat 数量。
  • README 未给出多智能体运行的性能、资源占用或并发限制。
  • README 未说明 Claude Code 与 Codex 的具体模型版本兼容矩阵。
  • README 未说明 provider hooks 和 workspace trust settings 的具体文件路径、内容与回滚方式。
  • README 未提供 Claude Code、Codex 或 OpenRig 的实际使用成本明细。
  • README 未说明 SQLite 数据库的备份、迁移和并发写入策略。
  • README 未说明 agent 间消息的认证、授权和敏感信息保护机制。

💡 深度解析

6
不适合 我的工作站已经安装 Node.js 22 和 tmux，但 Codex 认证、workspace trust 和 provider hooks 可能还没配置好；我应该直接启动 first-project 吗？
适合读者： 维护 Node.js 20、22 或 24 工作站、已有 tmux 但需要确认 Codex 登录和机器配置影响的本地自托管用户

不适合直接启动，因为 README 要求先审查 OpenRig 会修改的机器配置，并确认 Codex 已登录。

  • 安装要求是 Node.js 20、22 或 24 以及 tmux；但运行 starter 还需要 authenticated Codex。
  • rig setup --dry-run 会展示 provider hooks、workspace trust、tmux 默认配置及相关运行时资源的计划，README 要求先阅读并备份相关文件。
  • 启动前应确认 tmux -V、codex --version 和 codex login status，否则代理可能停在认证、信任或权限提示上。
  • rig doctor 可在 setup 后检查系统健康；已有被接管会话可能还需重启才能读取新写入的运行时配置。
  • Install and first run："Requires Node.js 20, 22 or 24 and tmux."
  • Install and first run："This starter requires tmux and authenticated Codex"
  • Install and first run："rig setup --dry-run"
  • Setup and Troubleshooting："Already-running adopted sessions may need restart before they pick up newly written runtime config."
rig setup --dry-run
材料未说明：README 没有列出 workspace trust 或 provider hooks 在不同操作系统上的具体文件路径。；README 没有说明企业代理、凭据管理或网络策略是否会阻止 setup。
不适合 我不习惯 tmux 和键盘式 TUI，更希望通过远程 Web 控制台查看 Claude Code 与 Codex 的拓扑和任务；OpenRig 是否适合我的工作方式？
适合读者： 在偏好图形化 IDE 或远程 Web 控制台的开发环境中、但仍想查看 Claude Code 与 Codex 团队状态的开发者

不适合，因为 OpenRig 的主要交互面是 CLI、TUI、MCP 和 tmux，旧 React Web UI 只处于维护模式。

  • README 的架构明确列出 local daemon、CLI、terminal UI、MCP server，并以 tmux 承载代理会话。
  • TUI 提供拓扑表格和图、Feed、Projects、Terminals 与健康状态，但这仍是终端界面，不是远程 Web 控制台。
  • README 明确说 older React web UI remains in maintenance mode with best-effort support，因此不能把它当作主要产品入口。
  • rig tui --shared 可共享仪表板，但关闭查看终端不等于停止团队；这更适合熟悉终端工作流的本地用户。
  • How It Works："The older React web UI remains in maintenance mode with best-effort support."
  • How It Works："OpenRig is a local daemon + CLI + terminal UI + MCP server, built on tmux."
  • What It Does："See rigs, pods, and seats in the TUI topology table and graph"
  • Install and first run："rig tui --shared"
rig tui --shared
材料未说明：README 未说明是否支持通过 SSH、反向代理或浏览器安全地远程访问 daemon。；README 未说明旧 Web UI 当前支持哪些拓扑、任务和恢复操作。
视情况 我目前想在一台机器上用 SQLite 管理 Claude Code 和 Codex，但后续需要跨主机、多用户和高可用代理编排；OpenRig 能作为长期生产控制平面吗？
适合读者： 需要在单机 SQLite 控制面上管理 Claude Code、Codex 和 tmux 会话，但计划扩展到跨主机高可用编排的技术负责人

视情况：它适合单机、自托管的本地控制面，但不能仅凭 README 视为跨主机高可用平台。

  • 架构使用本地 daemon、SQLite 和 tmux，Requirements 也把核心依赖限定为本地 Node.js 与 tmux。
  • README 强调 self-hosted、own infrastructure，以及本地会话、拓扑、快照和恢复，这与单机开发环境匹配。
  • Docker 只是 service-backed rigs 和 managed apps 的可选依赖，并不表示 daemon、SQLite 或 tmux 已具备集群协调能力。
  • 项目洞察明确指出 SQLite 和本地 daemon 适合单机或单用户控制面，不应直接视为跨主机集群或高可用架构。
  • How It Works："OpenRig is a local daemon + CLI + terminal UI + MCP server, built on tmux."
  • How It Works："SQLite + tmux + runtime adapters"
  • Requirements："Docker for service-backed rigs and managed apps"
  • 项目洞察："SQLite和本地daemon适合单机或单用户控制平面"
rig doctor
材料未说明：README 未说明跨主机节点发现、SQLite 复制、故障转移或多用户隔离方案。；README 未说明 daemon 是否支持远程部署、TLS、水平扩展或外部数据库。
适合 我已经在本地仓库使用 Claude Code 和 Codex，但现在需要分别维护多个终端会话；我能否用 OpenRig 把一个 owner 和一个 checker 组织成可检查、可恢复的团队？
适合读者： 需要在本地仓库中同时运行 Claude Code 和 Codex、并用 tmux 管理两个代理席位的开发者

适合，因为 OpenRig 正是把 Claude Code 和 Codex 从分散终端会话提升为统一管理的 Rig。

  • README 的首次运行流程明确提供两个 Codex seat：owner 和 checker，并通过 rig send 分派一个边界清晰的仓库任务。
  • 每个代理都运行在独立 tmux session 中，可以附加、检查，不依赖当前查看窗口是否仍然打开。
  • rig ps --nodes、TUI、任务队列和消息命令能分别查看节点就绪状态、拓扑和任务记录。
  • rig down --snapshot 与按名称恢复可保留拓扑和协调上下文，但不等于代码、凭据或外部服务的完整备份。
  • Install and first run："inspect the plan before launching the two Codex seats, an owner and a checker"
  • Install and first run："rig ps --nodes --rig first-project"
  • What It Does："Every agent runs in a tmux session you can attach to, inspect, and work with directly."
  • What It Does："Snapshot the topology with rig down --snapshot, restore by name with rig up"
rig setup --dry-run
材料未说明：README 没有量化单个 Rig 可稳定运行的最大 seat 数量。；README 没有说明快照能恢复多少代理上下文，以及恢复后未提交代码的具体行为。
适合 我想把实现和审查拆给 owner 与 checker，并要求 checker 审查准确的候选变更、记录测试方式和结论；OpenRig 是否能支撑这个交接流程？
适合读者： 使用 first-project 或 adversarial-review 流程、要求 owner 交付精确候选版本并由独立 checker 审查的小型工程团队负责人

适合，因为 README 的 first-project 流程已经把 owner、checker、任务队列和精确候选审查串成一条路径。

  • rig send 的示例要求 owner 实现一个具体变更、在 queue 中记录任务 ID、验证行为，并让 dev-check 检查 exact candidate。
  • rig queue list 可以按 destination 查看 owner 记录的任务；README 特别说明发送消息本身不会创建 queue item。
  • OpenRig 支持 rig send、rig broadcast、rig chatroom，适合传递交接信息，但代码正确性仍取决于代理和人工阅读最终产物。
  • starter rigs 包含 first-project、conveyor、implementation-pair、adversarial-review 等模板；README 没有保证模板适用于所有仓库结构。
  • Install and first run："Keep it local, verify the behavior, ask dev-check@first-project to check the exact candidate"
  • Install and first run："Sending a message does not itself create a queue item; the owner records the task."
  • What It Does："Communicate across agents with rig send, rig broadcast, and rig chatroom"
  • 项目洞察：starter rigs 包括 first-project、conveyor、implementation-pair、adversarial-review
rig up first-project --cwd . --plan
材料未说明：README 未说明 queue 是否支持依赖关系、截止时间或跨 Rig 查询。；README 未定义 checker 如何标记失败、阻断 owner 继续工作或自动触发返工。
适合 我用 TypeScript 构建本地代理流程，希望 Claude Code 或 Codex 能通过 MCP 自己执行 rig_up、rig_ps 和 rig_send，同时让我用 TUI 查看拓扑；OpenRig 能满足这种控制面约束吗？
适合读者： 希望让代理自行管理拓扑、同时要求人类通过 CLI 或 TUI 观察状态的 TypeScript AI 工程实验者

适合，因为 OpenRig 将 CLI、TUI 和 MCP 接入同一个本地 daemon，而不是为代理和人类维护两套状态。

  • 架构章节给出的路径是 CLI / TUI / MCP → Hono HTTP daemon → domain services → SQLite、tmux 和 runtime adapters。
  • MCP 提供 rig_up、rig_ps、rig_send、rig_chatroom_send 等工具，代理可以参与拓扑和通信管理。
  • TUI 能查看 Rig、Pod、Seat、Specs、Feed、Projects、Terminals 和实例健康状态。
  • 项目主语言是 TypeScript，但 README 没有承诺 MCP 工具可直接嵌入任意 TypeScript 应用；这里描述的是代理运行时的 MCP 接入。
  • How It Works："OpenRig is a local daemon + CLI + terminal UI + MCP server"
  • How It Works："MCP: Tools so agents can manage their own topology (`rig_up`, `rig_ps`, `rig_send`, `rig_chatroom_send`, etc.)"
  • How It Works："CLI / TUI / MCP → Hono HTTP daemon → Domain services → SQLite + tmux + runtime adapters"
  • 项目数据：主语言为 TypeScript
rig doctor
材料未说明：README 未说明 MCP server 的传输配置、鉴权方式和端口默认值。；README 未说明多个代理同时修改拓扑时的并发冲突处理规则。

✨ 核心亮点

  • YAML RigSpec 定义 pods、edges 与连续性策略
  • rig up 一条命令启动 tmux、harnesses 与检查
  • TUI 同时查看 rigs、pods、seats 与实例健康
  • 支持发现并接管 tmux 中的 Claude Code 与 Codex
  • 安装要求 Node.js 20/22/24、tmux 与 Codex 登录

🔧 工程化

  • 用 RigSpec YAML 描述多智能体拓扑、pods、edges 和恢复策略。
  • 用 rig send、rig broadcast 和 rig chatroom 在 Claude Code 与 Codex 间通信。
  • 用 rig down --snapshot 保存拓扑，再用 rig up 按名称恢复。
  • CLI、TUI、MCP 与 SQLite/tmux 共同管理团队状态和终端会话。

⚠️ 风险

  • rig setup 会写入 provider hooks 与 workspace trust settings，需先审阅变更。
  • starter 要求 tmux 与已认证 Codex，缺少登录会阻断启动流程。
  • Bun 可能阻止 postinstall，导致 Node.js 与 SQLite 检查不在安装时运行。
  • 旧 React Web UI 处于 maintenance mode，仅提供 best-effort 支持。

👥 适合谁？

  • 需要在本地 tmux 中协同 Claude Code 与 Codex 的开发团队。
  • 希望用 YAML 管理多座席拓扑、交接、审查与恢复的工程师。
  • 使用 Node.js 20/22/24，并能维护 SQLite、tmux 和本机运行时的用户。