OpenRig

A harness wraps a model. A rig wraps your harnesses. Define your agent team in YAML, boot it with one command. Claude Code and Codex in the same rig, managed as one system.

OpenRig is open-source software for building and running your own network of agents. It turns AI coding agents from a pile of terminal sessions into a persistent, organized team. Talk to a lead agent about the outcome you want; it can coordinate specialists across teams and bring you results and decisions that need your attention. Start with a repository and one useful change, then keep the team's work and context at the same addresses.

It's the open-source system behind my AI civilization experiments.

Guide: Getting started · Stuck? Help · Questions: Q&A · Updates and demos: @_feralmachine on X

See it running

Start here: the guided first-use path: install, launch a two-agent team in your repository, and get one reviewed change.

Not setting this up today? Get the next walkthrough and occasional OpenRig updates → https://openrig.dev/follow

Install and first run

Requires Node.js 22 or 24 and tmux, on macOS or Linux. On a Mac with Apple silicon, use Node.js 22 (compatibility history). Native Windows is not supported yet, and WSL2 has not been tested. Launching a rig writes provider hooks and workspace trust settings. Before running the commands below, read what OpenRig changes on your machine and back up the relevant files.

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

To install with Bun instead, run bun add -g @openrig/cli. OpenRig still runs on Node.js, so install Node.js 22 as well. Bun may block this package's postinstall script, in which case the Node.js and SQLite check described under what OpenRig changes on your machine does not run at install time.

Choose the working account you already have: Claude Code, Codex, or both. Reuse an explicit choice; no second subscription is required. rig setup --dry-run previews the broader setup, but applying rig setup checks both harnesses and installs a missing one, and on macOS cmux too. It is optional for the selected-provider path.

Before launching, your agent asks once: “Allow your agents to run OpenRig commands without repeated permission prompts?” Yes — recommended / No — keep prompts. This covers every rig command, including starting/stopping agents and configuration, at personal project scope unless you explicitly choose user-wide sessions. It is not global YOLO or permission to invent work. On Yes, the agent adds and verifies native rules; No or no answer leaves settings unchanged. An existing explicit choice is reused. Say “Undo the OpenRig command allowances added by this setup” to remove only its additions.

Check tmux -V and only your selected CLI/login: claude --version plus claude auth status, or codex --version plus codex login status. If needed, sign in once with claude auth login or codex login; do not install or log in to an unused provider.

| Team | Starter | Models | | --- | --- | --- | | Two Codex agents | first-project | Both gpt-6-astra (unchanged) | | Two Claude agents | first-project-claude | Configured native Claude default | | Claude owner + Codex checker | first-project-mixed | Claude default + gpt-6-astra |

All three use the same owner/checker roles and task. Show the selected runtime, configured model and command before launch; confirm the account supports the model instead of silently falling back. The kernel starts automatically and selects from available authenticated providers independently of these two project agents. A missing unused provider is not a setup requirement.

cd /path/to/your/repository
starter=first-project  # or first-project-claude or first-project-mixed
rig specs preview "$starter" --kind rig
rig up "$starter" --cwd . --plan
rig up "$starter" --cwd .

After installation, your agent should open a new kernel conversation space: herdr first, then cmux, then a plain terminal. It tells you before opening it and keeps its own terminal and your existing spaces intact. The guide also gives the manual and SSH commands.

The kernel provides separate operational support and the shared dashboard. To detach without stopping the dashboard, press Ctrl-b then d; rig tui --shared returns to that view. Plain rig tui opens an independent view. Closing a viewing terminal does not mean you should relaunch the team.

Check project-seat readiness with rig ps --nodes --rig "$starter" and resolve any authentication, trust or permission prompt before assigning work. If a seat stopped at such a prompt before its startup context arrived, rig ps shows the rig seat continue <seat> command that delivers it once the prompt is answered. Then give the owner one bounded outcome from your repository:

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

Sending a message does not itself create a queue item; the owner records the task. Read the final artifact and the review of its exact candidate, then return to the same owner for the next change. The guided first-use path covers readiness, a useful task, a reviewed result, Herdr/cmux terminals and recovery.

