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
Start here: the guided first-use path: install, talk to the kernel operator, then choose a team for your first useful change.
Not setting this up today? Get the next walkthrough and occasional OpenRig updates → https://openrig.dev/follow
Let your coding agent set it up. First check that node --version shows 22 or 24: the command below needs
Node.js and the npx that comes with it. Then, in your project folder, add OpenRig's rigs skill to the agent you
use:
# Claude Code
npx skills add https://github.com/mvschwarz/openrig/tree/v0.7.12/skills/rigs --skill rigs --agent claude-code
# Codex
npx skills add https://github.com/mvschwarz/openrig/tree/v0.7.12/skills/rigs --skill rigs --agent codexThen type /rigs in Claude Code, or $rigs in Codex, and say what you want built. The skill has your agent tell
you what it will run and change before it does, install OpenRig, open the OpenRig view and pass your goal to
OpenRig's operator.
You need Node.js 22 or 24 (22 on Apple silicon), tmux, macOS or Linux (WSL2 on Windows), and Claude Code or Codex signed in. One provider is enough to start.
Already have OpenRig? Use the tag that matches rig --version, or upgrade first.
Prefer to type the commands yourself? Install it yourself ↓
Requires Node.js 22 or 24 and tmux, on macOS or Linux, and one working Claude Code or Codex account: one is enough, since the kernel operator adapts the shipped starter team to whichever you have. On Linux, the distribution's own Node.js can be older (Ubuntu 24.04's is 18); install a supported version with nvm (nvm install 22) or NodeSource. On a Mac with Apple silicon, use Node.js 22 (compatibility history). On a Mac where you aren't an administrator, or where Homebrew belongs to another account (its brew install is refused), install Node.js in your own home folder with nvm: run touch ~/.zshrc (a new Mac account has none, and nvm's installer only adds itself to a profile file that already exists), then nvm's install command, for nvm v0.40.8 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh | bash (nvm's page has the newest), open a new terminal, and run nvm install 22. nvm itself needs no administrator password, and npm install -g then installs into your nvm folder. If nvm's installer says you need Apple's command line tools, run xcode-select --install, then its install command again. On Windows, use WSL2, the Windows route OpenRig supports; native Windows isn't supported. OpenRig's automated tests don't run on WSL2 yet; see one user's working setup.
What OpenRig changes on your machine
- Install:
@openrig/cligoes in globally with npm.- Setup:
rig setupadds an OpenRig block to~/.tmux.conf. It can install tmux (with Homebrew on macOS), and Herdr unless you pass--no-herdr. Plainrig setup, which is what the one-command install runs, checks both Claude Code and Codex and may install a missing one;rig setup --providers claude(orcodex) limits it to yours.- Starting OpenRig, for the coding agent you use (paths are the usual defaults):
- Codex: hooks and trust in
~/.codex/config.toml.- Claude Code: workspace trust in
~/.claude.json, and activity hooks in the project's.claude/settings.local.json, plus a status line unless you already have your own.- Discovery skills go in
~/.claude/skillsand~/.agents/skills.- Starting a team in your project: adds managed guidance to
AGENTS.mdorCLAUDE.md, plus the team's skills and plugins.- Permissions: by default, OpenRig's own kernel gets broader permissions than a project team gets by default. On Codex that's full access with no approval prompts (
-s danger-full-access -a never). On Claude Code, its file tools, web fetches and operational commands, including reads under your home folder, run without asking. A permission policy, per-agent choice or Codex profile changes that. What your team can do depends on the team you choose and your settings;workshop, for example, ships with broad access.- Backups: OpenRig doesn't guarantee it can preserve or roll back these files, so back them up first.
This runs OpenRig's install script from the v0.7.12 release. It checks Node.js and npm, installs the latest published @openrig/cli with npm install -g, runs the Node.js and SQLite check, then runs rig setup --dry-run and rig setup. The first line prints that plan and changes nothing:
curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.7.12/scripts/install.sh | sh -s -- --dry-run
curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.7.12/scripts/install.sh | shIf the last step isn't ready, the installer reports INSTALLED, SETUP NOT COMPLETE and points to the details from rig setup above. Follow that output and any reported Fix, then rerun rig setup; the CLI does not need reinstalling. If the only remaining failures are provider sign-ins, sign in to each selected provider as below and continue.
Or step by step:
npm install -g @openrig/cli
rig setup --dry-runTo 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.
npm 11 and later can skip that postinstall script and print npm warn install-scripts naming @openrig/cli. That's expected: the CLI still works, and only the Node.js and SQLite check was skipped. To run it yourself, use node "$(npm root -g)/@openrig/cli/scripts/check-abi.mjs"; rig doctor checks the Node.js version only.
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; applying rig setup checks both harnesses and installs a missing one, plus Herdr unless declined with --no-herdr. Pass the choice with --providers claude or --providers codex so the other reads not selected instead of failed. The one-command install above doesn't know the choice, so it installs and checks both; for one provider, go step by step and run rig setup --providers <choice>. On macOS, the installing agent offers Ghostty once. Setup leaves an existing cmux installation alone. It is optional for the selected-provider path.
A team seat with no permission policy, per-seat choice or (for Codex) named profile launches with OpenRig's team default: Claude runs ordinary rig commands, project reads and common tests without prompting, while lifecycle commands such as rig up and rig down still ask; Codex also gets the OpenRig workspace and its pod's state directory as writable directories. Before launching, your agent recommends keeping that default, and offers to remember selected OpenRig commands in your native settings only if you want that, 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 keeps the team default and leaves settings unchanged. An existing explicit choice is reused. Say “Undo the OpenRig command allowances added by this setup” to remove only its additions.
If permission prompts are slowing you down, consider the workshop bundle. It ships with broad access and non-interruptive mode: its agents bypass permission prompts and supported harness warning dialogs. The listing and before-install view explain that access before you choose it.
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.
After installing, your agent opens the OpenRig TUI and the operator for you. To get back to them later, ask your agent for OpenRig or your agents in any words. After checking the selected login, it starts the daemon if it's stopped and opens the view:
rig daemon start
rig terminal open saved:kernel --window--window opens a new terminal tab or window itself, or a space in your current
Herdr session. Below 120 measured columns,
the operator fills the first page; from 120, the dashboard and operator share
it equally. The advisor has a separate tab or tmux window.
An installing agent can run it from its shell on the daemon's
desktop; the person copies nothing. It uses Herdr when installed, otherwise
the same layout in plain tmux, and preserves existing conversations. rig tui
is the team dashboard. Installation is finished when you are talking to the
operator; if you choose to talk later, that handoff remains pending.
If setup stops, read the named step: missing tools and selected-provider logins need their specific setup action. A harness permission rule, sandbox or automatic permission decision can also block the installing agent's command. The agent should name the command and reported reason, then help you resolve that specific step within your chosen permissions. A permission refusal is not an OpenRig installation result.
The desktop may need an Automation approval; SSH/headless sessions may have no
display. Herdr can show first-run panels, and an 80×24 window can cramp the view.
Follow the OpenRig view checks and next steps.
Herdr is visible only inside a terminal you can see. Changing the shared TUI to
:terminals does not open that terminal. The agent checks the visible window when
it has desktop access and says what it could not verify otherwise. Over headless
SSH, it asks you to open a new terminal window or tab and gives the exact connection
and attachment command for the current view. If you choose a manual attachment
after a failure,
ask the installing agent for the exact command using your current operator
session; run that in a new terminal window.
The kernel's operator helps you pick a first team. It asks what you want to build, recommends one of three, and fits it to the providers you have.
| Team | Talk to | Agents and purpose |
|---|---|---|
starter |
dev-build@starter |
A Claude Code builder and Codex reviewer for one bounded change |
workshop |
orch-lead@workshop |
A lead, builder, QA and reviewer for ongoing work in one repository; a rig bundle the operator installs from its pinned listing |
factory |
orch-lead@factory |
Seven: a lead, advisor, build, QA, design and two independent reviewers for sustained product work |
As shipped, starter uses both Claude Code and Codex. With only one of them, ask
the kernel operator to adapt it: it writes a copy of the team for your providers
under the same name. The naming guide explains
how their pods and roles grow and how to name your own team. first-project is
starter's old name and still starts it,
unless you already have a rig named first-project or starter: then it refuses
and names the rig up <name> --existing command that brings that rig back.
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 teams. A missing unused provider is not a setup requirement.
To launch the starter yourself instead (the manual path, without the operator):
cd /path/to/your/repository
rig specs preview starter --kind rig
rig up starter --cwd . --plan
rig up starter --cwd .To see your agents, use rig terminal open saved:kernel --window. If that window cannot open, rig tui --shared is the named dashboard-only fallback; it does not show the operator conversation. The installing agent should resolve or explain the window failure, not finish by suggesting a command for you to type. 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 builder one bounded outcome from your repository:
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.'
rig queue list --destination dev-build@starter --limit 1000Sending a message does not itself create a queue item; the builder records the task. Read the final artifact and the review of its exact candidate, then return to the same builder 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
- Questions: Discussions › Q&A
- Bugs and feature requests: open an issue
- Contributing: CONTRIBUTING.md · Code of Conduct · Security policy · Getting help
- Working on OpenRig with a coding agent? Start with the
developing-openrigskill in.agents/skills/(Claude Code:.claude/skills/) and CONTRIBUTING.md. - 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.
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. Installs herdr by default on macOS and Linux unless declined with --no-herdr; an unavailable herdr install is a warning. On macOS the installing agent offers Ghostty, and --ghostty attempts it after acceptance. Existing cmux settings are left unchanged. --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, the refocusing skill and the person-facing rigs skill in ~/.claude/skills and ~/.agents/skills, subject to existing version ownership. When a Codex seat is already recorded and runtime.codex.hooks_enabled is enabled (the default), ensures its hook configuration and trust records as described below. With no recorded Codex seat, enabled hooks wait for its first launch; disabled hooks still remove a stale OpenRig-managed hook block, if present. |
| 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/shared:openrig-core/ (or the unqualified .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 to your settings files; a team seat with no permission policy, per-seat choice or (for Codex) named profile gets the per-launch team default instead. Agent-guided setup recommends keeping it and requires your actual answer before the agent adds remembered rules at your chosen scope. No/no answer keeps the team default and 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.jsonwhen that variable is set. Classic startup writesHOME/.claude.json, and also<CLAUDE_CONFIG_DIR>/.claude.jsonwhen the daemon has that variable set. In the workspace,.claude/settings.local.jsonreceives the context collector'sstatusLinecommand and selected activity hooks; a user's own status-line command is preserved, so it can prevent collector installation. Selected settings resources can still replace overlapping keys. The collector script lives under.openrig/, and the activity-hook relay under the instance'sstate/claude-activity-hooks/. Selected settings/MCP resources can also change that settings file and.mcp.json. The shared settings resource enables Exa/Context7 MCP entries and leaves existingpermissions.defaultModeand permission rules unchanged. Managed launch flags select the session mode. Selected MCP resources configure those external services. Built-in bootstrap no longer writes a command allowlist to~/.claude/settings.jsonor removes older allowances.CLAUDE_CONFIG_DIRdoes not relocate the project-local writes. To keep your own status line alongside the collector, see Custom Claude status line. - Codex: writes the daemon's
CODEX_HOME/config.toml(normally~/.codex/config.toml). With hooks enabled, daemon startup ensures the OpenRig activity relay commands and their trust hashes when a Codex seat is already recorded; otherwise the first Codex launch does so. With hooks disabled, startup can remove a stale OpenRig-managed hook block even without a Codex seat. Seat startup addstrust_level = "trusted"for the workspace; selected config resources can add MCP settings. Managed launches pass-c check_for_update_on_startup=false, which writes no config; a recognized update notice that still appears can be skipped, recording the skipped version in Codex's cache; this is not an update install.
Activity relays send event type/subtype, seat/runtime identity, timestamps and
native session identity to the configured OpenRig daemon's /api/activity/hooks
endpoint, using its activity token. That payload excludes prompt text and tool
arguments. Claude's collector writes context/token usage, session/transcript-path
metadata and available rate-limit data to the instance's state/context-usage
and state/provider-usage. Provider and selected MCP connections have their own
data flows. Daemon plugin initialization also checks the OpenRig plugin release
endpoint on GitHub.
Managed launches supply HOME, CODEX_HOME and OPENRIG_* identity/connection
variables. Claude uses --permission-mode acceptEdits and defaults to the classic
renderer for terminal scrollback. Codex uses -s workspace-write unless a named
profile governs its sandbox; the default does not force an approval-policy flag.
On that plain launch OpenRig first asks Codex for its own configuration and adds
-c sandbox_workspace_write.network_access=true only when Codex answers that no
configuration layer sets network access and no managed requirement could restrict
it, so the seat can reach the local daemon. If Codex can't be asked or doesn't
answer in time, the launch is left unchanged.
Fresh Codex launches also add writable access to the workspace's .git and the
pod's shared queue-state directory with --add-dir; the shared root comes from
OPENRIG_SHARED_DOCS_ROOT or ~/.openrig/shared-docs.
A team seat with no permission policy, per-seat choice or (for Codex) named
profile also gets the per-launch team default: Claude gets --settings allowing
ordinary rig commands, project reads and common tests, with a session-only
PreToolUse hook that asks before lifecycle commands, and Codex also gets the
OpenRig workspace root as a writable directory. Neither writes a permission file.
Seats of the rig named kernel launch with an operational default instead,
unless a permission policy, a per-seat choice or (for Codex) a named profile
applies: Claude in acceptEdits with a per-launch allow list for its file tools,
web fetches and operational commands (including reads under your home folder),
and Codex with -s danger-full-access -a never. Neither writes a permission file.
YOLO is off by default. An explicitly selected full-bypass policy selects
Claude's --dangerously-skip-permissions or Codex's
-s danger-full-access -a never. The legacy environment-only OPENRIG_YOLO=1
path, with no policy attached, selects Claude's bypass flag, Pi's --approve and
Codex's -s danger-full-access without -a never; a resolved policy overrides
that environment setting. The builtin:auto policy launches Claude with
--permission-mode auto; Codex and Pi seats launch as they do without a policy (a
named Codex profile still governs its sandbox, and Pi keeps its configured
resource trust).
--non-interruptive on rig up or rig bundle install additionally passes
per-launch flags to full-bypass seats so Claude's bypass warning and Codex's
full-access and GPT-5.1 migration notices don't stop startup; it writes nothing to
their settings files and is saved on the rig. See
non-interruptive mode.
Permission mode controls native execution permissions; work posture is separate
project guidance. Use rig policy permissions list|show|current|apply for rig
policy configuration (the four rig policy aliases remain compatible). Use
rig seat set-permissions <seat> --mode <mode> --reason <text> for an audited
future-launch choice: floor, full_bypass, or inherit to clear the seat
override. Additional Claude modes such as auto require support from the exact
managed Claude executable at the seat's working directory; selection and launch
each check it. Unsupported or changed contexts refuse without a fallback.
This does not relaunch the seat
or change its current native process, history, rules or hooks. rig seat status
separates the desired selection from the last launch arguments; neither proves
native enforcement. See the permission guide.
Managed hook blocks target OpenRig's entries and retain unrelated hooks, but
trust entries and selected resource keys can be replaced. Claude's collector,
activity-hook and JSON resource writers leave unreadable or malformed settings
untouched; this is not a product-wide preservation guarantee. Codex's workspace
trust writer can treat an unreadable config.toml as empty and write a new trust
configuration. Read-modify-write operations can also race other writers; there
is no complete preservation or rollback guarantee. Back up relevant
files before first use. Daemon/bootstrap writes are automatic and do not each
have an interactive preview; rig setup --dry-run does not preview every later
startup effect.
OpenRig is a multi-agent harness — it manages the system that coding agents form when you run them together. Not the agents themselves, but the team they create: which sessions are running, how they relate, how to recover after a reboot, and how to stop it from becoming terminal sprawl.
- Define topologies in YAML (RigSpec) with pods, edges, and continuity policies
- Boot everything with
rig up— tmux sessions, harnesses, startup files, readiness checks - See rigs, pods, and seats in the TUI topology table and graph; inspect projects, specs, feeds, and instance health
- Discover existing Claude Code and Codex sessions in tmux and adopt them into a managed rig
- Snapshot the topology with
rig down --snapshot, restore by name withrig up <name> - Communicate across agents with
rig send,rig broadcast, andrig chatroom - Protect a seat where you type by hand:
rig seat set-typing-guard <seat> --enabled true --reason <text>holds automatic messages and wakes instead of typing them into that seat (off by default; seerig seat set-typing-guard --help) - Connect Slack through an app you create in your own workspace; the experimental
rig slack manifestprints that app's manifest (setup guide) - Evolve running topologies with
rig grow,rig shrink,rig launch,rig remove
Every terminal seat runs in a tmux session you can attach to, inspect, and work with directly. Hosted members join through OpenRig's MCP server and have no pane.
Three teams grow with you, and the kernel operator helps you pick one:
starter: a builder and a reviewer for one bounded change.workshop: a lead, a builder, QA and a reviewer for ongoing work in one repository. It's a rig bundle, installed from its pinned listing.factory: seven agents (a lead, an advisor, build, QA, design and two independent reviewers) for sustained product work. You bring ideas to the advisor, and the lead runs the team.
rig specs preview factory --kind rig
rig up factorySpecialist teams: code-review (two independent reviews), research (an analyst and a synthesizer) and pm (a product lead, a researcher and a builder for prototypes).
Also built in: secrets-manager, a HashiCorp Vault instance run by a specialist agent.
Browse the library:
rig specs lsOpenRig is a local daemon + CLI + terminal UI + MCP server, built on tmux. OpenRig itself is under active development; only the older React web UI is in maintenance mode, with best-effort support.
CLI / TUI / MCP
|
Hono HTTP daemon
|
Domain services
|
SQLite + tmux + runtime adapters
- CLI: Commands for both humans and agents to launch teams, inspect state, send messages, track owned work, and manage context.
- TUI: Topology explorer, table and graph views, seat details, Specs, Projects, Terminals, Feed, and System. Navigate with the keyboard, mouse, or command bar.
- MCP: Tools so agents can manage their own topology (
rig_up,rig_ps,rig_send,rig_chatroom_send, etc.) - Runtimes: Native Claude Code and Codex sessions, terminal nodes, and Pi and Oh My Pi via RPC runners.
The TUI shows the team's coordination state; herdr and cmux show the actual agent terminals alongside it. Use rig tui commands to list the TUI's command-bar navigation, or try the interactive TUI tour.
Captured from the interactive TUI demo using fictional project data.
With herdr installed and connected, open the starter's terminals together:
rig terminal open starter --provider herdrFor cmux, use --provider cmux. In the TUI, a rig's detail view has an Open terminals ▸ rig <name> link that opens a terminal view of the running seats of that rig (in a new window or tab, or the current Herdr session), laid out with herdr when installed, otherwise plain tmux; with herdr that is up to 16 seats per tab, in a workspace named after the rig. A seat it can't attach is reported as absent or degraded. The underlying sessions remain accessible through tmux. See the terminal workspace guide for setup and returning to an existing view.
The first words you meet, in plain language: What these words mean.
- RigSpec: Declarative multi-agent harness definition in YAML. Pods, members, edges, continuity policies, culture file.
- AgentSpec: Reusable agent blueprint with skills, guidance, hooks, profiles, and startup contracts.
- Seat: A stable role and address in a rig, such as
dev-build@starter. The conversation occupying it can change while its identity and authored context remain. - Pod: A group of related seats with shared guidance and context. Each agent still has its own context window.
- Discovery:
rig discoverfingerprints existing tmux sessions.rig adoptbrings them under management. - Snapshot/Restore:
rig down --snapshotcaptures full state.rig up <name>restores from latest snapshot. Restore reports per-node outcomes: resumed, fresh-primed, awaiting-decision (the original conversation can't resume; choose--fresh), attention_required, or failed. - RigBundle: Portable archive with vendored AgentSpecs and SHA-256 integrity. Share topologies across machines.
rig up,rig bundle create,inspectandinstallalso take a GitHub folder link,rig bundle checkchecks a folder before you share it, andrig bundle inspectshows what a bundle will do before you install it. See publishing a rig bundle. - Culture: A rig's
CULTURE.md(itsculture_file) sets coordination norms for the group, on top of OpenRig's default culture, which every seat receives.
A rig can package actual software alongside the agents that manage it. The shipped example is secrets-manager: a HashiCorp Vault instance operated by a specialist agent.
rig up secrets-manager
rig env status secrets-manager
rig send vault-specialist@secrets-manager "Check Vault health and report status." --verifyRequires Docker for service-backed rigs.
For an existing installation, follow the upgrade procedure and the 0.5.14 release notes; notes for later releases are in CHANGELOG.md. Preserve live seats during the upgrade; rig down is not an upgrade step. Upgrading to 0.6.0 also requires Node.js 22 or 24: see Moving off Node 20 and the 0.6.0 release notes.
OpenRig 0.6.0 supports Node.js 22 and 24 only. Its SQLite binding (better-sqlite3 13) requires Node 22 or newer. Node 20 is no longer supported; the install check refuses it with an explanation.
If you run OpenRig on Node 20, switch Node first, then reinstall the CLI under the new Node (a version manager keeps a separate global package set for each Node):
nvm install 22 # or 24; fnm or your package manager work the same way
npm install -g @openrig/cli
rig --versionYour existing OpenRig data stays where it is. The daemon reopens the same database