TL;DR

OpenRig (mvschwarz/openrig) is an open-source “multi-agent harness”: a local daemon, CLI, terminal UI and MCP server that runs several Claude Code, Codex and Pi sessions as one team. The README puts it in two sentences: “A harness wraps a model. A rig wraps your harnesses.” You describe the team in a YAML file (a RigSpec), start it with rig up, and every agent lives in its own tmux session with a stable address such as dev-build@starter. Agents message each other with rig send, record work in a shared queue, and the whole team can be snapshotted with rig down --snapshot and brought back after a reboot.

Facts as of October 8, 2026:

  • 5,960 GitHub stars, 437 forks, Apache-2.0, written in TypeScript. The repo was created on April 1, 2026.
  • Latest release: v0.6.6 (October 7, 2026). The npm package @openrig/cli has 56 published versions and was downloaded 4,821 times in the week of September 28 to October 4.
  • 93 open issues. Almost all commits come from one author (1,840 by mvschwarz; the next contributor has 152).
  • Requirements: Node.js 22 or 24, tmux, macOS or Linux. WSL2 is the Windows route; native Windows is not supported.
  • Bring your own agents. OpenRig doesn’t call any model itself. You need a working Claude Code or Codex login (one is enough).

Our verdict: the install is clean and quick. In our lab it went from an empty container to a running daemon with its full spec library in 16 seconds. If you already have a Claude Code builder and a Codex reviewer in two terminal tabs, OpenRig is the most complete open-source way to turn that habit into something you can name, restart and grow. It is also young software from one main author: it writes trust settings and hooks into your Claude and Codex configs, and its issue tracker shows real trouble at large seat counts.

What problem OpenRig solves

Anyone who runs coding agents seriously ends up with one tab of Claude Code building, another of Codex reviewing, and themselves copying text between them. Reboot and the arrangement is gone. OpenRig’s README describes the goal as turning “AI coding agents from a pile of terminal sessions into a persistent, organized team.” It doesn’t make each agent smarter; it manages which sessions run, how they relate, how they talk and how to recover them.

The author explained the pairing that started it in the April Show HN thread: “Claude is better at understanding your intent, but at the expense of it makes lots of mistakes. Codex makes less mistakes but at the expense of over-engineering. Together they are not perfect but significantly more accurate.” That is exactly what the default starter team is: a Claude Code builder whose work is checked by a Codex reviewer.

How it works

OpenRig is four pieces on top of tmux, per the README:

  • A daemon (a Hono HTTP server, SQLite for state) on 127.0.0.1:7433.
  • A CLI (rig) used by both you and the agents.
  • A TUI (rig tui) that shows the team as a graph or as a table of seats with runtime, model, context use and state.
  • An MCP server, so agents can manage their own topology with tools such as rig_up, rig_ps, rig_send and rig_chatroom_send.

The vocabulary takes ten minutes to learn:

ConceptWhat it means
RigA running team, started from a RigSpec
RigSpecYAML that defines pods, members, edges and continuity policies
PodA group of related seats sharing guidance and context
SeatA stable role and address (dev-build@starter); the conversation inside it can be replaced
AgentSpecA reusable agent blueprint: skills, guidance, hooks, startup files
CultureA rig’s CULTURE.md, coordination norms every seat receives
RigBundleA portable archive of a rig with vendored AgentSpecs and SHA-256 integrity

Agent-to-agent messaging goes through tmux itself: OpenRig types the message into the receiving seat’s pane, so you can attach to any seat and see exactly what it received. Tasks and handoffs use a separate event stream and queue (rig queue list).

A RigSpec, from the shipped starter team

This is the built-in starter rig from the repository:

version: "0.2"
name: starter
culture_file: CULTURE.md

pods:
  - id: dev
    label: Project
    members:
      - id: build
        agent_ref: "local:../../../agents/development/implementer"
        runtime: claude-code
        profile: default
        cwd: "."
      - id: review
        agent_ref: "local:../../../agents/development/qa"
        runtime: codex
        model: gpt-6-astra
        profile: default
        cwd: "."
    edges:
      - kind: delegates_to
        from: build
        to: review

edges: []

The RigSpec reference adds startup files, Docker Compose services with health checks, checkpoint commands and per-seat permission policies.

The built-in teams

