The Rig That Wraps Your Agent Harnesses

Every multi-agent setup eventually collides with the same wall, and it isn’t intelligence. It’s terminals. You start one Claude Code session, then a Codex session because Codex is better at the thing Claude is worse at, then a third session to review what the first two did, and within a week you’re managing a sprawl of tmux panes held together by muscle memory and a notes file. The agents are fine. The system they’ve formed is unmanaged.

This is the problem OpenRig names with unusual precision. Its framing — “a harness wraps a model, a rig wraps your harnesses” — is the whole pitch in one line, and it’s a line that tells you the project isn’t trying to compete with Claude Code or Codex. It’s trying to compete with the mess those tools leave behind when you run them together.

The origin story is refreshingly mundane

The founder, posting as mschwarz on Hacker News, describes the motivation without any pretense: his Claude Code plus Codex setup kept forming little “topologies” of long-lived agents that worked well together, but the terminal sprawl was intense. So he built a primitive the agents could use to save and recreate these setups on demand. Nine months of iteration later, that primitive grew into a daemon, a CLI, a terminal UI, and an MCP server — and, per the project’s studio page, roughly 1,558 tests, 52 domain services, 36 CLI commands, and 17 MCP tools.

That last set of numbers is worth pausing on, because it signals something about the project’s character. OpenRig is not a weekend glue script over tmux. It’s a fairly earnest piece of systems software — a Hono HTTP daemon holding state in SQLite, with tmux as the session substrate and runtime adapters for each agent type. The React web UI is in maintenance mode; the terminal UI is where the project’s attention now lives. This is infrastructure built by someone who ran into the problem personally and then kept going.

The Hacker News thread itself drew six points and eight comments, which is to say: this is not currently a hyped project. It’s an early, single-maintainer effort inviting feedback on where its mental model confuses people. That context matters for calibrating expectations, and it also makes the project more interesting to write about honestly — there’s no adoption wave to explain, only an idea.

The core idea: topology as the unit of persistence

The genuinely novel move in OpenRig is what it chooses to persist. Most agent tooling treats the session as the atomic thing — you resume a conversation, or you don’t. OpenRig treats the topology as the atomic thing. You define a rig in YAML: pods of related agents, edges between them, continuity policies, and a culture file that sets coordination norms (research rigs get exploratory culture; implementation rigs get conservative, trust-but-verify culture). You boot the whole thing at once, and when you’re done — or when the machine reboots — you snapshot the entire topology by name and restore it later, with per-node outcomes reported as resumed, fresh, or failed.

Two supporting concepts do a lot of quiet work here. The first is the seat: a stable role and address, like a dev-owner on a named rig, whose occupying conversation can change while the identity and accumulated context stay put. This is the difference between “I have a terminal running Claude” and “I have an owner for this work who happens to be Claude right now.” The second is discovery and adoption: OpenRig fingerprints existing tmux sessions by inspecting running processes and can bring unmanaged Claude Code or Codex sessions under management without interrupting them. That’s a small mercy for anyone with an existing sprawl — you don’t have to rebuild your mess inside the tool before the tool can help.

The boring part is where the value lives, as it often is. Agent-to-agent messaging runs through tmux; tasks and handoffs run through a custom event stream and queue system. The founder is explicit in the Hacker News thread that this is deliberately simpler than something like the A2A protocol — “intentionally stripped down to keep things inspectable by a single human operator trying to manage a fleet of agents.” Whether that simplicity ages well as fleets grow is an open question, but as a design constraint it’s coherent: one human, one screen, a hundred agents.

The cross-harness bet

The most contrarian thing about OpenRig is what it refuses to standardize on. The industry’s default answer to scaling agents is subagents — spawn focused workers inside one harness, summarize results back to the main context. Anthropic’s own agent teams documentation follows this shape: one lead Claude session coordinating teammates that are all, ultimately, Claude sessions, behind an experimental feature flag with known limitations around resumption and shutdown.

OpenRig’s founder argues the opposite in a blog post linked from the project site: Claude and Codex are two halves of one brain, good at different things, and scaling across harnesses matters more than scaling within one. So a rig mixes runtimes natively — Claude Code seats, Codex seats, terminal nodes, and a Pi adapter — with starter topologies like a four-seat conveyor that deliberately pairs the two. The shipped defaults reflect the bet: Codex seats run workspace-write sandboxes, Claude seats run acceptEdits, and the infamous full-bypass modes are off unless explicitly chosen.

