OpenRig：让 Claude Code 与 Codex 协同运行的多智能体编排框架

Harness 封装一个模型，Rig 则封装你的多个 Harness。在 YAML 中定义 Agent 团队，再用一条命令启动它。让 Claude Code 和 Codex 运行在同一个 Rig 中，并作为一个系统统一管理。

OpenRig 将 AI 编码 Agent 从一堆终端会话转变为一个持久化、有组织的团队。向一名主导 Agent 说明你期望的成果；它可以跨团队协调专长 Agent，并向你交付结果以及需要你关注的决策。先从一个代码仓库和一项有用的变更开始，然后让团队的工作与上下文持续保留在相同的位置。

需要 Node.js 20、22 或 24，以及 tmux。启动 Rig 会写入 Provider Hook 和工作区信任设置。在运行以下命令前，请阅读 OpenRig 将对你的机器做出的变更，并备份相关文件。

npm install -g @openrig/cli
rig setup --dry-run

如需改用 Bun 安装，请运行 bun add -g @openrig/cli。OpenRig 仍运行于 Node.js，因此也请安装 Node.js 22。Bun 可能会阻止该软件包的 postinstall 脚本；在这种情况下，下文“OpenRig 将对你的机器做出的变更”中所述的 Node.js 与 SQLite 检查不会在安装时运行。

在应用 rig setup 前，请审阅其安装计划：它会检查原生 Harness 和 cmux。本入门流程需要 tmux 以及已完成认证的 Codex；对于其仓库任务，其他 Harness 和终端 Provider 均为可选项。

启动前，请让你的 Agent 配置你选择的权限：保留提示词、记住选定的命令，或有意识地选择更广泛的访问权限。Agent 会处理配置和验证；OpenRig 随附的默认设置保持不变。

在用于启动的 Shell 中检查前置条件：

tmux -V
codex --version
codex login status

在继续前解决缺失的工具或登录问题。在你的仓库目录中，在启动两个 Codex 席位（一个负责人和一个检查者）前先查看计划：

cd /path/to/your/repository
rig up first-project --cwd . --plan
rig up first-project --cwd .
rig tui --shared

内核提供独立的运行支持与共享仪表板。若要在不停止仪表板的情况下脱离，请按 Ctrl-b，然后按 d；rig tui --shared 会返回该视图。普通的 rig tui 会打开一个独立视图。关闭查看用终端并不意味着你应当重新启动团队。

使用 rig ps --nodes --rig first-project 检查项目席位的就绪状态，并在分配工作前解决任何认证、信任或权限提示。随后，向负责人分配来自你仓库的一项边界明确的目标：

rig send dev-owner@first-project 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-check@first-project to check the exact candidate, and record the result and how I can try it.'
rig queue list --destination dev-owner@first-project --limit 1000

发送消息本身不会创建队列项；负责人会记录该任务。阅读最终产物及其针对确切候选版本的审查结果，然后回到同一位负责人处处理下一项变更。引导式首次使用路径涵盖就绪状态、有用的任务、已审查的结果、Herdr/cmux 终端及恢复流程。

社区

我们的目标是在一天内确认 Issue 和 Pull Request；请参阅 CONTRIBUTING.md，了解审查目标。

OpenRig 将对你的机器做出的变更

OpenRig 在配置和运行期间会写入实例状态、Provider 集成和工作区文件。其中包括信任设置和可执行 Hook。以下摘要对应当前源代码修订版本；使用已发布的软件包时，请检查 rig --version，因为仓库中的指引可能比 npm 上的版本更靠前。

何时	变更内容及原因
npm 安装	在你的 npm 前缀目录下安装 CLI、打包组件和依赖项（使用 Bun 时，安装在 Bun 的全局目录下）。OpenRig 的 postinstall 会检查 Node.js 版本及 SQLite 模块能否加载；Bun 可能阻止此脚本。它不会运行守护进程或 Provider 配置。
rig setup	尝试安装缺失工具，并在 ~/.tmux.conf 中写入 OpenRig 配置块，以支持鼠标和滚动缓冲区。在 macOS 上，它可安装 cmux，并在 ~/.config/cmux/settings.json 中启用其自动化 Socket 控制。--full 会添加工作站工具。--dry-run 会显示配置计划，但不应用变更。
守护进程启动	在 OPENRIG_HOME（通常为 ~/.openrig）下创建或更新实例状态，包括数据库和受管理的插件资源。在 ~/.claude/skills 与 ~/.agents/skills 中植入 openrig-skills 发现技能，但会遵循现有版本的所有权关系。当 runtime.codex.hooks_enabled 启用时（默认启用），将按下文所述写入 Codex Hook 配置和信任记录——即使 Rig 尚未启动也是如此。
Rig/席位启动与附加	创建 tmux 会话，提供席位身份和守护进程连接环境，并将选定的指导、技能、插件和运行时资源映射到工作区。受管理的启动会预先信任工作区。也可为已附加会话配置 Claude 上下文收集，并在监控过程中刷新。
显式权限配置	内置引导程序不会添加 rig 命令允许规则。请让你的 Agent 应用你选择的项目级或用户级作用域；现有规则仍然有效。更广泛的访问权限是另一项独立选择。