Version 0.6.6 ships starter (builder + reviewer), factory (seven seats: lead, advisor, build, QA, design, two reviewers), the specialist teams code-review, research and pm, and secrets-manager (a Vault instance run by an agent; needs Docker). The four-seat workshop installs from openrig.dev. By default OpenRig also starts a kernel rig whose “operator” agent asks what you want to build and launches a team for you.

Quick start

From the README, the step-by-step route:

npm install -g @openrig/cli
rig setup --dry-run      # preview what setup would change
rig setup                # installs missing tools; checks Claude/Codex
rig daemon start         # also starts the kernel (operator + advisor)
rig terminal open saved:kernel --window

There is also a one-line install script pinned to the release tag (.../v0.6.6/scripts/install.sh), with a --dry-run mode that only prints the plan.

To skip the operator and launch the starter yourself:

cd /path/to/your/repository
rig specs preview starter --kind rig
rig up starter --cwd . --plan
rig up starter --cwd .
rig ps --nodes --rig starter

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

Other everyday commands: rig down --snapshot / rig up <name> (save and restore), rig grow / rig shrink, and rig discover / rig adopt to bring existing Claude or Codex tmux sessions under management.

Hands-on test (October 8, 2026)

Running the agents needs a signed-in Claude Code or Codex account, and our lab has none: it is a CPU-only GitHub-hosted runner with no API keys or subscriptions. So we tested everything up to the first model call: install, version, health checks, the setup plan, starting the daemon, and reading the spec library. We ran six steps in a fresh node:22-bookworm container (x86_64, 2 CPUs, 8 GB RAM, no GPU) against commit 114cdb1554bd. All six passed, in 16.2 seconds in total.

StepResultTime
Install tmux (apt-get install tmux)tmux 3.3a2.4 s
npm install -g @openrig/cli”added 114 packages in 8s”8.4 s
rig --version0.6.6 (2620dea8), the v0.6.6 release build0.5 s
rig doctorEvery check OK except one WARN (cmux not found) and one SKIP0.5 s
rig setup --dry-runPrinted the files it would change; made no changes0.5 s
rig daemon start --no-kernel, rig specs ls, rig specs preview starter”Daemon started on port 7433”; library listed; starter previewed3.9 s

What worked. The install pulled 114 npm packages and needed nothing beyond tmux. rig doctor confirmed the daemon and UI builds, Node v22.23.3, tmux, writable state paths and a free port 7433; its only warning was the optional cmux. Its closing lines are honest about their scope: “This is not an end-to-end readiness verdict: provider login and agent task-readiness are not established.”

The daemon’s first output line was a harmless tmux error (error connecting to /tmp/tmux-0/default, no tmux server yet); the next confirmed the start. rig specs ls then listed the whole built-in library: 16 agent specs, 7 rig specs and 6 workflow specs (among them basic-loop, gated-release, linear-build and branched-remediation). rig specs preview starter showed one pod, dev, with two members: build — claude-code and review — codex.

The most useful output was the setup dry run. Before changing anything it lists the files OpenRig may modify: ~/.claude.json (“Pre-trust managed workspaces and mark Claude onboarding complete”), the project’s .claude/settings.local.json and .mcp.json, and ~/.codex/config.toml. It notes that it “bakes NO allow/ask/deny permission policy”. On Linux it skipped Homebrew and cmux and would have tried to install and sign in to Claude Code and Codex.

What this does not tell you. We never launched a seat, so we can’t judge how well a Claude builder and Codex reviewer work together, rig send delivery, or snapshot and restore. Those are exactly where the open issues below sit.

Community reactions

Its two Show HN posts (April, May) drew single-digit points; the star growth came later, from GitHub Trending. The threads are still useful:

  • Long runs. The author said his longest continuously running rig lasted “about 4 days”: a large spec carried out test-first, with independent code reviews at milestones and automated browser testing.
  • The skeptic’s view. One commenter maintaining open-source projects said agents did “%80~ of the work,” but reviewing each PR and steering fixes “takes about as much time as without the swarm”. In his experience the swarm mostly helps with initial scouting. That is a fair warning for any multi-agent setup.
  • Isolation. Asked about isolation, the author was direct: every agent shares the same network and filesystem, and that is deliberate. OpenRig “assumes you the operator are running coding agents on a host you control.” It doesn’t speak A2A; messaging is tmux plus its own queue.
  • “Context domains.” The author argues a 10-agent rig with 1M-token windows each can be operated “as if it had a 10 million token context window.” Treat that as a working model, not a measurement: agents still pass context through messages.

