OpenRig
Turn Claude Code and Codex into a persistent agent team: define the topology in YAML, boot it with one command, manage and restore it as one system.
- Source repo
- mvschwarz/openrig
- Stars
- ★ 4.9k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 79/100 · Good
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A solo developer starts an owner/checker pair (first-project starters) in their repository, with a Claude owner coordinating a Codex checker to ship one reviewed change
- Not a fit if
- Native Windows users or teams needing tested WSL2 support
- Developers who want a single coding agent with no multi-agent coordination
- Environments unwilling to have provider trust settings and hooks written locally
- Source review
- 79/100 · Good
What does this agent do, and when should you use it?
OpenRig is an open-source multi-agent harness: instead of wrapping a model, it manages the system of coding agents you run together. It runs locally as a daemon + CLI + terminal UI + MCP server, built on tmux and SQLite. You declare topologies as YAML RigSpecs (pods, members, edges, continuity policies), then boot the whole team with `rig up`, with every agent living in a tmux session you can attach to. It runs Claude Code and Codex natively in the same rig, plus Pi and Oh My Pi via RPC runners. Shipped starter rigs include first-project, conveyor, product-team, and a secrets-manager rig where a specialist agent operates a HashiCorp Vault instance. It requires Node.js 22 or 24, tmux, and currently supports macOS and Linux only.
OpenRig reads YAML RigSpecs (pods, members, edges, continuity policies, CULTURE.md), and rig up creates tmux sessions, supplies seat identity and daemon connection environment, projects startup files, and runs readiness checks. At runtime it provides: cross-agent communication via rig send, rig broadcast, and rig chatroom; inspection via rig ps and a TUI with topology table, graph, and seat detail views; session discovery and adoption via rig discover and rig adopt; snapshot/restore via rig down --snapshot and rig up <name>; live topology evolution via rig grow, rig shrink, rig launch, and rig remove; task queues via rig queue list; a typing guard for human-typed seats; Slack via rig slack manifest; and permission governance via rig policy permissions and rig seat set-permissions. MCP tools (rig_up, rig_ps, rig_send, rig_chatroom_send, etc.) let agents manage their own topology. Architecture: Hono HTTP daemon, domain services, SQLite + tmux + runtime adapters.
- A solo developer starts an owner/checker pair (first-project starters) in their repository, with a Claude owner coordinating a Codex checker to ship one reviewed change
- An engineer juggling multiple AI terminal sessions uses rig down --snapshot and rig up <name> to save and restore the whole team after a reboot
- A team that wants mixed vendors runs Claude Code agents and Codex agents in one rig with shared context and queues
- A user with scattered Claude/Codex tmux sessions uses rig discover + rig adopt to bring them under management
- A larger product squad boots product-team: two orchestrators, implementation, QA, design, and two independent reviewers
- An operator runs the secrets-manager rig and asks vault-specialist to check a managed Vault's health via rig send --verify
How do you install or deploy this agent?
Prerequisites: Node.js 22 or 24 (22 on Apple Silicon Macs), tmux, macOS or Linux; a working Claude Code and/or Codex account. Install the CLI and preview setup:
bash
npm install -g @openrig/cli
rig setup --dry-runOr install with Bun:
bash
bun add -g @openrig/cliBefore installing, read the README section "What OpenRig changes on your machine" and back up relevant files: setup writes tmux config, daemon startup creates instance state under ~/.openrig, seeds the openrig-skills skill in ~/.claude/skills and ~/.agents/skills, and writes trust and hooks settings into Claude/Codex provider configuration.
How do you use this agent?
Enter your repository, pick a starter (first-project, first-project-claude, or first-project-mixed), preview, plan, and boot:
bash
cd /path/to/your/repository
starter=first-project # or first-project-claude / first-project-mixed
rig specs preview "$starter" --kind rig
rig up "$starter" --cwd . --planrig up "$starter" --cwd .
rig tui --sharedCheck seat readiness and give the owner one bounded task:
bash
rig ps --nodes --rig "$starter"
rig send "dev-owner@$starter" 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-check in this rig to check the exact candidate, and record the result and how I can try it.'
rig queue list --destination "dev-owner@$starter" --limit 1000Press Ctrl-b then d to detach from the shared TUI without stopping the dashboard; rig tui --shared returns to it. Browse the full spec library with rig specs ls.
What are this agent's strengths and limitations?
- Cross-vendor teams: Claude Code and Codex collaborate in one rig; the mixed starter (first-project-mixed) works out of the box
- Persistence and recovery: snapshot/named restore (rig down --snapshot, rig up <name>), stable seat identities that survive occupant changes
- Declarative, evolvable topology: YAML RigSpecs with pods/edges/continuity policies, adjusted live via rig grow/shrink/launch/remove
- Agent-managed operation: MCP tools let agents boot topology, message each other, and manage queues; typing-guard protects human-typed seats
- Full operational surface: TUI graph/table views, rig doctor health diagnostics, RigBundle portable archives with SHA-256 integrity
- Platform limits: no native Windows support, WSL2 untested; macOS and Linux only
- Modifies local provider configuration: writes ~/.codex/config.toml, .claude/settings.local., trust records and hooks, with no complete preservation/rollback guarantee — back up first
- Requires Node.js 22/24 and tmux; Node 20 is refused at install, and Apple silicon has a documented Node compatibility limitation
- Upgrade migration risk: crossing the 0.5.9 layout boundary requires the multi-phase openrig-upgrade skill migration scripts
- Requires an existing paid Claude/Codex account with model usage billed separately; the React web UI is in maintenance mode
How does this agent compare with similar options?
The README compares OpenRig with Claude Managed Agents: OpenRig is open source and self-hosted, can mix Claude Code and Codex in the same team, runs on your own infrastructure, and the selected providers' model usage costs still apply. A full comparison is at openrig.dev/compare/claude-managed-agents.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| OpenRig This agent | 79 · Good | CLIFree + model costs | ★ 4.9k | today | TypeScript | Codex · Claude Code |
| NTM (Named Tmux Manager) | 73 · Some gaps | CLIFree + model costs | ★ 452 | 2d ago | Go | Codex · Claude Code |
| Agent Manager | 64 · Some gaps | CLIFree | ★ 561 | today | Go | Codex · Claude Code |
| AgentBridge | 61 · Some gaps | CLIFree + model costs | ★ 370 | 22d ago | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
README discloses machine writes in detail, YOLO is off by default, and permission changes require an explicit user answer; deducted because the daemon enables Codex hooks by default, pre-writes trust hashes at startup, and the docs themselves admit writes are 'not a complete preservation or rollback guarantee'. Data-flow transparency is thorough (activity payloads exclude prompt text), so full marks; sensitive-data handling is mid (transcript paths and usage metadata still land in state files); dependency security gets 1 because only better-sqlite3 is mentioned with no lockfile/audit evidence in scope.
Tests show honest, structured failure messages (conflict, not-found, failed launch all exit non-zero with actionable text), and self-consistency is supported by docs-guard and mirror-skills checks; deducted on dependency availability because external CLIs (claude/codex) and tmux are required and several platforms are explicitly untested.
Environment fit is fully evidenced (Node 22/24, tmux, macOS/Linux, Apple-silicon caveat, Windows/WSL2 untested); capability boundaries likewise have explicit 'not supported/untested' statements; deducted on audience (the framing leans on the author's personal 'AI civilization experiments' narrative) and trigger precision (choosing starters/permission modes rests on docs guidance, not enforced mechanisms).
Information architecture and install notes are excellent (upgrade path, Node 20 exit, 0.5.9 layout boundary); known limitations are candid; full Apache-2.0 LICENSE with copyright justifies full marks on license; deducted on naming stability (legacy YOLO path, rig policy aliases), on versioning/changelog (release notes referenced by link rather than a changelog file in scope), and on maintenance responsibility (single maintainer; response targets are promises, not mechanisms).
Output usability is well evidenced (-- flags, error text, TUI views under test); deducted on marginal value and cost-benefit because the tool is a whole orchestration layer with a large install surface (daemon, hooks, tmux, optional herdr/cmux), and those benefit claims cannot be verified in a static review.
Fact/inference separation is good: docs distinguish implemented behavior from untested/unsupported, and tests cite concrete acceptance IDs; deducted on claim traceability because the daemon core source is not in scope, so safety claims (e.g., 'no prompt text sent') can only be checked against self-description, and cross-source corroboration is limited to partial consistency among README, SECURITY.md, and CI.
- Installation writes global configuration: rig setup and daemon startup modify ~/.claude, ~/.codex, ~/.tmux.conf and similar files, and automatic writes have no per-step preview; back up relevant files before first use.
- Codex hooks are enabled by default with pre-written trust hashes and workspace pre-trust; these are defaults, not per-action prompts — run --dry-run first in least-privilege environments.
- The shared Claude settings set permissions.defaultMode to acceptEdits and enable external MCP services (Exa/Context7); be aware of these external data flows.
- No dependency-audit evidence exists in the reviewed scope; the security posture of better-sqlite3 and other dependencies is not shown, so audit independently before adoption.
- Windows is unsupported, WSL2 untested, and Apple silicon requires Node 22; validate in an isolated environment before production use.