Provider 文件与实例状态相互独立。此处的 ~ 指守护进程用户的主目录；仅更改 OPENRIG_HOME 并不能隔离 Provider 配置。

• **Claude Code：**受管理的启动会向 ~/.claude.json 写入工作区信任和已完成入门引导的状态。在工作区中，.claude/settings.local.json 会接收上下文收集器的 statusLine 命令及选定的活动 Hook；辅助脚本位于 .openrig/ 下。选定的设置/MCP 资源也可以修改该设置文件和 .mcp.json。共享设置资源会将 permissions.defaultMode 设为 acceptEdits，并启用 Exa/Context7 MCP 条目；选定的 MCP 资源会配置这些外部服务。内置引导程序不再向 ~/.claude/settings.json 写入命令允许列表，也不会移除旧的许可规则。信任写入器使用守护进程主目录，因此自定义 CLAUDE_CONFIG_DIR 并不能作为这些写入操作的通用重定位方式。
• **Codex：**写入守护进程的 CODEX_HOME/config.toml（通常为 ~/.codex/config.toml）。启动时会启用 Hook、添加 OpenRig 活动中继命令，并为这些命令预写信任哈希。席位启动时会为工作区添加 trust_level = "trusted"；选定的配置资源可添加 MCP 设置。启动期间可跳过已识别的更新通知，并在 Codex 缓存中记录被跳过的版本；这并非安装更新。

活动中继会使用活动令牌，将事件类型/子类型、席位/运行时身份、时间戳和原生会话身份发送至已配置 OpenRig 守护进程的 /api/activity/hooks 端点。该载荷不包含提示词文本和工具参数。Claude 的收集器会将上下文/Token 用量、会话/转录路径元数据以及可用的速率限制数据，写入实例的 state/context-usage 和 state/provider-usage。Provider 和选定 MCP 的连接具有各自的数据流。守护进程插件初始化还会检查 GitHub 上的 OpenRig 插件发布端点。

受管理的启动会提供 HOME、CODEX_HOME 以及 OPENRIG_* 身份/连接变量。Claude 使用 --permission-mode acceptEdits，并默认使用经典渲染器以支持终端滚动缓冲区。除非命名 Profile 管理其沙箱，否则 Codex 使用 -s workspace-write；OpenRig 不会强制设置审批策略标志。新的 Codex 启动还会通过 --add-dir 为工作区的 .git 和 Pod 的共享队列状态目录添加可写访问权限；共享根目录来自 OPENRIG_SHARED_DOCS_ROOT 或 ~/.openrig/shared-docs。YOLO 默认关闭。显式设置 OPENRIG_YOLO=1 或采用完全绕过权限的席位策略时，将选择 Claude 的 --dangerously-skip-permissions 或 Codex 的 -s danger-full-access；已解析的席位策略优先于环境变量设置。

受管理的 Hook 配置块针对 OpenRig 的条目，并会保留无关 Hook，但信任条目、选定的资源键以及 Claude 现有的状态栏命令可能会被替换。某些写入器会将无法读取的设置恢复为空对象；这并不保证完整保留或可回滚。首次使用前请备份相关文件。守护进程/引导程序写入会自动执行，并非每项操作都有交互式预览；rig setup --dry-run 不会预览之后每一次启动造成的所有影响。

OpenRig 是一个多智能体 Harness——它管理的是当你同时运行多个编码 Agent 时形成的系统。它管理的不是 Agent 本身，而是它们构成的团队：哪些会话正在运行、彼此如何关联、重启后如何恢复，以及如何避免终端会话蔓延失控。

