OpenRig, a project published by GitHub user mvschwarz, describes itself as “a harness that wraps your harnesses.” Define a team of coding agents in YAML, boot it with rig up, and Claude Code and Codex run side by side in tmux sessions that the tool tracks, snapshots, and restores. The pitch is not a better agent. It is a control plane for the pile of terminal sessions that agentic coding has already produced.
That framing is the genuinely new thing here, and it is worth taking seriously. Anthropic and OpenAI both ship single-agent CLIs with their own permission models, their own config files, and no shared notion of a team. OpenRig’s answer is a local daemon plus CLI plus TUI plus MCP server, backed by SQLite and tmux, that treats those two runtimes as interchangeable seats in a topology. The starter rigs make the intent concrete: first-project is a two-seat Codex setup with an owner and a checker; conveyor is a four-seat mix of Claude Code and Codex walking a handoff path through intake, planning, build, and review; product-team scales to two orchestrators, implementation, QA, design, and two independent reviewers.
The install does more than install
The part that deserves scrutiny is the setup surface. OpenRig is not a passive wrapper. On launch it writes provider hooks and workspace trust settings, and the project documents this in unusual detail. Managed Claude Code startup writes workspace trust and onboarding completion into ~/.claude.json. In the workspace, .claude/settings.local.json receives a context collector’s statusLine command and activity hooks, with helper scripts under .openrig/. The shared settings resource sets permissions.defaultMode to acceptEdits and enables Exa and Context7 MCP entries.
On the Codex side, OpenRig writes the daemon’s CODEX_HOME/config.toml, normally ~/.codex/config.toml. Startup enables hooks, adds OpenRig activity relay commands, and pre-writes trust hashes for those commands. Seat startup adds trust_level = "trusted" for the workspace. Managed launches supply HOME, CODEX_HOME, and OPENRIG_* identity variables, run Claude with --permission-mode acceptEdits, and run Codex with -s workspace-write unless a named profile governs the sandbox. Fresh Codex launches also add writable access to the workspace’s .git and the pod’s shared queue-state directory via --add-dir.
Read that list again. A tool that manages coding agents has to modify the trust and permission configuration of those agents to make coordination work. That is not a flaw unique to OpenRig. It is the structural problem of building orchestration on top of CLIs that were designed to be invoked by one human at a time.
What the activity relay actually sends
The project is unusually candid about telemetry, which is the right instinct. Activity relays send event type and subtype, seat and runtime identity, timestamps, and native session identity to the configured daemon’s /api/activity/hooks endpoint. The payload excludes prompt text and tool arguments. Claude’s collector writes context and token usage, session and transcript-path metadata, and available rate-limit data into the instance’s state/context-usage and state/provider-usage directories. Daemon plugin initialization checks the OpenRig plugin release endpoint on GitHub.
Excluding prompt text is the correct default, and stating it plainly is better than most agent tooling manages. But the metadata is still meaningful. Token usage and rate-limit data across a multi-seat rig is a real-time map of how a team spends its inference budget, and it lives in a local SQLite database under OPENRIG_HOME, normally ~/.openrig.
OpenRig is not selling a smarter agent. It is selling the missing layer between a coding agent and a team of them, and it is paying for that layer with configuration changes to the agents themselves.
YOLO is off by default, which matters
The permission story has one genuinely reassuring detail. Full bypass is opt-in: explicit OPENRIG_YOLO=1 or a full-bypass seat policy selects Claude’s --dangerously-skip-permissions or Codex’s -s danger-full-access, and a resolved seat policy takes precedence over the environment variable. The built-in bootstrap does not add rig command allow rules, and the project tells users to ask their agent to apply project or user scope permissions deliberately.
The counterweight is that the writers are not fully reversible. Managed hook blocks target OpenRig’s entries and retain unrelated hooks, but trust entries, selected resource keys, and Claude’s existing status-line command can be replaced. Some writers recover unreadable settings as empty objects. The project says so directly: “this is not a complete preservation or rollback guarantee.” Daemon and bootstrap writes are automatic and do not each have an interactive preview, and rig setup --dry-run does not preview every later startup effect. The advice is to back up relevant files first. That advice is correct and also a warning label.
Why this matters for AI builders
The interesting signal is not OpenRig specifically. It is that the multi-agent coding stack is consolidating around a pattern: a declarative spec, a supervisor process, tmux or an equivalent for process isolation, and MCP as the control channel. OpenRig exposes MCP tools like rig_up, rig_ps, rig_send, and rig_chatroom_send so agents can manage their own topology. It can adopt existing Claude Code and Codex sessions already running in tmux. It can snapshot a topology with rig down --snapshot and restore it by name, which is the closest thing anyone has shipped to durable agent state across a reboot.
The competition here is not another coding agent. It is whatever Anthropic and OpenAI eventually ship as first-party multi-agent management, and whatever the tmux-adjacent crowd builds next. OpenRig’s bet is that the harness layer stays open and vendor-neutral while the models stay proprietary. That bet is reasonable, and it is also fragile in a specific way: every improvement to Claude Code’s or Codex’s own permission and trust handling can break the writers OpenRig depends on.
The project targets acknowledgment of issues and pull requests within one day and asks users to check rig --version, noting that repository guidance can run ahead of the published npm package. For anyone running more than two coding agents at once, that gap between the repo and the release is the thing to watch.