Honest limitations

  1. It writes to your agent configs. Startup pre-trusts workspaces in ~/.claude.json and ~/.codex/config.toml, adds hooks and a statusLine to .claude/settings.local.json, and writes Codex hook trust hashes, in some cases before you launch any rig. The README admits that “this is not a complete preservation or rollback guarantee” and asks you to back up those files first. Do that.
  2. Scale problems are open. Issue #161 reports that per-seat tmux polling spawns about 300 processes per second and that around 90 seats saturate the daemon’s event loop: health checks time out and zombie processes pile up. A request for a max_concurrent_seats cap (#711) is also open. A handful of seats is fine; dozens is not yet.
  3. Delivery through tmux is fragile at the edges. Issue #197 describes v0.6.2 refusing every rig send to Claude seats launched with an explicit permission mode, because the pane showed OpenRig’s own /bin/sh wrapper. Another issue covers a restored Claude seat wrongly reported as “returned to shell”. When messaging means typing into terminals, those cases matter.
  4. Fast release churn. Three releases in six days (v0.6.4 to v0.6.6, October 2–7). v0.6.6 renamed built-in teams with no alias for some (adversarial-review became code-review). Read release notes and restart the daemon after each upgrade.
  5. Bus factor. About 90% of commits come from one person.
  6. No isolation. All seats share your user, network and filesystem. Pair it with a sandbox (see NVIDIA OpenShell) or a dedicated VM.

When to use OpenRig, and what to pick instead

Use OpenRig if you already pay for Claude Code or Codex (ideally both), you run more than one agent at a time on a machine you control, and you want named roles, review gates and restart-after-reboot without building it yourself.

Look elsewhere if:

  • You want governance (budgets, approvals, org charts) more than terminals. Paperclip models a company: tickets, budgets with hard stops, approval stages, a web UI. OpenRig is closer to the metal: tmux, YAML, CLI.
  • You only want to see many agent terminals at once. Herdr is a multiplexer for agent sessions. OpenRig can use it as its terminal view, but Herdr alone adds no roles, queue or restore.
  • You live inside Claude Code only. oh-my-claudecode runs multi-agent workflows inside one Claude Code install without a separate daemon.

FAQ

Is OpenRig free?

Yes. OpenRig is Apache-2.0 and free. You still pay for the agents it runs: a Claude Code subscription or API usage, and/or Codex through a ChatGPT plan or API. The README says you can reuse the accounts you already have, and one provider is enough.

Does OpenRig work with only Claude Code, or only Codex?

Yes. The starter team ships with one of each, but the kernel’s operator can write a copy adapted to the providers you have. OpenRig also supports Pi and Oh My Pi through RPC runners, plus plain terminal nodes.

Does OpenRig run on Windows?

Not natively. WSL2 is the supported Windows route, though OpenRig’s automated tests don’t run on it yet. The getting-started guide documents one user’s working WSL2 setup on Ubuntu 24.04 with Node 24 and tmux 3.4.

What happens to my agents after a reboot?

rig down --snapshot saves the topology, and rig up <name> restores it. Restore reports a result per seat: resumed, fresh-primed, awaiting-decision (the original conversation can’t resume, so you choose --fresh), attention_required, or failed. We didn’t test restore in our lab, because it needs signed-in agents.

How is OpenRig different from a framework like LangGraph or CrewAI?

Frameworks build agents in code and call model APIs. OpenRig runs existing CLI agents (Claude Code, Codex) as they are, each in a tmux session you can attach to. Its unit is a terminal session, not a function call.

Verdict

OpenRig is the most serious open-source attempt so far at the layer between “one coding agent” and “an agent platform”. It treats a team of terminal agents as something with addresses, a spec, a queue and a restart button. The parts we could check (install, health checks, the daemon, the spec library and the up-front list of config changes) are polished and honest about what they don’t prove. The parts we couldn’t check are where the open issues are: delivery through tmux, restore edge cases, and scale past a few dozen seats. Start with starter in a repo you care about, back up ~/.claude.json and ~/.codex/config.toml first, and keep the rig small.

Sources