• 在 YAML（RigSpec）中定义包含 Pod、边和连续性策略的拓扑
• 使用 rig up 启动所有内容——tmux 会话、Harness、启动文件和就绪检查
• 在 TUI 拓扑表格和图形中查看 Rig、Pod 和席位；检查项目、Spec、信息流和实例健康状态
• 发现 tmux 中现有的 Claude Code 和 Codex 会话，并将其纳入受管理 Rig
• 使用 rig down --snapshot 快照保存拓扑，通过 rig up <name> 按名称恢复
• 使用 rig send、rig broadcast 和 rig chatroom 在 Agent 间通信
• 使用 rig grow、rig shrink、rig launch、rig remove 演进正在运行的拓扑

每个 Agent 都运行在一个 tmux 会话中，你可以附加、检查并直接与之协作。

使用 first-project 进行专注的首次使用流程。product-team 是一个可选的、更大型产品开发示例：

rig specs preview product-team --kind rig
rig up product-team

当你需要一个规模更大的产品团队时可使用它：其中包括两名编排者、实现、QA、设计，以及两名独立审查者。

如需更小的入门配置，请使用 conveyor：

rig specs preview conveyor --kind rig
rig up conveyor

conveyor 是一个混合 Claude Code 与 Codex 的四席位入门配置。它展示了一条经过需求接收、规划、构建和审查的交接路径；first-project 仍然是更小的双席位起点。

此外还提供：implementation-pair、adversarial-review、research-team 和 secrets-manager（由专业 Agent 管理 HashiCorp Vault）。

浏览资源库：

OpenRig 是一个构建于 tmux 之上的本地守护进程 + CLI + 终端 UI + MCP 服务器。较旧的 React Web UI 仍处于维护模式，并提供尽力而为的支持。

CLI / TUI / MCP
      |
Hono HTTP daemon
      |
  Domain services
      |
  SQLite + tmux + runtime adapters

• CLI：供人类和 Agent 使用的命令，用于启动团队、检查状态、发送消息、跟踪负责的工作以及管理上下文。
• TUI：拓扑浏览器，提供表格和图形视图、席位详情、Specs、Projects、Terminals、Feed 和 System。可通过键盘、鼠标或命令栏导航。
• MCP：让 Agent 管理自身拓扑的工具（rig_up、rig_ps、rig_send、rig_chatroom_send 等）。
• 运行时：原生 Claude Code 和 Codex 会话、终端节点，以及通过终端窗格内 RPC Runner 运行的 Pi 适配器。

终端 UI 与工作区

TUI 展示团队的协调状态；herdr 和 cmux 则在其旁边展示实际的 Agent 终端。使用 rig tui commands 列出 TUI 命令栏的导航命令，或试用交互式 TUI 导览。

截取自使用虚构项目数据的交互式 TUI 演示。

安装并连接 herdr 后，可一同打开入门配置的终端：

rig terminal open first-project --provider herdr

对于 cmux，请使用 --provider cmux。底层会话仍可通过 tmux 访问。有关配置及返回现有视图，请参阅终端工作区指南。

• RigSpec：声明式多智能体编排...

A harness wraps a model. A rig wraps your harnesses. Define your agent team in YAML, boot it with one command. Claude Code and Codex in the same rig, managed as one system.

OpenRig turns AI coding agents from a pile of terminal sessions into a persistent, organized team. Talk to a lead agent about the outcome you want; it can coordinate specialists across teams and bring you results and decisions that need your attention. Start with a repository and one useful change, then keep the team's work and context at the same addresses.

Requires Node.js 20, 22 or 24 and tmux. Launching a rig writes provider hooks and workspace trust settings. Before running the commands below, read what OpenRig changes on your machine and back up the relevant files.

npm install -g @openrig/cli
rig setup --dry-run

To install with Bun instead, run bun add -g @openrig/cli. OpenRig still runs on Node.js, so install Node.js 22 as well. Bun may block this package's postinstall script, in which case the Node.js and SQLite check described under what OpenRig changes on your machine does not run at install time.

Review setup's plan before applying rig setup: it checks both native harnesses and cmux. This starter requires tmux and authenticated Codex; the other harness and terminal provider are optional for its repository task.

Before launching, ask your agent to configure your chosen permissions: keep prompts, remember selected commands, or deliberately choose broader access. The agent handles setup and verification; OpenRig's shipped defaults stay unchanged.

Check prerequisites in your launch shell:

tmux -V
codex --version
codex login status

Resolve missing tools or login before continuing. From your repository, inspect the plan before launching the two Codex seats, an owner and a checker:

cd /path/to/your/repository
rig up first-project --cwd . --plan
rig up first-project --cwd .
rig tui --shared

The kernel provides separate operational support and the shared dashboard. To detach without stopping the dashboard, press Ctrl-b then d; rig tui --shared returns to that view. Plain rig tui opens an independent view. Closing a viewing terminal does not mean you should relaunch the team.

Check project-seat readiness with rig ps --nodes --rig first-project and resolve any authentication, trust or permission prompt before assigning work. Then give the owner one bounded outcome from your repository:

rig send dev-owner@first-project 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-check@first-project to check the exact candidate, and record the result and how I can try it.'
rig queue list --destination dev-owner@first-project --limit 1000

Sending a message does not itself create a queue item; the owner records the task. Read the final artifact and the review of its exact candidate, then return to the same owner for the next change. The guided first-use path covers readiness, a useful task, a reviewed result, Herdr/cmux terminals and recovery.

Community

We aim to acknowledge issues and pull requests within one day; see CONTRIBUTING.md for review targets.

What OpenRig changes on your machine

OpenRig writes instance state, provider integration and workspace files as part of setup and operation. These include trust settings and executable hooks. The summary below follows this source revision; check rig --version when using a published package, since repository guidance can be ahead of npm.

