OpenRig
Esoteric Labs · OpenRig: Open-Source Harness for Running Claude Code and Codex as a Persistent Agent Team
OpenRig is a free, open-source (Apache 2.0) multi-agent harness that runs Claude Code, Codex, and Pi sessions as a persistent team defined in YAML. A lead agent delegates to named specialists, work is tracked in an owned task queue, and a terminal UI shows the whole team. It suits developers who already run several coding agents and want them to coordinate on long-running projects on their own machine.
Best for
Developers who already run several Claude Code or Codex sessions on one project and want them organized into a persistent, addressable team they can attach to and steer from the terminal
Not ideal for
Windows users, developers who have not yet outgrown a single agent with subagents, teams that need budgets, approval gates, and a web dashboard, and anyone who does not want a tool writing hooks and trust settings into their Claude Code and Codex configuration
Who it's for
Individual developers and small teams who run multiple Claude Code and Codex sessions and want them to work as a coordinated, long-lived team
Capabilities
- RigSpec YAML defines a team as pods, seats, edges, and continuity policies, and `rig up` boots the whole topology in tmux with readiness checks
- Seats are stable addresses such as `dev-owner@first-project`, so a role keeps its name, guidance, and context when the session occupying it changes
- Direct agent-to-agent messaging with `rig send`, `rig broadcast`, and `rig chatroom`, plus `rig capture` to read another seat's screen
- `rig queue` tracks each piece of work with one owner and a state, and handing work to another seat closes one item and opens the next in one step
- Declared workflows that move work between seats step by step without the user relaying messages
- Claude Code and Codex in the same rig, plus a Pi adapter and generic terminal nodes
- `rig down --snapshot` saves a topology and `rig up <name>` restores it, reporting each seat as resumed, rebuilt, started fresh, needing attention, or failed
- `rig discover` and `rig adopt` bring Claude Code and Codex sessions already running in tmux under management
- Terminal UI with topology graph and table views, seat details, projects, a feed, and system health, and herdr or cmux integration to tile a rig's terminals
- MCP server that lets agents manage their own topology with tools such as `rig_up`, `rig_ps`, and `rig_send`
- Starter rigs from the two-seat `first-project` to the seven-seat `product-team`, plus `conveyor`, `adversarial-review`, `research-team`, and a Vault-backed `secrets-manager`
- Change a running rig with `rig grow`, `rig shrink`, `rig launch`, and `rig remove`, and share topologies as RigBundles with SHA-256 integrity checks
- Per-seat permission modes with an audited selection, an opt-in typing guard for seats you type into by hand, and experimental Slack app setup (v0.6.0)
Limitations
- Runs on macOS and Linux only. Native Windows is not supported and WSL2 has not been tested. Requires Node.js 22 or 24 (Node 22 on Apple silicon) and tmux
- Daemon startup and rig launches change provider configuration automatically, without a preview of each write: OpenRig writes workspace trust to `~/.claude.json`, adds hooks and a status-line command to the workspace's `.claude/settings.local.json`, launches Claude seats in `acceptEdits` permission mode, and enables hooks and adds trust entries in `~/.codex/config.toml`. Existing trust entries and a Claude status-line command can be replaced. The README says to back up these files first and that this is not a complete preservation or rollback guarantee
- It supplies no model. Every seat uses your Claude Code or Codex login, and the automatically started kernel also runs on one of your authenticated providers, so usage grows with the number of seats you run against those plans
- Messages are delivered by typing into tmux sessions. OpenRig's docs say delivery and action are separate events and that queued work can still need someone to notice it
- Self-hosted only. OpenRig describes itself as not a cloud service, and no managed version is offered
- A young, fast-moving project: pre-1.0, four releases between September 28 and 30, 2026, some upgrades have required agent-run migrations, and nearly all commits come from one maintainer
- The Slack integration and stream classification added in v0.6.0 are experimental and off by default
Use cases
- Pairing a Claude Code owner with a Codex checker so each change is reviewed by a different model before you see it
- Running a seven-seat product team of orchestrators, an implementer, QA, a designer, and reviewers on a multi-week feature
- Keeping long-lived specialist agents for different parts of a codebase and letting them answer each other's questions directly
- Restoring a whole team of agents by name after a reboot instead of resuming sessions one by one
- Bringing Claude Code and Codex sessions already running in tmux into one managed, addressable team
Our take
OpenRig takes seriously a problem most multi-agent coding setups leave to the user: once you have more than two or three agents, you become the router between them. Stable seat addresses, direct messaging, an owned task queue, and snapshot and restore let the agents do that bookkeeping themselves, and the mixed starter sets up cross-model review between Claude Code and Codex out of the box. The costs are also clear. It changes your agent configuration, it depends on tmux and a Unix machine, every seat draws on your plans, and it is a young, fast-moving project that mostly depends on one maintainer. Try the two-seat starter on a real repository before committing to a larger rig, and read its list of machine changes first.
Who should use it
Developers and small teams who already juggle several Claude Code or Codex terminals, want cross-model review built into their workflow, and are comfortable with tmux, the command line, and a tool that manages agent configuration for them.
Who should skip it
Windows users, people still getting value from a single agent, teams that need budget limits and approval gates rather than live pairing, and organizations that cannot accept a single-maintainer tool changing agent trust and permission settings.
Strengths
- Free and open source under Apache 2.0, with no API keys or subscriptions of its own
- Mixes Claude Code and Codex in one team, so different models can check each other's work
- Every agent is a real tmux session you can attach to and type into
- Teams survive reboots through snapshots and restore by name
- Documents in detail what it changes on your machine
Weaknesses
- macOS and Linux only, with Node.js and tmux requirements
- Writes hooks, trust settings, and permission modes into your agent configuration
- Running many seats multiplies usage against your Claude and Codex plans
- Young, fast-changing project maintained mostly by one person
OpenRig pricing
Open source
Free
- Apache 2.0 license
- CLI, daemon, terminal UI, and MCP server
- Starter rig library
- Community support through GitHub Discussions and issues
Note: OpenRig has no paid plan and needs no API keys of its own. Model usage is billed through the Claude Code and Codex subscriptions or logins each seat uses, so running more seats uses more of those plans.
Technical specs
Available models
Where OpenRig excels
Getting every change reviewed by a second model
The `first-project-mixed` starter gives a Claude Code owner a Codex checker. The owner implements one bounded change, records it in the queue, and asks the checker to review the exact candidate before reporting back.
Keeping a large project moving over weeks
Specialist seats keep their roles and context, the queue keeps an owner on every task, and snapshot and restore bring the team back by name after a reboot, so work does not depend on one agent's context window or on you remembering which terminal did what.
Consolidating a sprawl of agent terminals
`rig discover` finds Claude Code and Codex sessions already running in tmux, and `rig adopt` brings them into a managed rig you can see in one terminal UI and address by name.
OpenRig vs. competitors
OpenRig vs. Paperclip
Paperclip organizes agents you already use as a company, with an org chart, tickets, per-agent budgets, heartbeats, and approvals, operated from a web dashboard. OpenRig organizes Claude Code and Codex as persistent tmux sessions that message each other directly and are operated from a CLI and terminal UI. Paperclip suits governed, budgeted autonomy, and OpenRig suits developers who want to pair with a live team of agents.
OpenRig vs. Orca
Orca is a desktop agent development environment for running many CLI coding agents side by side, each in its own git worktree with a terminal, browser, and diff review. OpenRig focuses on how agents work together: named seats, direct messaging, an owned task queue, and a lead agent that delegates. Orca suits parallel independent tasks, and OpenRig suits long-running coordinated work.
Frequently asked questions
What is OpenRig?
OpenRig is an open-source multi-agent harness that runs Claude Code and Codex sessions, and Pi through an adapter, as a persistent team. You define the team in YAML, boot it with `rig up`, and talk mainly to a lead agent that delegates to specialists, tracks work in a queue, and brings back results. It runs locally as a daemon, CLI, terminal UI, and MCP server on top of tmux.
Is OpenRig free?
Yes. OpenRig is Apache 2.0 licensed and self-hosted, and no paid plan is listed. It uses your existing Claude Code and Codex logins, so you still pay for model usage through those accounts. The default Codex starter uses gpt-6-astra, and Claude seats use your configured default model.
Which coding agents does OpenRig support?
Claude Code and Codex run natively, and a rig can mix both. Pi is supported through an adapter that runs an RPC runner inside a terminal pane, and generic terminal nodes can run other processes. You only need the provider you plan to use; the others do not have to be installed.
Does OpenRig work on Windows?
Not yet. OpenRig supports macOS and Linux. Native Windows is not supported and WSL2 has not been tested. It needs Node.js 22 or 24 (Node 22 on Apple silicon) and tmux.
How is OpenRig different from Claude Code subagents or agent teams?
Subagents and agent teams are Claude Code features, run from a Claude Code session and limited to Claude. OpenRig runs separate, named Claude Code and Codex sessions that message each other directly, stay alive in tmux while the machine is on, and can be restored by name after a reboot. OpenRig's docs say to keep using subagents, since each seat can still use its own.
What does OpenRig change on my machine?
Besides its own state in `~/.openrig`, `rig setup` writes an OpenRig block to `~/.tmux.conf`. The daemon seeds an `openrig-skills` skill in `~/.claude/skills` and `~/.agents/skills` and, by default, enables hooks and pre-writes trust entries in `~/.codex/config.toml` even before a rig launches. Managed Claude launches write workspace trust and onboarding completion to `~/.claude.json`, add a status-line command and activity hooks to the workspace's `.claude/settings.local.json`, and run with the `acceptEdits` permission mode, while Codex seats get a trusted-workspace entry. YOLO mode is off by default. The README lists these changes in detail and recommends backing up the files before first use.
OpenRig vs Paperclip: what is the difference?
Paperclip runs agents as a company, with an org chart, tickets, budgets, heartbeats, approvals, and a web dashboard. OpenRig runs agents as a topology of always-on tmux sessions that message each other directly, and you attach to any of them from the terminal. Paperclip leans toward governance and cost control, and OpenRig toward working live alongside the agents.
Integrations & fit
Alternatives to consider
Paperclip Labs, Inc.
Technical founders, builders, and small teams already running several coding or general-purpose agents who want budgets, approvals, and an audit trail around them
Free
Stably AI
Developers who already use one or more CLI coding agents and want to run and review many of them in parallel without branch conflicts
FreeAbout OpenRig
OpenRig does not replace Claude Code or Codex. It launches and coordinates them. You describe a team in a RigSpec YAML file as pods of seats, where each seat is a stable role and address such as `dev-owner@first-project`, and `rig up` starts every seat as an ordinary Claude Code or Codex session in tmux. Sessions can end and be replaced while the seat keeps its name, guidance, and context. Agents talk to each other directly: `rig send` types a message into another seat's session, `rig capture` reads its screen, and `rig queue` records work with a single owner so handoffs do not get lost between terminals. Declared workflows can move work from one seat to the next without you relaying messages. The smallest starter, `first-project`, is a two-seat owner and checker team (two Codex agents, two Claude agents, or a Claude owner with a Codex checker), and `product-team` boots seven seats with two orchestrators, an implementer, QA, a designer, and two reviewers. `rig down --snapshot` saves the topology and `rig up <name>` restores it after a reboot, reporting which seats resumed, were rebuilt, or started fresh. Existing tmux sessions can be discovered and adopted, and an MCP server lets agents inspect and change their own topology. Everything runs locally as a daemon with a SQLite database, a CLI, and a TUI. OpenRig needs no API keys of its own and uses the Claude Code and Codex logins you already have, so the cost is your model usage. The tradeoffs are setup and trust. It runs only on macOS and Linux with Node.js 22 or 24 and tmux. Daemon startup and rig launches write hooks and workspace trust settings into your Claude Code and Codex configuration, which the README recommends backing up first. The project is young and moves fast, with four releases in three days at the end of September 2026, and nearly all of its commits come from one maintainer.
Updates from OpenRig
The first-use path now offers the same owner and checker team as two Codex agents (`first-project`), two Claude Code agents (`first-project-claude`), or a Claude owner with a Codex checker (`first-project-mixed`), so a second provider login is not required. The release also clarified permission guidance and fixed bundle installation and agent message delivery. v0.6.3 followed the same day with a fix for messaging managed Claude seats.
v0.6.0 added per-seat permission choices for future launches, an opt-in typing guard for seats you type into by hand, a single TUI action to open a whole rig in Herdr, and experimental Slack app manifest support. It dropped Node.js 20 support.
Are you the founder? Claim this listing →