Run Claude Code and Codex as One Managed Team

Two coding agents in two terminal tabs are not a team — they are two strangers who have never seen each other's work. OpenRig wraps your harnesses the way a harness wraps a model: define the team in YAML, boot it with one command, and every agent gets a stable address you can message, inspect, and restore after a reboot.

Why This Skill Matters

OpenRig is a local daemon, CLI, and terminal UI built on tmux and SQLite. A rig is a declarative RigSpec: pods of seats, edges between them, continuity policies. Seats are stable addresses like dev-build@starter — the conversation occupying a seat can change while its identity and authored context remain. Rigs snapshot and restore by name, existing tmux sessions can be adopted instead of relaunched, and teams ship ready-made: starter pairs a Claude Code builder with a Codex reviewer for one bounded change, workshop adds a lead and QA for ongoing work, and factory runs seven agents for sustained product work. It is Apache-2.0, self-hosted, and reads your existing subscriptions — no second one required.

Installation

You need Node.js 22 or 24, tmux, and macOS or Linux — on Windows the supported route is WSL2, and on Apple silicon the README says to use Node 22. The step-by-step path:

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

--providers is where you commit to Claude Code, Codex, or both; the dry run previews everything setup will change first. rig setup installs a missing harness if needed, writes an OpenRig block in ~/.tmux.conf, and installs the herdr terminal workspace by default (decline with --no-herdr). The README's advice before running any of this: read its What OpenRig changes on your machine section and back up the relevant files — setup and launches write trust settings and executable hooks. Check the result with tmux -V plus your provider's claude auth status or codex login status.

Real Workflow: One Bounded Change Through starter

1. From your repository, preview and launch the starter team manually:

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

2. Check readiness before assigning work — rig ps --nodes --rig starter — and resolve any authentication or permission prompt it reports (if a seat stopped at a prompt, rig ps shows the rig seat continue <seat> command that delivers its startup context).
3. Give the builder one bounded outcome:

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.'

4. Sending the message does not itself create a queue item — the builder records the task. Watch it with rig queue list --destination dev-build@starter --limit 1000, then read the final artifact and the review of its exact candidate.

When you are done for the day, rig down --snapshot captures the full state and rig up <name> restores it — per-node outcomes tell you which seats resumed and which need attention.

Tips

• If the manual path feels heavy, ask your agent: after installing, it can open the OpenRig TUI and the kernel operator, which recommends one of three teams fitted to your providers.
• Specialist teams exist beyond the main three: code-review, research, and pm, plus secrets-manager — a HashiCorp Vault instance run by a specialist agent (Docker required).
• Wire agents together with rig send, rig broadcast, or rig chatroom; evolve a running topology with rig grow, rig shrink, and rig remove.
• Permission escalation is explicit: YOLO is off by default, a seat's default lets Claude run ordinary rig commands while lifecycle commands like rig up still ask, and broader access ships only in the separately-documented workshop bundle.
• Already running agents in tmux? rig discover fingerprints them and rig adopt brings them under management without a relaunch.

When Not to Use This

There is no native Windows — WSL2 is the supported route, and the automated tests do not run on WSL2 yet. If your work is a single agent and a single task, a rig is machinery you will spend more time operating than saving. And OpenRig manages the team, not the bill: it is self-hosted, and the selected providers' model usage costs still apply.

See the leaderboard for more skills.