When	What changes and why
npm installation	Installs the CLI, bundled components and dependencies under your npm prefix (with Bun, under Bun's global directory). OpenRig's postinstall checks the Node.js version and that the SQLite module loads; Bun may block this script. It does not run daemon or provider setup.
rig setup	Attempts missing tools and writes an OpenRig block in ~/.tmux.conf for mouse support and scrollback. On macOS it can install cmux and enable its automation socket control in ~/.config/cmux/settings.json. --full adds workstation tools. --dry-run shows setup's plan without applying it.
Daemon startup	Creates/updates instance state under OPENRIG_HOME (normally ~/.openrig), including its database and managed plugin resources. Seeds the openrig-skills discovery skill in ~/.claude/skills and ~/.agents/skills, subject to existing version ownership. With runtime.codex.hooks_enabled enabled (the default), writes Codex hook configuration and trust records as described below—even before a rig launches.
Rig/seat launch and attachment	Creates tmux sessions, supplies seat identity and daemon connection environment, and projects selected guidance, skills, plugins and runtime resources into the workspace. Managed startup pre-trusts the workspace. Claude context collection can also be provisioned for attached sessions and refreshed during monitoring.
Explicit permission configuration	The built-in bootstrap does not add rig command allow rules. Ask your agent to apply your chosen project or user scope; existing rules remain relevant. Broader access is a separate choice.

The provider files are separate from instance state. Here ~ means the daemon user's home; changing OPENRIG_HOME alone does not isolate provider configuration.

• Claude Code: managed startup writes workspace trust and onboarding completion to ~/.claude.json. In the workspace, .claude/settings.local.json receives the context collector's statusLine command and selected activity hooks; helper scripts live under .openrig/. Selected settings/MCP resources can also change that settings file and .mcp.json. The shared settings resource sets permissions.defaultMode to acceptEdits and enables Exa/Context7 MCP entries; selected MCP resources configure those external services. Built-in bootstrap no longer writes a command allowlist to ~/.claude/settings.json or removes older allowances. The trust writer uses the daemon home, so a custom CLAUDE_CONFIG_DIR is not a general relocation of these writes.
• Codex: writes the daemon's CODEX_HOME/config.toml (normally ~/.codex/config.toml). Startup enables hooks, adds the OpenRig activity relay commands and pre-writes trust hashes for those commands. Seat startup adds trust_level = "trusted" for the workspace; selected config resources can add MCP settings. Recognized update notices can be skipped during launch, recording the skipped version in Codex's cache; this is not an update install.

Activity relays send event type/subtype, seat/runtime identity, timestamps and native session identity to the configured OpenRig daemon's /api/activity/hooks endpoint, using its activity token. That payload excludes prompt text and tool arguments. Claude's collector writes context/token usage, session/transcript-path metadata and available rate-limit data to the instance's state/context-usage and state/provider-usage. Provider and selected MCP connections have their own data flows. Daemon plugin initialization also checks the OpenRig plugin release endpoint on GitHub.

Managed launches supply HOME, CODEX_HOME and OPENRIG_* identity/connection variables. Claude uses --permission-mode acceptEdits and defaults to the classic renderer for terminal scrollback. Codex uses -s workspace-write unless a named profile governs its sandbox; OpenRig does not force an approval-policy flag. Fresh Codex launches also add writable access to the workspace's .git and the pod's shared queue-state directory with --add-dir; the shared root comes from OPENRIG_SHARED_DOCS_ROOT or ~/.openrig/shared-docs. YOLO is off by default. Explicit OPENRIG_YOLO=1 or a full-bypass seat policy selects Claude's --dangerously-skip-permissions or Codex's -s danger-full-access; a resolved seat policy takes precedence over the environment setting.

Managed hook blocks target OpenRig's entries and retain unrelated hooks, but trust entries, selected resource keys and Claude's existing status-line command can be replaced. Some writers recover unreadable settings as empty objects; this is not a complete preservation or rollback guarantee. Back up relevant files before first use. Daemon/bootstrap writes are automatic and do not each have an interactive preview; rig setup --dry-run does not preview every later startup effect.

OpenRig is a multi-agent harness — it manages the system that coding agents form when you run them together. Not the agents themselves, but the team they create: which sessions are running, how they relate, how to recover after a reboot, and how to stop it from becoming terminal sprawl.

• Define topologies in YAML (RigSpec) with pods, edges, and continuity policies
• Boot everything with rig up — tmux sessions, harnesses, startup files, readiness checks
• See rigs, pods, and seats in the TUI topology table and graph; inspect projects, specs, feeds, and instance health
• Discover existing Claude Code and Codex sessions in tmux and adopt them into a managed rig
• Snapshot the topology with rig down --snapshot, restore by name with rig up <name>
• Communicate across agents with rig send, rig broadcast, and rig chatroom
• Evolve running topologies with rig grow, rig shrink, rig launch, rig remove

Every agent runs in a tmux session you can attach to, inspect, and work with directly.

Use first-project for the focused first-use path. product-team is an optional larger product-development example:

rig specs preview product-team --kind rig
rig up product-team

Use it when you want a larger product squad: two orchestrators, implementation, QA, design, and two independent reviewers.

For a smaller starter, use conveyor:

rig specs preview conveyor --kind rig
rig up conveyor

conveyor is a four-seat starter mixing Claude Code and Codex. It shows a handoff path through intake, planning, build, and review; first-project remains the smaller two-seat starting point.

Also ships: implementation-pair, adversarial-review, research-team, and secrets-manager (HashiCorp Vault managed by a specialist agent).

Browse the library:

OpenRig is a local daemon + CLI + terminal UI + MCP server, built on tmux. The older React web UI remains in maintenance mode with best-effort support.

CLI / TUI / MCP
      |
Hono HTTP daemon
      |
  Domain services
      |
  SQLite + tmux + runtime adapters

• CLI : Commands for both humans and agents to launch teams, inspect state, send messages, track owned work, and manage context.
• TUI : Topology explorer, table and graph views, seat details, Specs, Projects, Terminals, Feed, and System. Navigate with the keyboard, mouse, or command bar.
• MCP : Tools so agents can manage their own topology (rig_up, rig_ps, rig_send, rig_chatroom_send, etc.)
• Runtimes : Native Claude Code and Codex sessions, terminal nodes, and a Pi adapter using an RPC runner inside a terminal pane.

Terminal UI and Workspaces

The TUI shows the team's coordination state; herdr and cmux show the actual agent terminals alongside it. Use rig tui commands to list the TUI's command-bar navigation, or try the interactive TUI tour.

Captured from the interactive TUI demo using fictional project data.

With herdr installed and connected, open the starter's terminals together:

rig terminal open first-project --provider herdr

For cmux, use --provider cmux. The underlying sessions remain accessible through tmux. See the terminal workspace guide for setup and returning to an existing view.

• RigSpec : Declarative multi-agent harness definition in YAML. Pods, members, edges, continuity policies, culture file.
• AgentSpec : Reusable agent blueprint with skills, guidance, hooks, profiles, and startup contracts.
• Seat : A stable role and address in a rig, such as dev-owner@first-project. The conversation occupying it can change while its identity and authored context remain.
• Pod : A group of related seats with shared guidance and context. Each agent still has its own context window.
• Discovery : rig discover fingerprints existing tmux sessions. rig adopt brings them under management.
• Snapshot/Restore : rig down --snapshot captures full state. rig up <name> restores from latest snapshot. Restore reports per-node outcomes (resumed, fresh, or failed).
• RigBundle : Portable archive with vendored AgentSpecs and SHA-256 integrity. Share topologies across machines.
• Culture : CULTURE.md sets coordination norms for the group. Research rigs get exploratory culture. Implementation rigs get conservative, trust-but-verify culture.

A rig can package actual software alongside the agents that manage it. The shipped example is secrets-manager: a HashiCorp Vault instance operated by a specialist agent.

rig up secrets-manager
rig env status secrets-manager
rig send vault-specialist@secrets-manager "Check Vault health and report status." --verify

Requires Docker for service-backed rigs.

Upgrading an existing instance

For an existing installation, follow the upgrade procedure and the 0.5.14 release notes. Preserve live seats during the upgrade; rig down is not an upgrade step.

Crossing the 0.5.9 layout boundary

The migration below still applies when upgrading from a pre-0.5.9 instance.

0.5.9 makes $OPENRIG_HOME/context the addressable context library, writes Claude telemetry to state/context-usage (and provider telemetry to state/provider-usage), and installs the default System World at context/system/system-world.yaml. Existing instances cross this boundary by an Agent-Operated Migration from the shipped openrig-upgrade skill. The target runtime reads canonical-first with legacy-fallback while new writes use the canonical roots; a custom context-library root stays stable during activation. This is not a directory rename to do while an old collector writes.

# SKILL_DIR is the installed openrig-upgrade skill directory.
node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" --help
node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" --home "$OPENRIG_HOME"
node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" --home "$OPENRIG_HOME" --apply-state --preimage /safe/path/layout-0.5.9-before

# Activate the exact target runtime separately. After every bounded legacy tail is followed by newer paired samples at both new state roots:
node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" --home "$OPENRIG_HOME" --verify --preimage /safe/path/layout-0.5.9-before > /safe/path/layout-0.5.9-verify.json

# Run the separately invoked non-destructive finalizer only with that exact receipt:
node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" --home "$OPENRIG_HOME" --apply-library --preimage /safe/path/layout-0.5.9-before --verification /safe/path/layout-0.5.9-verify.json

# Restore only helper-owned preparation/finalizer effects if the observed upgrade must be reversed:
node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" --home "$OPENRIG_HOME" --rollback /safe/path/layout-0.5.9-before

--help prints the phase grammar without inventorying the instance. No phase flag intentionally runs the read-only plan; unknown options fail nonzero before plan or mutation.

Every phase emits JSON. Stop on any issue or incomplete receipt and follow its next action; do not continue from copied legacy telemetry or retry a partial mutation blindly. Preparation leaves legacy state and collector settings in place. Verification accepts exact tail bytes only when that same seat has newer paired context and provider samples under state/; finalization revalidates the accepted tails, copies the library without overwrite, and switches config last. The helper never removes the legacy telemetry or library. Retirement follows separate stable runtime, writer, reader, and recovery proof. Daemon, database, seat, plugin, and release lifecycle actions remain agent-owned.

• Node.js 20, 22, or 24 (the supported versions in this release)
• tmux

Optional:

• herdr or cmux for terminal workspaces showing the agents together
• Docker for service-backed rigs and managed apps

Setup and Troubleshooting

• rig setup attempts core machine preparation: tmux, cmux, Claude Code, Codex, and tmux defaults. It reports what it tried and what actually succeeded. If something fails, it gives the local agent enough context to finish the job.
• rig setup --full attempts a broader operator workstation setup (jq, gh) on top of core.
• rig doctor inspects current system health and helps diagnose problems after setup. Use it when something stops working or after machine changes.

Both commands support --json for agent-driven workflows.

Before setup or managed launch, review what OpenRig changes on your machine, including provider trust, hooks and selected runtime resources.

Already-running adopted sessions may need restart before they pick up newly written runtime config.

For agents: Ask the user whether they want core setup (rig setup) or the fuller workstation path (rig setup --full) before choosing the invocation. Inspect the result with --json and use rig doctor to finish any remaining machine-specific issues.

Comparison with Claude Managed Agents

OpenRig is open source and self-hosted, with Claude Code and Codex in the same team. You operate it on your own infrastructure; the selected providers' model usage costs still apply.

Full comparison

Apache 2.0