There’s a related claim the founder makes that deserves a raised eyebrow, kindly. He describes “context domains” — distributing a task across agents so that a ten-agent rig with million-token windows each can be “viewed or operated as if it had a 10 million token context window.” That’s true only in a loose sense: it’s ten coordinated windows with a communication protocol between them, not one window, and the coordination overhead is exactly what Claude’s own documentation warns about (“agent teams add coordination overhead and use significantly more tokens than a single session”). The claim is directionally interesting for brownfield work on large codebases, where the founder says he uses it, but it’s a framing, not a benchmark.

The field it lands in

The timing is good, even if the traction isn’t there yet. VS Code’s February 2026 release now runs Claude and Codex agents alongside GitHub Copilot, with an Agent Sessions view for managing them — an acknowledgment from the largest editor on earth that multi-agent, multi-harness work is now normal. Google’s own multi-agent codelabs teach orchestrator-and-specialist patterns with the A2A protocol as the connective tissue. The problem space is real and crowded.

What distinguishes OpenRig from the VS Code approach is where it sits. VS Code’s answer is an editor feature: sessions visible in a side panel, delegated from your writing environment. OpenRig’s answer is an operating layer: a daemon that owns lifecycle, persistence, and messaging for agents that live in terminals, on a host you control, self-hosted and Apache 2.0. It’s closer in spirit to running a small fleet on a Mac mini than to clicking through a panel — and the project site leans into this with a notebook-style post describing 109 seats defined, 41 running, 13 active, agents left on to accumulate context so work can later be routed to whoever already knows that part of the project. Whether that’s a workflow or a hobby is a fair question, but it’s clearly a lived one.

The honesty section, which is honestly a lot

OpenRig’s README contains something rare: a table titled “What OpenRig changes on your machine,” and it’s long. The daemon writes trust settings and executable hooks into Claude and Codex configuration files, seeds skills directories, pre-trusts workspaces, and relays activity events to its own API endpoint. The project is upfront that some writers recover unreadable settings as empty objects, that this “is not a complete preservation or rollback guarantee,” and that you should back up relevant files before first use. For a tool whose entire value proposition is managing agent state, being this explicit about the state it mutates is the right instinct — and also a genuine caution. You are granting a fleet-coordination daemon write access to the configuration of your other agents.

The security posture is similarly candid and similarly limited. Asked on Hacker News about isolation, the founder’s answer is direct: OpenRig doesn’t solve it, and currently assumes you want all agents sharing the same network and filesystem so they can work together without friction. That’s a defensible single-operator stance and a real constraint the moment you don’t trust every seat equally. No A2A support yet, though the founder acknowledges heavy overlap and calls it a possible roadmap item.

Then there’s the migration section. The README’s walkthrough of crossing the 0.5.9 layout boundary — a multi-phase, preimage-taking, receipt-verifying, agent-operated telemetry migration with explicit rollback semantics — reads like a small distributed-systems paper embedded in a getting-started guide. It’s rigorous to the point of intimidating, and it tells you two things at once: the author has been burned by state migrations before, and the project’s complexity budget is being spent in places a newcomer won’t expect.

Outlook

The near-term trajectory is visible in the sources: Pi and OpenHands adapters in development, a starter library that already includes an adversarial-review topology and a Vault instance managed by a specialist agent (the “agent-managed software” idea — packaging the software alongside the agents who run it — is quietly one of the more original bits), and a public open specification. The unresolved tensions are equally visible: single-maintainer bus factor, a small community, an isolation story that will need an answer before rigs can be shared or run on untrusted code, and a migration ergonomics problem that will bite exactly the agent-heavy developers it courts.

But the core insight holds regardless of whether OpenRig itself wins: once you run more than a couple of coding agents, the agents stop being the hard part and the system they form becomes the product. Someone was going to build the control plane for that. OpenRig is an early, opinionated, unusually honest attempt — built on tmux, of all things, which turns out to be exactly the right amount of boring.