OpenRig organizes existing agents into named seats
OpenRig manages the team formed by several coding-agent sessions. A RigSpec describes pods, seats, links, and continuity rules in YAML. The CLI launches those seats in tmux, while a local daemon and terminal interface show topology, work, messages, health, and requests for human decisions. Claude Code and Codex remain the workers. OpenRig supplies identity, persistence, routing, and recovery around them.
The starter rig uses 2 Codex seats, an owner and a checker, on one repository task. The README tells the owner to create a queue item, implement a bounded change, request review of the exact candidate, and return the result plus a way to try it. That is a sound operating pattern because it keeps implementation and checking distinct. A larger topology only helps after the team can supervise the small one.
The 255 MB install is the smaller setup cost
Our sandbox installed 492 npm packages in 18 seconds and used 255 MB on disk. The monorepo build completed in 57 seconds. OpenRig requires Node.js 20, 22, or 24 and tmux. The first-project path also expects an authenticated Codex CLI. Claude Code and cmux are optional for that starter, although both are central integrations elsewhere in the documentation.
The local footprint goes well beyond npm. Daemon startup creates instance state, seeds skills, and can write Codex hook configuration and trust records before a rig launches. Claude seats may receive workspace trust, status-line commands, activity hooks, selected MCP settings, and managed files. rig setup --dry-run previews its own plan, but the README says it cannot preview every effect caused by later daemon and seat startup. Backups are part of setup here.
What happened when we ran it
We cloned commit 91a04d7 into a 3-CPU, 8 GB sandbox. The checkout held 2,999 files, roughly 570,014 lines of source, and 29 MB before dependencies. Installation succeeded in 18 seconds, adding 492 packages and growing the environment by 255 MB. The build passed in 57 seconds. Our scan found a workspace monorepo, no Dockerfile, no CI workflow files, and no tests directory.
Tests exited with code 1 after 183 seconds. Node's test runner reported 197 passed and 4 failed out of 201. The supplied tail shows successful subtests numbered 192 through 203, covering CLI manifest behavior, digest checks, stub assets, lint preparation, and typecheck preparation. It does not show the names or errors of the 4 failures, so assigning them a cause would be guesswork. The useful conclusion is limited: this commit did not pass its full test command in our environment.
npm audit reported 21 known vulnerabilities: 3 critical, 9 high, 5 moderate, and 4 low. That count does not tell us whether a specific advisory is reachable through OpenRig's local daemon or published CLI. It does rule out describing the dependency tree as clean. Before installing it on a workstation with repository credentials, inspect the audit paths and decide whether each exposed package can wait for an upstream fix.
Setup writes trust and hooks outside the project
OpenRig documents writes under ~/.claude, ~/.codex, the selected workspace, and its own state directory. Managed Codex launches normally use the workspace-write sandbox. Claude launches use accept-edits mode. A separate full-bypass policy can choose far broader access, while the default keeps that mode off. These choices affect what every managed seat may change, so a copied RigSpec should never silently choose them for you.
Activity relays send event type, seat identity, timestamps, and native session identity to the local daemon while excluding prompt text and tool arguments. Context usage and transcript-path metadata may also be stored in instance state. Selected MCP providers have their own flows. The documentation is specific enough to support a real review, which is better than hiding the plumbing, but the operator still has to approve the resulting boundary.
Current status bugs can mislabel working agents
Issue 28 describes OpenRig v0.5.14 marking a live Codex seat attention_required because its tmux pane reports a shell wrapper rather than the descendant Codex process. Issue 29 says Pi activity hooks omit an occupant generation value, leaving those seats in an unknown state. These reports concern the dashboard's picture of work, which is the exact layer OpenRig asks an operator to trust.
Other open reports cover a send command returning success while leaving text as a draft, startup failures on some tmux hosts, and a Codex hook-trust prompt that can block seats. GitHub listed 26 combined open issues and pull requests on September 25, 2026. The queue is active and detailed, but several entries touch delivery, readiness, and identity rather than cosmetic behavior. Watch the actual tmux sessions when piloting a rig.
v0.5.14 is active and still operationally young
The repository had 391 stars and was pushed on September 25, 2026. Release v0.5.14 arrived on September 14 with navigation, notifications, mission progress, and instance-health changes. Its extensive notes also retain limits around intermittent read timeouts, multi-client control sockets, provider coverage, shutdown drains, config preservation, and bundled workflow discovery after some upgrades. That is honest release writing, and it describes software still settling its operating model.
OpenRig makes sense once 2 or more agent sessions have become difficult to identify, revisit, and coordinate. It does not make supervision disappear. The failed test command, 21 audit findings, and live status issues mean the first deployment belongs on a controlled machine with a disposable repository copy. If one agent can do the job, use one agent. Add the rig when the coordination cost is already real.