Not setting this up today? Get the next walkthrough and occasional OpenRig updates → https://openrig.dev/follow

Community

• Questions: Discussions › Q&A
• Bugs and feature requests: open an issue
• Contributing: CONTRIBUTING.md · Code of Conduct · Security policy · Getting help
• Videos: youtube.com/@openrig
• Releases: GitHub Releases and npm @openrig/cli

We aim to acknowledge issues and pull requests within one day; see CONTRIBUTING.md for review targets.

What OpenRig changes on your machine

OpenRig writes instance state, provider integration and workspace files as part of setup and operation. These include trust settings and executable hooks. The summary below follows this source revision; check rig --version when using a published package, since repository guidance can be ahead of npm.

| When | What changes and why | | --- | --- | | npm installation | Installs the CLI (rig and openrig-tui), bundled components and dependencies under your npm prefix (with Bun, under Bun's global directory). OpenRig's postinstall checks the Node.js version and that the SQLite module loads; Bun may block this script. It does not run daemon or provider setup. | | rig setup | Attempts missing tools and writes an OpenRig block in ~/.tmux.conf for mouse support and scrollback. On macOS it can install cmux and enable its automation socket control in ~/.config/cmux/settings.json; cmux defaults automation.socketControlMode to cmuxOnly, which only accepts processes started inside cmux and so blocks OpenRig's control, so setup switches it to automation. --full adds workstation tools. --dry-run shows setup's plan without applying it. | | Daemon startup | Creates/updates instance state under OPENRIG_HOME (normally ~/.openrig), including its database and managed plugin resources. Seeds the openrig-skills discovery skill in ~/.claude/skills and ~/.agents/skills, subject to existing version ownership. With runtime.codex.hooks_enabled enabled (the default), writes Codex hook configuration and trust records as described below—even before a rig launches. | | Rig/seat launch and attachment | Creates tmux sessions, supplies seat identity and daemon connection environment, and projects selected guidance, skills, plugins and runtime resources into the workspace. Managed startup pre-trusts the workspace. Claude context collection can also be provisioned for attached sessions and refreshed during monitoring. In a Git repository, newly created files under .codex/plugins/openrig-core/ are added to the repository's Git info/exclude inside an # BEGIN OpenRig generated files block; new AGENTS.md, CLAUDE.md and CLAUDE.local.md files stay visible with a warning. | | Bundle install (rig bundle install, or rig up with a .rigbundle or GitHub link) | Writes the bundle's files into the install target: --target, or the current directory for rig up and for a GitHub link. rig bundle install with a local archive needs --target. Routes its declared skills, plugins and context packs into your libraries. A GitHub link's archive is kept under OPENRIG_HOME/bundle-imports/, and installs are recorded in OPENRIG_HOME/bundle-audit.jsonl. A bundle that carries a project creates it under workspace.projects_root and records it, with the rig's association, in the workspace catalog. | | Explicit permission configuration | The built-in bootstrap does not add rig command allow rules. Agent-guided setup recommends Yes and requires your actual answer before the agent adds rules at your chosen scope. No/no answer preserves settings; existing choices and stricter rules remain relevant. Broader access is separate. |

The provider files are separate from instance state. Here ~ means the daemon user's home; changing OPENRIG_HOME alone does not isolate provider configuration.

• Claude Code: startup writes workspace trust and onboarding completion. With an explicit permission mode, it uses the launch-selected HOME/.claude.json, or <CLAUDE_CONFIG_DIR>/.claude.json when that variable is set. Classic startup writes HOME/.claude.json, and also <CLAUDE_CONFIG_DIR>/.claude.json when the daemon has that variable set. In the workspace, .claude/settings.local.json receives the context collector's statusLine command and selected activity hooks; helper scripts live under .openrig/. Selected settings/MCP resources can also change that settings file and .mcp.json. The shared settings resource sets permissions.defaultMode to acceptEdits and enables Exa/Context7 MCP entries; selected MCP resources configure those external services. Built-in bootstrap no longer writes a command allowlist to ~/.claude/settings.json or removes older allowances. CLAUDE_CONFIG_DIR does not relocate the project-local writes.
• Codex: writes