What's new

Agents you've already set to full bypass can launch without stopping at Claude Code's and Codex's first-launch warnings, and the rig remembers that choice through restores and handovers. You can also make it the default for new rigs.

--non-interruptive on rig up and rig bundle install lets agents whose policy is full bypass skip Claude Code's and Codex's first-launch warnings through launch flags. The choice is saved on the rig and kept for restores, forks and handovers, and rig config set launch.non_interruptive true makes it the default for new rigs.

Only agents whose policy is full bypass skip the warnings. Existing rigs start with it off. --no-non-interruptive clears it, with the rig down first. No harness settings file is written.

#737, #741Link

Agents that are slow to start can be given up to ten minutes to become ready, at launch, restore and handover, instead of the default 30 seconds.

runtime.readiness_timeout_seconds (1 to 600, default 30) gives slow agents more time to become ready at launch, restore and handover.

#643 · thanks @Nikhi00718Link

The restore map a Claude agent writes before its context is compacted now sits in the agent's own launch folder, with a .gitignore that keeps it out of your commits. Tools that ignore .gitignore, such as rsync or zip deploys, still see it.

Managed Claude compaction now writes its restore map inside the agent's own launch folder, at .openrig/compaction/preparation/<session>/<attempt>/RESTORE-MAP.md, with a .gitignore that keeps it out of Git.

Tools that don't read .gitignore, such as rsync, zip deploys and Docker build contexts without .dockerignore, still see the folder. The OpenRig home is used when the workspace is unknown or unwritable.

#685Link

You can change an agent's permissions from an ordinary shell, not only from inside an agent, and an incomplete request tells you exactly which part is missing.

rig seat set-permissions takes --operator <address>, so it works from a plain shell, and reports a missing identity, mode or reason as three separate errors.

#689Link

Startup text that wasn't confirmed as sent now shows as a warning in launches, imports, restore records and the TUI, so an agent that may have missed its instructions is easy to spot.

Startup files delivered later get the same submit check, and staged or unverified startup text shows as a warning in rig bootstrap, rig import, rig seat launch, restore records and the TUI.

#736 · thanks @pr0xc3nt4ur1Link

If an agent is stuck at a provider's own prompt, such as Claude's trust dialog, OpenRig flags it for your attention instead of calling it ready, so you know someone has to answer it.

An agent stopped at a provider's own prompt, such as Claude's trust dialog, is reported as needing attention instead of ready.

#684Link

If rig down can't stop an agent, that agent keeps its CLAUDE.md or AGENTS.md, so it isn't left running without its instructions.

When rig down can't stop an agent, it leaves that agent's CLAUDE.md, CLAUDE.local.md or AGENTS.md in place instead of stripping or deleting it.

#662 · thanks @Vaishnavi220506Link

Agents can look up which specialist to bring in for a job, and why, from rosters you keep, across teams and machines. It's a lookup only and never assigns work.

rig roster list, show and find read JSON rosters from <workspace.root>/rosters/ and show who to involve for a purpose and why, across rigs and hosts. They never assign work.

#697Link

Handing work to another agent returns as soon as the task is saved, so you aren't kept waiting on delivery. When you need to know it was delivered, add --verify.

rig queue create, handoff and handoff-and-complete return once the change is saved, and the agent is notified after that. The result no longer reports whether that notification was delivered; use --verify to wait for delivery.

#776Link

Answering an agent's numbered menu from outside its terminal now sends the digit as a keypress rather than a paste, so the menu gets the choice you meant. It hasn't been tried against a live Claude Code or Codex menu yet.

rig send --dangerously-interact now types your answer as keystrokes instead of a paste, so a numbered menu gets the digit you sent. This addresses a known issue, #519.

It wasn't tried against a live Claude Code or Codex menu. Upgrade the CLI and the daemon together for this.

#663 · thanks @DianaKerimLink

Marking a task as blocked is easier to get right: the help says you must name what it's waiting on, and naming a task this daemon doesn't have suggests waiting on something outside OpenRig instead.

rig queue block help says --on is always required, and blocking on a task this daemon doesn't have suggests an external gate instead.

#664Link

A new Claude Code agent stopped at Claude's bypass-permissions warning no longer loses its startup instructions. Accept the warning in its terminal, and one command, which rig up prints for you, delivers them into the same conversation without a relaunch.

If a fresh Claude Code agent stops at Claude's bypass-permissions warning, it now keeps its startup context and reports attention as bypass_consent_gate. Accept the warning in that agent's terminal, then run rig seat continue <seat> to deliver the context into the same conversation without relaunching; rig up and rig bundle install print the command.

#740, #748Link

You can run Claude Code agents in Claude's own auto permission mode by picking one built-in policy, and see each agent's effective mode and where it came from. The policy is a community contribution.

A new built-in policy, builtin:auto, launches Claude Code agents with --permission-mode auto, while Codex and Pi agents launch as they normally would. rig seat status prints the effective permission mode and where it came from, and the built-in policies are described in the RigSpec reference.

#680, #733, #713 · thanks @shravansumanthananLink

Claude Code agents in your teams can run OpenRig commands, read the project and run its tests without a permission prompt, but still ask before starting, stopping or installing teams. It's an allow list, not a sandbox, and applies only where you haven't set permissions yourself.

Claude Code agents in your teams need fewer permission prompts. OpenRig passes an allow list and an ask list at launch, so rig commands, reads inside the project and common test commands such as npm test, pytest, go test and cargo test run without a prompt, while lifecycle commands such as rig up, rig down, rig bundle install, rig seat stop and rig daemon stop still ask.

Applies outside the kernel at an agent's next launch, resume, fork or handover, only when no member or rig permission_policy and no saved permission choice is set; permission_policy: none keeps the old behaviour. These are command allowances, not containment: a project's test command runs project code. Your own ask and deny rules still apply, and no settings file is written. Asking before lifecycle commands works in Claude Code team agents only; Codex team agents don't ask yet. In a Claude Code team agent, rig down --help also asks; rig help down prints the same help without a prompt. rig setup's permission question still describes the behaviour before these defaults; its text is corrected in the next release.

#893Link

New Claude agents finish setting themselves up without anyone typing to them: after their startup text, OpenRig sends one short line asking each to run its startup check.

After delivering a Claude Code agent's startup text, OpenRig sends one short line asking it to run its startup check, so Claude agents finish getting set up on their own.

#719, #743, #747Link

OpenRig reads more Claude Code screens correctly: an agent with only update or limit warnings under an empty prompt counts as idle and gets its messages, and one that's visibly working isn't mistaken for idle.

A Claude Code pane is read as idle when update, focus-events or weekly-limit warnings sit below an empty input, in every permission mode, and a pane showing live work alongside the mode bar is read as working.

#735, #814 · thanks @AdamWhitehurstLink

When a Claude Code agent asks a question with a long list of choices, OpenRig now recognises that it's waiting on an answer.

A tall Claude Code question picker is recognised as a waiting question.

#745 · thanks @gopinathrimcLink

Claude agents launched through a shell wrapper named with a version number are now recognised by their executable path, so a restore problem flagged on them can be cleared. A restore can still report a problem with an agent that works.

OpenRig can identify a Claude process running under a shell wrapper with a version number as its name, by its executable path, so restore attention on such agents can be cleared.

On macOS the daemon may run the built-in /usr/bin/osascript for this; whether macOS shows a permission prompt for it on a Mac that has never approved one hasn't been observed. A restore can still report a problem with an agent that works (#273); several fixes target it and it isn't fully resolved.

#724, #730Link

Claude agents brought back with rig up --existing keep reporting their activity to OpenRig, and a restore that can't set that up again says so.

An agent brought back with rig up --existing keeps its Claude activity hooks, and a restore that can't reapply them now says so.

#731, #746Link

Forking a Claude agent now quotes the parent conversation's ID in the launch command, so the shell can't misread it.

Forking a Claude agent quotes the parent session ID in the launch command.

#773 · thanks @DeryFerdLink

Codex agents in your teams get the same relief: routine OpenRig, read and test commands ran without prompts in testing, still inside Codex's sandbox. One difference for now: they don't ask before starting or stopping teams, as Claude Code agents do.

Codex agents in your teams need fewer permission prompts too. They keep the workspace-write sandbox and can also write OpenRig's workspace folder and the state folder of their pod (their group of agents), and ordinary rig, read and test commands ran without prompts in testing.

Codex team agents don't ask before lifecycle commands such as rig up and rig down yet; Claude Code team agents do. Applies only when no member or rig permission_policy, saved permission choice or named Codex profile is set; permission_policy: none keeps the old behaviour. rig setup's permission question still describes the behaviour before these defaults; its text is corrected in the next release.

#893Link

Codex agents no longer get stuck at launch, resume or fork when Codex 0.160 shows its newer update menu.

Codex agents no longer stall at launch, resume or fork when Codex 0.160 shows its update menu with the new header.

#861Link

Oh My Pi agents using Anthropic, OpenAI or LiteLLM models can send requests to a custom endpoint, such as a gateway, once you allow that provider's base-URL variable. If you already allow one, those agents now use it.

An Oh My Pi agent whose model is written anthropic/…, openai/… or litellm/… now also receives that provider's base-URL variable when you allowlist it in recovery.provider_auth_env_allowlist.

If you already allowlist ANTHROPIC_BASE_URL or OPENAI_BASE_URL, those Oh My Pi agents now send requests there. Oh My Pi agents weren't tested beyond automated tests.

#744 · thanks @PowellTravisLink

A rig with a Pi agent no longer fails its pre-launch check just because the daemon can't see pi on its PATH, since the agent's own shell finds it at launch. Pi flag errors also name your Pi version.

A rig with a Pi agent no longer fails preflight when pi isn't on the daemon's PATH; it warns, and the pane's shell finds Pi at launch. Pi flag errors name the Pi version.

Pi agents weren't tested beyond automated tests.

#655Link

Pi agents keep talking to the right daemon as the right agent, even when your shell startup files set conflicting values.

Pi agents keep their daemon routing and identity when shell startup files set conflicting values.

Pi agents weren't tested beyond automated tests.

#666Link

When a Pi agent can't find an API key, the error now tells you what to set.

A Pi agent failing with "No API key found" now says what to set.

Pi agents weren't tested beyond automated tests.

#667Link

When Oh My Pi quits during startup, you see how it exited and its last error output, so you can tell why.

When Oh My Pi exits during startup, the error says how it exited and shows its last stderr lines.

Oh My Pi agents weren't tested beyond automated tests.

#646 · thanks @1solomonwakhunguLink

If the daemon loses its Slack connection for a while, top-level channel messages posted during the gap still reach your agents, late and marked as recovered, instead of being missed. rig slack status shows the connection and whether it's catching up.

Top-level Slack messages posted while the daemon was disconnected now arrive late, as tasks marked "Recovered after a gap". rig slack status shows the live connection and recovery state.

Needs Slack inbound configured. Each channel gets a recovery checkpoint on the first daemon start, and history before that checkpoint stays unknown. Live Slack recovery wasn't tested.

#742Link

OpenRig's saved Slack connection state stays intact if the daemon crashes while writing it.

Slack gateway state survives a crash in the middle of a write.

#669 · thanks @rudycelekliLink

One command opens the kernel's TUI, advisor and operator side by side on any kernel, Claude-only, Codex-only or mixed, with nothing to set up first. A kernel view you saved yourself still takes priority.

rig terminal open saved:kernel works without any saved-view file: it opens the TUI, the advisor and the operator side by side, for Claude-only, Codex-only and mixed kernels. A view you saved yourself under the name kernel still wins.

#830, #854Link

Without herdr or cmux, you still get the exact tmux or ssh command to reach each agent, and the shared TUI is labelled as the dashboard, not the place to talk to agents.

Without herdr or cmux, setup, the TUI preview and a failed rig terminal open give an exact tmux or ssh -t attach command for each agent, and rig tui --shared is named as the dashboard, not the conversation.

#831, #833, #878Link

Open a team's spec in the TUI to see how its agents fit together as a graph, then launch it from there: it asks for a working folder and runs the real rig up.

A rig spec opened in the TUI starts on a graph of its topology, with Launch: it asks for a working folder and hands the terminal to the real rig up.

#867, #874Link

When a team starts, you know where to go: watch it from the dashboard, and talk about the work in the lead's pane.

Team views say the dashboard is the overview and the lead's pane is where you talk about the work.

Shaped by an earlier first-user run on macOS, which wasn't rerun on the final package.

#884, #890Link

Open the TUI and you're at your work right away, even before any team is running, rather than on a start page. The Start page is one key away, on S.

The TUI goes straight to the work views once it has read the daemon, even when no rig is running. The Start page is still there on S.

#818Link

The TUI's recent task activity takes less work to load when there's a long history behind it.

The query behind the TUI's recent queue activity does less sorting on large histories.

#816Link

rig terminal open now uses the daemon's own tmux, and with herdr it reports a pane that closes at once as degraded instead of treating it as working.

rig terminal open starts tiles with the daemon's own tmux, and with herdr reports a pane that exits at once as degraded.

#715Link

Tools that collect OpenRig's history can read it a page at a time through the CLI, with any gaps marked, instead of reading OpenRig's database directly.

rig telemetry events, transitions and tenures read one bounded page of retained history at a time, with a cursor and explicit gaps, so collectors no longer read OpenRig's database.

#696Link

Inventory timeouts are easier to diagnose: requests marked with a diagnostic header are traced in the daemon's slow-operation log.

Requests that carry an X-OpenRig-Diagnostic-Attempt header are traced in the daemon's slow-operation log, to help diagnose inventory timeouts.

#726Link

The project commands shadow-drain and shadow-stop now work from an ordinary shell, not only from inside an agent.

rig project shadow-drain and shadow-stop take --actor, so they run from a plain shell.

#665 · thanks @Coder8124Link

Before you stop or restart a running team, the help tells you what that does to the work in progress.

Lifecycle help says what stopping or restarting a live team does to its work.

A text change, packaged without a new journey run.

#895Link

Stopping services through the daemon's API removes their data volumes only when the request explicitly asks for it. The rig env down --volumes command works as before.

Tearing down services through the daemon's API deletes volumes only when the request says volumes: true as a JSON boolean. rig env down --volumes is unchanged.

#668 · thanks @rudycelekliLink

rig host pair always gives up eventually, even when given an infinite or oversized timeout.

rig host pair --timeout caps an infinite or overflowing value at about 25 days instead of waiting forever.

#734 · thanks @DeryFerdLink

When rig whoami can't find the agent, the error names the daemon it reached, so you can tell if it's talking to the wrong install.

When rig whoami or rig health --self can't find the agent, the error names the daemon it reached.

#660Link

Pointing rig project experimental at a named pipe now gets a clear refusal instead of a hang.

rig project experimental refuses a FIFO instead of hanging.

#670 · thanks @rudycelekliLink

rig capture now shows an empty agent screen as empty.

rig capture shows an empty pane as empty.

#671 · thanks @rudycelekliLink

OpenRig's MCP server exits when its input closes, and keeps using the daemon address it found, including IPv6 ones.

rig mcp serve shuts down when its input ends, and keeps the daemon address it found, including IPv6.

#674, #676 · thanks @rudycelekliLink

Mission titles with colons, hash signs or quotes no longer break the mission's file.

A mission title with : , # or quotes writes valid frontmatter.

#768 · thanks @adampogLink

rig env logs --tail 0 now prints no earlier lines, as you asked.

rig env logs --tail 0 prints no past lines.

#673 · thanks @rudycelekliLink

rig env status keeps working when a cached service record is damaged.

rig env status survives a corrupt cached service record.

#675 · thanks @rudycelekliLink

Agent transcripts now read correctly where text was erased with several backspaces in a row.

Transcript cleanup applies runs of backspaces correctly.

#677 · thanks @rudycelekliLink

A team can be shared as a link to a folder on GitHub and installed straight from it, pinned to one commit and with a package digest you can check. You need git and a running local daemon.

rig up, and rig bundle create, inspect and install, accept a public GitHub folder link (https://github.com/<owner>/<repo>/tree/<ref>/<folder>). The ref resolves to one commit, and the result reports the source, configuration ID and package digest.

Link import needs git on your PATH and a running local daemon. It runs your git with credential helpers, hooks and global config disabled.

#708Link

A team can come in several ready-made configurations, such as which runtime each agent uses, and you choose one when you install it.

A bundle can declare presets in configurations.yaml. rig bundle configurations <spec> lists them, and --preset <name> or --seat pod.member=runtime picks one.

#704Link

Before you install a team, you can see what it will do on your machine: its models, whether permission prompts are off, the files and startup actions it brings, what it writes and which outside domains it uses. The author's setup steps are shown, never run.

See a team before you install it. rig bundle inspect, and the view printed before rig bundle install and rig up <bundle>, show the team and models, its permission settings including whether prompts are off for every agent, files the agents receive, startup actions, writes, outside domains, the author's setup preconditions and what stays unknown until launch. Facts about one agent are labelled with that agent.

The author's setup preconditions are shown, never run, and some facts stay unknown until launch.

#710, #717, #723, #738, #892Link

Install a team and point all its agents at your project folder in one step, separately from where the team itself is installed.

rig bundle install --cwd <dir> sets every agent's working folder, and --target sets the install folder.

#692Link

Team authors can check a bundle against the authoring rules on their own machine before sharing it. The check is advisory.

rig bundle check <folder> checks a bundle against the authoring rules, locally.

It's advisory.

#708Link

When you package a team, it can carry a context pack kept outside the rig folder and the project the team works in, so whoever installs it gets both.

rig bundle create --context-pack <dir> carries a context pack from outside the rig folder, and --project-dir <dir> carries the project the rig works in.

#694, #700, #716 · thanks @DeryFerdLink

Installing a team you already have now asks what to do: use it, stop and replace it, or cancel. A running team is left alone, and conflicting files are backed up before a stopped one is replaced.

Installing a team that already exists shows what's installed and offers to use it, stop and replace it, or cancel. A running team is refused before anything is written; a stopped one is replaced in the folder holding its installed manifest, with conflicting files backed up first.

Reinstalling into another folder that holds a copy of the team's installed manifest treats that folder as the team's install folder, so its conflicting files are replaced. They're backed up first and the backup is named.

#877Link

Publishing your team on openrig.dev/rigs takes one pull request that adds a single file pointing at your repository. The guide ships with OpenRig.

To share a team, open a pull request to openrig-world that adds one file naming its repository, folder and ref. Rig names on the site are unique, and the guide is docs/reference/publishing-a-rig-bundle.md, also at $OPENRIG_HOME/reference/.

#750, #751, #810, #777Link

If you build tools around team bundles, the v1 formats are now documented, with JSON Schemas to validate against.

The v1 bundle formats are documented in docs/reference/bundle-formats.md, with JSON Schemas.

#702Link

Install the workshop from openrig.dev/rigs for a four-agent team that builds in any repository: its lead plans from your goal and routes work to a builder, a reviewer and QA, and nothing is published until you say so. Its agents run without permission prompts, and the view before install says so.

The workshop, OpenRig's team for building software in any repository, OpenRig's own included, installs from openrig.dev/rigs, which shows its install command. It has a lead, a builder, a code reviewer and a QA agent; the lead starts from your goal, plans the work and routes it to the team, and nothing is published until you say so.

It ships separately, in the openrig-world repository, needs OpenRig 0.6.6 and isn't built in, so rig up workshop doesn't resolve. Its agents run with permission prompts off and install non-interruptively by the team's own declaration; the view before install says so. The current workshop was checked separately with a startup check, not a full journey, and not in other configurations or with Pi. The first-user journey used an earlier workshop revision.

Link

A team's author can declare in its spec that it launches without first-launch warnings, and a flag you pass on the command line still overrides it.

A rig spec can declare non_interruptive: true itself. An explicit flag still wins, and the declaration wins over the machine default.

#892Link

If you start any of these three teams by name, in scripts or by habit, switch to the new name. The old ones have no alias.

Three specialist teams were renamed: adversarial-review is now code-review, research-team is now research and pm-team is now pm.

There's no alias for the old names.

#864Link

Instructions that say rig up first-project keep working and now start the starter team, which pairs a Claude Code builder with a Codex reviewer. On a Codex-only machine, ask the kernel's operator to adapt it, and use a Codex newer than 0.145.

rig up first-project still works and starts starter, with a note that the team's providers changed. first-project used two Codex agents; starter has a Claude Code builder and a Codex reviewer.

On a Codex-only machine, ask the kernel's operator to adapt it. The starter's Codex reviewer needs a Codex newer than 0.145, which refuses its model with "requires a newer version of Codex"; Codex 0.160.1 works.

#864Link

Seven older built-in teams were retired. Any rig you already created from one of them keeps restoring as before.

conveyor, demo, implementation-pair, product-team, first-project-claude, first-project-mixed and factory-rsi are no longer built in. Rigs you already created from them keep restoring.

#864Link

Two rigs with near-identical names no longer end up sharing Docker containers by accident, because each new rig with services gets its own Compose project. Existing rigs keep theirs, and a brand-new rig won't reuse old containers unless you name the project.

A new rig with services gets a Docker Compose project named from its rig ID instead of its name, so two rigs whose names sanitize to the same string no longer share containers. Existing rigs keep their project.

A rig created fresh, not as a same-name replacement, won't attach to containers or volumes under the old name-based project unless you set services.project_name.

#481 · thanks @dajiaohuangLink

If a new rig's services fail to boot or none of its agents launch, OpenRig takes down the containers it just created and never deletes their volumes. When rigs being replaced would clash over containers, rig up refuses before starting anything.

If service boot or every agent launch fails, a rig's new Compose project is brought down, never with its volumes. When the earlier rigs being replaced use different projects and no project_name is set, rig up refuses with compose_project_conflict and starts no services, and rig down exits 2 when it keeps a project that a live rig of the same name still uses.

#481 · thanks @dajiaohuangLink

Previewing the starter or factory team ends with the same three-team choice, so you can compare before you pick.

rig specs preview starter and rig specs preview factory end with the three-team choice.

#884Link

Everything a bundled team brings, from skills and plugins to context packs, is put in place before its agents start, and anything that can't be routed is reported instead of silently dropped.

Skills, plugins, workflow specs, context packs and agent images in a bundle are put in place before any agent launches, and routing failures are printed instead of dropped.

#692, #705, #720, #722Link

Installing a team never changes a context pack you already have under the same name. OpenRig tells you it kept yours.

Installing a bundle never overwrites or merges into an installed context pack with the same name; it reports already_installed or kept_existing.

#694Link

Bootstrapping from a .rigbundle file now uses the same install path as rig bundle install, so both ways of installing a team behave alike.

rig bootstrap <file>.rigbundle now goes through the normal bundle install.

#709Link

The built-in teams are now a shorter list with plainer names: starter (a builder and a reviewer) for a first team, factory (a lead and six other agents) for bigger work, and specialist teams such as code-review and research.

The built-in teams have new names. The shelf is now starter (a Claude Code builder and a Codex reviewer), factory (a lead, an advisor, a builder, QA, design and two reviewers), the specialist teams code-review, research and pm, plus secrets-manager and the kernel. Shipped help, skills and onboarding use the new names.

#864, #866, #868Link

Every bundle now records which configuration it was built from and the OpenRig version that built it, so you can tell later where it came from.

Every rig bundle create records the configuration ID and the assembling OpenRig version in bundle.yaml, and bundles built by an installed OpenRig record its real version.

#718, #708Link

Inspecting a bundle before you install it now applies the same archive safety checks install does, so an unsafe archive is caught at the first look.

rig bundle inspect refuses the same unsafe archive entries that install refuses.

#695 · thanks @DeryFerdLink

An older-format bundle whose project settings point outside its own folder is now refused.

A legacy bundle whose project block escapes its root is refused.

#716 · thanks @DeryFerdLink

A package can no longer use a skill or agent name to write files outside its install folder. It's refused before anything is written.

Installing a package whose manifest gives a skill or agent a name that would write outside the install target is refused before anything is written.

#725 · thanks @DeryFerdLink

A project can name the world packs its agents should install, alongside the rest of its context.

A project can list world packs under install.worlds.

#691Link

Any Claude Code or Codex session, even outside an OpenRig team, gets a way into OpenRig by adding one skill with a single npx command.

The rigs skill gives an ordinary Claude Code or Codex session a route into OpenRig. It lives in the GitHub repository rather than the package; add it with npx skills add mvschwarz/openrig --skill rigs.

#872, #881Link

Implementer and QA agents now start without the test-driven-development skill loaded. If your team works that way, the skill is still available.

The implementer and QA agents no longer load the test-driven-development skill by default. The skill is still available.

#864Link

OpenRig no longer hides the guidance files it adds to your repository: a new CLAUDE.md or AGENTS.md shows in git status, and OpenRig prints the exact ignore line if you want it hidden. Only its Codex plugin files are ignored automatically, in a marked block you can edit.

Files a launch creates now show in git status. When a launch creates a new guidance file such as AGENTS.md or CLAUDE.md in a Git repository, OpenRig leaves it visible to Git and prints the exact line you can add to .git/info/exclude. New files under .codex/plugins/openrig-core/ are excluded automatically, in a marked OpenRig block in info/exclude where deleting a line makes that path visible again.

At launch, OpenRig runs your git to check generated files and may append its marked block to info/exclude.

#721, #727Link

With several projects in one workspace, an agent loading its project context gets one picked by clear rules and is told how it was chosen. Only a real tie stops it, with a ready-to-run command for each candidate.

With several projects declared and no --project, rig context work-install picks the project whose rigs: list names the agent's rig, then the deepest project root containing the working folder, then the only unclaimed project, and reports how it chose. It stops with project_required only when more than one still matches, printing a ready-to-run command for each candidate.

#690, #688, #772Link

The getting-started and agent help guides now cover what to do when an agent needs attention at startup, including Claude's bypass warning, slow-starting agents and the auto permission policy.

The getting-started guide and the agent help guide explain rig seat continue, startup attention, readiness timeouts, Claude's bypass warning and builtin:auto.

#779Link

Adding context works even when the daemon is stopped, because the command starts it for you.

rig context add starts a stopped local daemon.

#784Link

Agents working on OpenRig's own code are pointed to the skill that explains how OpenRig is built.

The bundled skills index sends agents that are changing OpenRig itself to the developing-openrig skill.

#829Link

If you read or contribute to OpenRig's code, its developer docs were refreshed throughout, with each claim checked against the code at the time.

The developer documentation was refreshed, with each claim checked against the code at the time: the README, CONTRIBUTING, SUPPORT and SECURITY; the reference pages for specs, projects, bundles, operations and process; the architecture pages and CLI reference; and ARCHITECTURE, DESIGN and the TUI README.

A final pass against the release commit is a separate change.

#782, #777, #783, #785, #788, #789, #791, #795, #797, #823, #825, #775, #778, #781, #787, #790, #792, #793, #794, #799, #804, #805, #826, #856, #796, #803, #806Link

OpenRig's contributor guidance now asks whether an agent with instructions could do a job before anyone writes code for it.

The contributor skill asks whether an agent with instructions could do a behaviour before adding code for it, and points to the capability map first.

#827, #828Link

Skills that come in a plugin, including OpenRig's own, are now copied to the folders Claude Code and Codex actually load skills from, which never happened before. Checked with stand-in harnesses, and existing agents get them when next created, not on restore.

When an agent's profile selects a plugin, such as openrig-core, its skills are now copied into the agent's .claude/skills/ or .agents/skills/ folder, where Claude Code and Codex actually load them. Before, neither runtime saw them.

Checked with stand-in harnesses; whether a real Claude Code or Codex agent lists and loads each skill is checked separately. Existing agents get the skills when they're next instantiated, not on restore. An existing folder with the same name that OpenRig doesn't own is kept, with a plugin_skill_kept warning.

#815, #823Link

The attention view, the health readout and rig mode effective now use the projects you configured and pick a task's project the same way project context does, so they agree on which project a task belongs to.

rig mode effective, the attention view and the health readout now read the project catalog you configured, and when a task names only its mission they pick its project the same way rig context work-install does.

#693, #712Link

An agent can carry its own version of a skill: the launch uses it and warns that it differs from OpenRig's catalog, instead of failing.

When a profile selects a skill from its own agent folder that differs from the managed catalog, the launch uses the selected skill with a skill_bundle_precedence warning instead of failing.

#720, #722Link

A context-pack folder created in the workspace after the daemon started is now found by sync, without restarting the daemon.

rig context sync finds a workspace context-pack folder created after the daemon started.

#686Link

Context packs that include JavaScript or Python helper files now install from the command line.

Context packs with .mjs or .py helper files install from the CLI.

#706Link

Skills and commands no longer point you to skills OpenRig doesn't ship, and rig compact-plan names the compaction restore skill that does.

rig compact-plan points to the shipped claude-compaction-restore skill, and shipped skills no longer point to skills that don't ship.

#683Link

After install, the first agent you meet is the kernel's operator: it asks what you want to build and recommends one of three teams. It's guidance the agent follows, not a scripted flow, and in the first-user test the person still needed help attaching terminals.

After you install OpenRig, the kernel's operator agent greets you first and asks, once, what you want to build or change. It offers three teams, starter, workshop and factory, with one recommendation and a drawing of each.

This is guidance the agents follow, not a scripted wizard; how closely an agent follows it is what OpenRig's first-user runs check. In the first-user test on a Linux VPS the person reached the operator and the goal reached the team's lead, but they were guided to attach a terminal five times, which counts as help. The final package wasn't put through another journey.

#858, #862Link

You don't need every provider a team was designed for: the operator adapts the team to the accounts you have, asks before launching, and passes your goal to the team's lead so you only explain it once. It's guidance the agents follow, checked by first-user runs.

The operator fits the team you pick to the providers you have by writing an adapted copy, shows you the plan and launches only on your yes. It then shows you the team and hands your goal to the team's lead as a task, so the lead starts from that goal instead of asking again.

Guidance for the agents, checked by first-user runs. In the first-user test the person was guided to attach a terminal five times, which counts as help.

#862, #880Link

When you want ongoing work, the operator keeps track of it in OpenRig's workspace, not in your repository. A one-off question is simply answered.

For continuing work, the operator records one mission, and one piece of work under it, in OpenRig's workspace rather than in your repository. A question just gets an answer.

Guidance for the agents, checked by first-user runs.

#865Link

Whether setup finishes ready, incomplete or as a dry run, it ends by telling you how to reach the operator.

rig setup prints how to reach the operator after ready, incomplete and dry-run results.

#859, #886Link

After install, the agent that installed OpenRig opens the kernel's dashboard, advisor and operator in a new terminal space, so you can see them without disturbing its own session. It's guidance that agent follows, and in the first-user test the person still needed help attaching terminals.

After installing, the agent opens a new terminal space with the kernel's TUI, advisor and operator, using herdr, then cmux, then a plain terminal window, without taking over its own terminal.

This is guidance for the installing agent. In the first-user test the person was still guided to attach a terminal five times, which counts as help.

#821Link

If you work from the repository, an optional script checks for Node and npm, installs OpenRig and runs setup, stopping at the first failure. It isn't in the npm package and isn't documented yet.

The repository has an optional scripts/install.sh that checks for Node and npm, runs npm install -g @openrig/cli, runs the installed Node.js and SQLite check, then rig setup --dry-run and rig setup, and stops at the first failed step.

It isn't part of the npm package and isn't documented yet.

#832, #841, #853Link

After upgrading the CLI, restart the daemon so it actually runs the new version. On that first start it also installs the updated openrig-core plugin, which your agents pick up the next time they launch.

Restart the daemon after upgrading the CLI: run rig daemon stop, then rig daemon start. The running daemon keeps its old build until it restarts, and on its first start it installs the updated bundled openrig-core plugin, which running agents pick up when they next launch.

#685, #829Link

The kernel's operator is the agent that installs and runs teams for you, so kernel agents now launch with the broad permissions that job needs, and Codex runs there without a sandbox. If you'd rather keep the old behaviour, set an explicit permission choice.

Agents in the built-in kernel rig launch with wider permissions by default, so its operator can install and run teams for you. Claude Code runs in acceptEdits with an allow list for file tools, reads under your home folder and operational commands such as rig, tmux, npm, git, ssh and curl; Codex runs unsandboxed with approvals off. rig seat status reports the source as the kernel operational default.

Applies only when no explicit permission choice, member or rig policy, or (for Codex) named profile is set; set one to keep the previous behaviour. Your ask and deny rules still apply to Claude Code.

#820, #858Link

Ask your coding agent to install OpenRig and it now hands your goal and project folder to the operator, and leaves the kernel running, instead of building the project itself. Part of that guidance lives on openrig.dev's install page.

An agent that installs OpenRig for you now keeps the kernel running and passes your goal and project folder to the operator, instead of building the project itself.

Part of the guidance for an agent finishing an install is on openrig.dev's install page, not in the package.

#873Link

When the operator suggests the workshop, it checks the latest pinned version instead of trusting a cached copy that may be older. This is a text change, and a fresh first-user run hasn't yet confirmed it finds the current workshop.

When the operator offers the workshop, it reads the workshop's current pinned version from the registry's raw file, because a cached copy can be older.

A text change, packaged without a new journey run. That a fresh first-user run then finds the current workshop hasn't been reproduced.

#900Link

rig doctor no longer gives a blanket all-clear, so a clean run isn't mistaken for a working setup: it points you to its warnings and says it doesn't check provider logins or agent readiness.

rig doctor no longer ends with "System checks look good." It says there were no failures, to review WARN and SKIP results, and that provider logins and agent readiness aren't checked.

#855Link

Setup shows you what to do next before it asks about permissions, and scripts reading its JSON output get the next steps too.

In rig setup, the guided next steps now come before the permission-policy menu, and --json output gains nextSteps.

#886Link

When setup runs into problems, you get a list of what failed and how to fix each one.

When rig setup finishes with problems, it lists each failed step with its fix.

#842Link

Starting without the kernel now tells you the operator won't be running either, and how to start it later.

rig daemon start --no-kernel and rig start say the operator is skipped too, and how to start it later.

#873Link

Setup offers to show you the kernel before you pick a team, and treats saying no, working over SSH or running headless as fine.

Setup's next steps offer the kernel view before you pick a team, and treat declining, SSH and headless use as valid.

#859Link

Common install snags on Linux are now in the README and getting-started guide: a system Node.js that's too old, npm 11 skipping the install check, and cmux being optional and macOS-only.

The README and getting-started say a Linux distribution's own Node.js can be too old and how to install 22 or 24, that npm 11 may skip the postinstall check, and that cmux is optional and macOS-only.

#839Link

Contributors install exactly the dependency versions in the lockfile, so everyone builds against the same set.

Contributor setup uses npm ci.

#714Link

If you run OpenRig on Linux, the kernel's advisor no longer talks to you as if you're on a Mac. A community contribution.

The kernel's advisor agent no longer assumes you're on macOS.

#770 · thanks @adampogLink

A setup dry run on Linux now reports the Homebrew and cmux steps as skipped, so the preview matches your system. A community contribution.

On Linux, rig setup --dry-run reports the Homebrew and cmux steps as skipped.

#769 · thanks @adampogLink

With dozens of agents running, the daemon checks on all of them in a few batched tmux calls instead of one or more per agent, so it stays responsive as teams grow.

Activity, identity and structural sweeps read tmux in a few batched calls instead of one or more per seat, so large fleets stay responsive.

#293, #309 · thanks @korallisLink

Before a reboot or upgrade, rig restore-check tells you whether a rig would really come back, because it runs the same checks a restore runs, against the snapshot a restore would use.

rig restore-check now checks the real queue store and each seat's selected Claude hooks, and runs the same pre-checks a restore would run against the snapshot it would use. A rig spec it can't locate reads as yellow, not checked, instead of red.

#328, #636, #631 · thanks @dajiaohuangLink

If tmux can't be reached, rig down no longer forgets a rig whose agents might still be running. It says what it couldn't confirm and keeps the record.

rig down keeps a rig it can't confirm is gone. If tmux can't be reached, it says so, keeps the rig record and blocks --delete.

#513 · thanks @Nikhi00718Link

If you're watching an agent in tmux when its session ends, you're detached instead of being switched into another agent's session.

Ending a seat's session detaches any terminal viewing it, instead of switching that terminal to another session.

#187 · thanks @vanducngLink

Before a long-running Claude agent's context is compacted, OpenRig asks it to write a map of what matters and waits for it, and afterwards the agent reads its own map back. It's how an agent picks its work back up after losing most of its working memory.

Managed Claude compaction now asks the seat to write a restore map first, and waits for it before sending /compact, up to 25 minutes for automatic compaction. If no map arrives, that attempt stops instead of compacting an unprepared seat.

Not tested against a real Claude compaction. When no map arrives, automatic compaction stays off for that seat until you run rig compact again.

#610, #633, #645, #591Link

A damaged snapshot no longer stops a restore; OpenRig skips it.

Restore skips damaged snapshots, and picks the newest of snapshots or checkpoints saved in the same second.

#207, #206, #601 · thanks @rudycelekli, @shravansumanthananLink

Seats with similar names, such as dev and dev-2, can't be mixed up when one of them stops, because OpenRig addresses tmux sessions by exact name.

OpenRig addresses tmux sessions by exact name, so a seat whose session ended can't be confused with another whose name starts the same way.

#449, #614, #625, #515 · thanks @rudycelekli, @NishilRathodLink

Agents that take around 20 seconds to start are given the time, instead of being marked as failed.

A seat that becomes ready after about 20 seconds now starts within the 30-second readiness allowance.

#530 · thanks @xiangzuodalaoLink

Work handed between agents goes through a durable queue, and a write that times out can now be checked and retried by its ID without creating the work twice.

rig queue create picks the item's ID before sending and prints it, so after a timeout you can check that exact item and retry with the same ID instead of creating a duplicate. A same-ID retry with a different body warns that the new body wasn't saved.

#495Link

Send work to a seat name with a typo and you get a warning naming the seat you probably meant, instead of a row nobody picks up.

A queue write to a seat that doesn't exist in a known local rig still goes through, with a warning that names the likely typo.

#337 · thanks @rudycelekliLink

You can hand an agent work from your own terminal, without being an agent in a seat.

rig queue create --source works from a plain shell outside a seat, recorded as a self-declared source.

#440 · thanks @rudycelekliLink

OpenRig delivers messages by typing them into each agent's terminal and pressing Enter. It now uses tmux's named Enter key, so messages no longer sit typed but unsent when extended-keys is on.

Typed and pasted text is submitted with tmux's named Enter key, so it no longer sits unsubmitted when extended-keys is on.

#540 · thanks @Totopo27Link

When an agent is stuck at a permission prompt, OpenRig doesn't type over it. It raises one alert to the orchestrator or to you, and the agent's work resumes once the prompt clears.

Work blocked behind a prompt is escalated as one alert to the orchestrator or operator, without typing into the blocked seat, and its wake retries resume once the prompt clears.

#619, #644Link

Agents can't wake themselves, so OpenRig keeps timers that wake parked work later. Those timers now hold even when the work around them is claimed, finished or re-parked.

A watchdog attached to a parked queue row survives the other row's claim, completion or re-park.

#505 · thanks @Vaishnavi220506Link

Before typing into a Claude agent's terminal, OpenRig confirms the native Claude process and the exact conversation it expects. When it can't confirm a resumed conversation, it reports it as unverified instead of claiming it came back.

OpenRig confirms a managed Claude seat behind a shell wrapper or a native install from the native Claude process and its exact saved conversation ID, in restore, readiness and identity checks and in rig seat clear-attention. Acknowledging a seat's attention no longer reports its conversation as resumed without strict proof.

#264, #335, #520, #554, #652, #651 · thanks @dajiaohuangLink

If you've customised Claude's status line, OpenRig leaves it alone.

OpenRig keeps your own Claude status line instead of replacing a custom command in .claude/settings.local.json, and no longer wipes that file when it doesn't parse.

A seat that keeps its own status line doesn't run OpenRig's collector, so its context usage reads as unknown and resume-token capture is skipped.

#497, #500Link

OpenRig follows the conversation each Claude agent is actually in, even after /clear. Shut the team down at night, bring it back in the morning, and each agent returns to the conversation it was really in.

After /clear, rig down and rig up now bring a Claude seat back to its current conversation, not the one from before the clear. At shutdown OpenRig reads the live Claude process's session and saves its current ID.

Shutdown can take slightly longer. A conversation change in the moment between that read and shutdown hasn't been verified.

#658Link

Several Claude agents can run under one login and one config folder and each keep its own conversation. Before, two of them could come back in each other's conversation after a restart.

Claude seats that share a config folder no longer pick up each other's conversations, because a fresh launch records the session ID OpenRig assigned.

Forks still look the session up by name.

#656Link

If you start Claude through a launcher shim, OpenRig now finds the real Claude behind it, so messages and queue wakes get through.

rig send and queue wakes reach a Claude seat whose launcher shim starts the real Claude binary.

#567 · thanks @Coder8124Link

If a Claude agent's startup message is left typed but unsent, OpenRig presses Enter once more and carries on with a warning instead of failing the launch.

OpenRig presses Enter once more when a Claude startup prompt is still visibly staged, and starts the seat with a warning instead of failing the launch.

#598Link

When a Claude agent has used up both of its usage limits, OpenRig shows when it can actually work again.

When both Claude usage limits are used up, provider usage reports the later reset time.

#455 · thanks @rudycelekliLink

Two OpenRig installs can live side by side on one machine, each with its own Codex home, so a test install's Codex conversations stay apart from your main one.

Each OpenRig install can have its own Codex home. Set an absolute CODEX_HOME when you start its daemon, and managed resume uses that home; with it unset, installs still share ~/.codex.

Before upgrading, align a CODEX_HOME set in your shell rc with the daemon's, or a Codex seat may not find an earlier conversation.

#638Link

Codex agents running in their default sandbox can now reach OpenRig's daemon on your machine, so they pick up and hand off queue work like any other agent. OpenRig only adds the network setting when your own Codex config hasn't made a choice.

Codex seats can now reach the local daemon under OpenRig's default workspace-write sandbox, so they can do their queue work. OpenRig turns on network inside the sandbox only when you haven't made your own choice and no managed requirement restricts it.

Not checked with real logins, managed policy bundles or on Linux. To keep it off, set network_access = false under [sandbox_workspace_write] in your Codex config.

#608Link

OpenRig tells whether an agent is idle by reading its screen, and now reads recent Codex versions correctly, so idle Codex agents get their work.

Codex 0.157 and 0.158 seats showing the empty-composer placeholder are recognized as idle, and a busy seat whose status row sits far above the composer isn't misread as idle.

#295 · thanks @korallisLink

Oh My Pi joins Claude, Codex and Pi as a runtime a team can use. Each Oh My Pi agent gets its own home, config, skills and sessions.

A rig spec can declare runtime: omp to run Oh My Pi seats, each with its own home, config, skills and sessions.

No live authenticated session against a real provider was run. rig seat clear-attention can't yet recover an OMP seat after a full restore; use rig up --existing <rig> --fresh <seat> instead.

#35 · thanks @MelonSmasherLink

Pi agents with long launch commands start correctly, instead of having the command cut off by the terminal.

Long Pi launch, fork and resume commands run from a temporary script instead of being cut off by the terminal's line limit.

#212 · thanks @rudycelekliLink

Agents can ask you for a decision in Slack with buttons, up to four questions at once, and the work waits for your tap. A typed reply still works.

A decision sent to a person in Slack can carry one to four questions, each shown as a row of buttons. A typed reply in the thread still works.

A Slack app created from an older manifest must turn on Interactivity by hand, or the buttons do nothing. Tested against a simulated Slack, not a live workspace.

#195 · thanks @sahiljadhav7Link

Agents keep follow-ups about one piece of work in the same Slack thread, and attach their evidence there, including screen recordings and PDFs.

A follow-up can go into an earlier Slack thread, and video and PDF evidence files up to 50 MiB are attached.

Tested against a simulated Slack, not a live workspace.

#155, #298, #305 · thanks @sahiljadhav7, @korallisLink

On a busy queue with Slack connected, each sweep skips work for items with nothing to post, and usage lookups use an index. Both are based on work by a user running their own large setup.

Slack sweeps skip building expensive queue views for items with nothing to post, and each seat's latest usage sample is found through an index instead of by sorting its history. Both are based on korallis and Lee's work in korallis/agent-stack.

On a synthetic 200-row queue the Slack sweep was much faster when few items needed a post, and about 11% slower when none had been posted.

#642, #569 · thanks @korallisLink

Two Slack messages sent at the same moment in different channels both reach their agents.

Slack messages in different channels with the same timestamp are both delivered, and retries search up to 10 pages of history for an earlier post with an unknown outcome.

#452, #395 · thanks @dajiaohuang, @rudycelekliLink

You can open a second TUI on the same install without it taking control away from the first.

A second TUI on the same OpenRig home binds its own control socket and shows its path, instead of taking over the first one's.

#205 · thanks @rudycelekliLink

The TUI copes with a flaky connection to the daemon, and arrow keys work in more terminals.

The TUI's live activity updates back off when the stream keeps dropping and retry when it's slow to open, and arrow keys work in application-cursor mode.

#380, #546, #429 · thanks @rudycelekliLink

OpenRig works by watching every agent's terminal. rig ps --resources now shows what that watching costs your machine, and idle agents are watched less often.

rig ps --resources shows load per CPU, running seats and what transcript capture costs your host. Idle panes are captured less often, and changes to transcripts.lines and transcripts.poll_interval_seconds reach running seats without a daemon restart.

An idle seat's transcript can trail its pane by about 6 seconds. Load average isn't CPU use.

#556, #624, #536 · thanks @rudycelekliLink

When the daemon refuses a request, these commands now fail instead of printing an empty success, so the scripts and agents built on them see the problem.

Commands that used to print an empty or successful result when the daemon refused the request now exit 1 or 2, including rig bootstrap, rig env status, rig plugin list, rig context list, rig specs ls and rig start --all.

#202, #382, #577, #578, #426, #476, #284 · thanks @rudycelekli, @oodadoudouLink

On very large installs, rig health gives a partial answer for the busiest families instead of failing, and names any source it couldn't read.

rig health above 200 families evaluates the 200 busiest and marks the result PARTIAL instead of failing, and a failing health source is named as unavailable while the others still report.

#357, #626Link

Opening a project's execution view no longer makes the daemon wait on Git, and transcripts no longer grow by repeating the same line.

Execution views no longer freeze the daemon while their Git checks run, and a repeated session-boundary line no longer grows a transcript on every capture.

#557, #545 · thanks @rudycelekliLink

The daemon can run on an IPv6 address, and the CLI and host list work with it.

CLI commands, the daemon's own endpoints and rig host list work with an IPv6 daemon host.

#461, #509, #398 · thanks @lab1207, @Totopo27, @rudycelekliLink

When the daemon is slow to answer, rig status and similar commands say it didn't respond, instead of telling you it's stopped.

rig status, rig start and four other commands say when the daemon didn't respond, instead of calling it stopped.

#349, #437, #439 · thanks @Totopo27, @rudycelekliLink

rig ps counts agents stuck at a permission prompt in each rig's attention total, so you can see who's waiting for someone.

rig ps counts a seat stuck at a pane-only permission prompt in the rig's attention total.

#180 · thanks @nvtoan0201-sweLink

rig usage top shows missing usage data as unknown, so it isn't mistaken for an agent that used nothing.

rig usage top lists seats with missing counters as unknown instead of zero.

#582 · thanks @rudycelekliLink

Two agents editing the same mission no longer silently overwrite each other's changes.

rig scope refuses a stale mission edit instead of silently dropping another edit, and refuses a slice that depends on itself.

#339, #286 · thanks @rudycelekliLink

rig daemon stop finishes promptly even while something is still listening to its live events.

rig daemon stop ends open event streams after a short grace period instead of timing out on them.

#324 · thanks @dajiaohuangLink

Each agent in a team can think as hard as its job needs: a planner at high reasoning effort and builders at low, Claude and Codex alike, declared once in the rig spec.

Each seat can have its own reasoning effort. Put effort on a pod member, in a profile's preferences or in an agent's defaults, and OpenRig passes it to Claude as --effort and to Codex as model_reasoning_effort on fresh launch, resume and fork.

OpenRig doesn't check the value, and Pi seats ignore it.

#320, #681 · thanks @shravansumanthananLink

You can check a rig spec anywhere, on a laptop or in CI, without a daemon running, using the same validators the daemon uses.

rig spec validate runs locally, with the same validators the daemon uses, so you can check a spec without a running daemon.

rig spec preflight still needs the daemon.

#566Link

An agent spec can use a plugin from your OpenRig home, wherever that home is.

Agent specs can point at a plugin with openrig-home:plugins/<name>, and built-in agents load openrig-core from a custom OPENRIG_HOME.

#620, #627Link

A rig can start services such as a database alongside its agents, and OpenRig waits until every replica is healthy before treating them as ready.

Service readiness accepts bracketed IPv6 targets and requires every Docker Compose replica to be healthy.

#215, #218 · thanks @rudycelekliLink

An agent joining a project can find the project's intent, context files and skills itself with one command, instead of waiting to be told.

Agents learn the route to your project's context. The onboarding text and bundled skills teach rig context work-install, which lists what the current project declares: its intent, context files and skills.

#679Link

If you want to contribute, your own agents can load a skill that explains how OpenRig is built.

Contributors get architecture maps, a developing-openrig skill and a roadmap.

#282, #539Link

Several agents can work in the same repository and each know its own role, without writing their roles into a shared CLAUDE.md or AGENTS.md.

Kernel seats no longer write their role into a shared CLAUDE.md or AGENTS.md. A startup file can be marked orientation: role, and rig queue whoami --json tells a seat where its role file is.

#562Link

Agents keep talking to the daemon that launched them, even if your shell startup files point OPENRIG_URL or PATH somewhere else. One less way for a seat to end up on the wrong install without anyone noticing.

Your shell startup files no longer change a seat's OpenRig settings. Each launch re-applies the daemon's OPENRIG_URL, OPENRIG_HOME and related settings, and puts the rig that matches the running daemon first on PATH.

For classic Claude launches, a claude alias or function defined only in a nushell rc doesn't resolve, and neither do some older fish setups.

#618Link

When OpenRig can't verify which runtime an agent is using, it says so instead of reporting the agent as stopped.

An agent runtime OpenRig can't verify is reported separately from a stopped agent.

#240Link

A rig with a single agent can be relaunched fresh, even when stopping that agent shut down its tmux server.

A rig's only seat can be relaunched fresh with rig seat launch --fresh --stop, even after stopping it ended the tmux server.

#267Link

When OpenRig restores an older Claude agent and can't tell whether its conversation came back, it keeps the new session and asks for your attention instead of closing it.

If the resume check can't tell whether an older Claude seat's conversation came back, the restore keeps the new session and asks for attention instead of closing it.

#346Link

A launch that times out is reported as an unknown outcome, because the agent may still be starting.

A seat launch that times out reports an unknown outcome instead of a failure.

#191 · thanks @oodadoudouLink

Parked work keeps its wake-up timer when its seat is handed over to a new occupant.

A blocked queue row keeps its park timer through a seat handover, and a rerouted row's periodic timer is retired.

#242 · thanks @korallisLink

Starting several Claude agents at once no longer trips a one-second check: OpenRig now gives Claude five seconds to answer before a managed launch.

Claude's capability check, run before a managed launch with an explicit permission mode, gets five seconds instead of one, which helps when several seats start at once.

A timeout can still refuse the launch.

#271 · thanks @m3ac-AllbrittenJLink

Shut a team down completely and bring it back, and Claude agents running in auto mode take messages again once OpenRig confirms the same Claude process is in each pane. If it can't confirm the conversation came back, it asks you instead of starting a new one.

After a full down and up, a managed Claude seat resumed in auto mode takes ordinary messages again once OpenRig confirms the same Claude process is running in its pane. A resume it can't confirm asks for your attention instead of starting a fresh conversation.

A restore can still report a problem with a seat that works.

#287Link

OpenRig finds a natively installed Claude behind its shell wrapper, including versioned install paths. When it can't see the runtime, messages still go through with a warning.

OpenRig recognizes a native Claude install behind its managed shell wrapper, including versioned install paths. When it can't observe the runtime, ordinary delivery goes ahead with a warning.

#310 · thanks @dmeloLink

Codex agents in an OpenRig team can use providers other than OpenAI.

Codex readiness works with providers other than OpenAI.

#222Link

Removing OpenRig's Codex activity hooks leaves the rest of your Codex configuration as it was.

Removing Codex activity hooks leaves the rest of your Codex config untouched.

#186 · thanks @hobostayLink

Long messages you send to agents from Slack now arrive whole; before, anything past 1,800 characters was lost.

Slack keeps a long message from a registered person whole, where anything past 1,800 characters used to be lost, and a storage error during retries is logged instead of escaping.

Checked with synthetic connections on Linux, not a live Slack test.

#404 · thanks @rudycelekliLink

If you start the daemon on a different port, your other commands now talk to that daemon instead of looking for the default one.

A daemon started with rig daemon start --port is now the one your other local commands talk to.

#266Link

Replacing a proof file swaps in a new file, so a linked artifact somewhere else is no longer overwritten along with it.

rig proof add --replace swaps in a new file, so a symlinked or hard-linked artifact no longer overwrites the other path's contents.

#307Link

A CLI command's deadline now covers the whole response, and a reply cut off partway is reported as an unknown outcome instead of a success.

CLI request deadlines cover the whole response, and a body that fails after its headers is reported as an unknown outcome.

#201 · thanks @rudycelekliLink

Output passed between machines over SSH and rsync, and through Herdr, keeps multi-byte characters such as accents and non-Latin scripts intact.

SSH, rsync and Herdr output keeps UTF-8 intact across chunks.

#230, #241 · thanks @rudycelekliLink

Files OpenRig edits keep their executable bit, so scripts stay runnable.

Atomic file edits keep the executable bit.

#235 · thanks @rudycelekliLink

rig env status tells you when a service's last receipt is stale, so an old result isn't taken as current.

rig env status says when a service receipt is stale.

#232 · thanks @rudycelekliLink

Importing a rig over a stopped one with the same name archives the old rig and tells you how to bring it back.

Importing YAML over a stopped rig with the same name archives the old one and shows its ID and the command to unarchive it.

#196Link

A bundle of agents keeps binary files exactly as they were, so packaged images and other assets arrive intact.

rig bundle create keeps binary files in agent packages intact instead of re-encoding them.

#257Link

Agents joining a team read onboarding text that covers how builds go wrong, and learn that a project, rig or machine can add its own skills.

The onboarding text new seats read now covers both ways a build goes wrong, and the skills router says a project, rig or machine may add its own skills.

#303Link

OpenRig's web UI is now off by default. The terminal UI and the CLI are how you use OpenRig, and both are built so agents can drive them as well as people.

The web UI is off by default. The CLI and the TUI are the supported ways to use OpenRig; the web UI is in maintenance mode.

To turn it back on, run rig config set ui.enabled true, then stop and start the daemon.

#303Link

The daemon now checks which address and which web page a request comes from. Your CLI, TUI, agents, Slack and other OpenRig hosts are unaffected; a custom hostname or a local web app needs one setting.

The daemon checks which address and which web page a request comes from. Nothing changes for the CLI, the TUI, agents, the queue, Slack or other OpenRig hosts; a custom DNS name or proxy domain goes in OPENRIG_ALLOWED_HOSTS, and a local app on another port in OPENRIG_ALLOWED_ORIGINS.

It isn't complete browser isolation, so keep the daemon on loopback or your tailnet. Both settings need a daemon restart.

#358, #372Link

After an upgrade removes the old version, agents still launch, because they use the running version's built-in startup files.

Seats launch after an upgrade removes the old version, using the running version's built-in startup files.

#269 · thanks @m3ac-AllbrittenJLink

Agent process checks give the same answer whatever language your system is set to.

Native process checks no longer depend on your locale.

#239Link

Repeated snapshot attempts no longer leave unusable helper sessions behind.

A newly created snapshot helper is cleaned up when its input target can't be established and its ownership can still be proven, so unusable helpers stop piling up.

#189 · thanks @z4ccLink

Archived rigs no longer get in the way of a live rig with the same seat names, and removing a stale duplicate keeps the live agent's session and queue work.

Archived rigs no longer interfere with seat references, and removing a stale duplicate node keeps another live seat's session and queue work.

#181 · thanks @FarkinellLink

Messages reach a running Claude agent even when OpenRig's managed launch puts a shell wrapper in front of it. A pane that's only a shell is still refused.

rig send reaches a running Claude Code seat launched with an explicit permission mode, even when OpenRig's managed launch leaves a shell wrapper in front of it. A bare shell alone is still refused.

The process checks used synthetic process metadata; an installed Claude send on every platform wasn't demonstrated.

#220 · thanks @dmeloLink

Agents can attach screenshots and other binary evidence to their proof with rig proof add --media, and existing proof isn't overwritten without --replace.

rig proof add refuses binary files given as artifact text and asks for --replace before overwriting. Attach screenshots and other binary evidence with --media.

#177 · thanks @agammann, @korallisLink

Herdr gets hints about which agents are Claude and which are Codex, and a seat missing its startup context is flagged for attention.

Known Claude and Codex runtime hints are passed to Herdr, and a missing fresh startup context or adapter is reported as needing attention.

#106, #107 · thanks @dajiaohuangLink

After a tmux or host restart, launches find the right terminal by name instead of an old pane.

Managed launches after a tmux or host restart keep the named launch target instead of confusing it with an old pane binding.

Actual reboot and power-loss recovery were outside this fix's verification.

#151 · thanks @diaztunjanoLink

rig restore-check looks in the shared-docs folder you configured.

rig restore-check uses the configured shared-docs root.

This doesn't repair every case in #130.

#139 · thanks @jbaehovaLink

When a sweep runs slowly, the daemon no longer piles up overlapping polling work on every tick.

Identity and transcript polling no longer start overlapping work on every tick when a sweep runs slowly.

This prevents piled-up overlap; it isn't a measured overall CPU reduction.

#169 · thanks @korallisLink

OpenRig delivers messages by typing them into a terminal, so it now refuses to type into a pane it can see is a bare shell where an agent should be running. The message isn't run as shell commands.

Message delivery won't type a message into a bare shell when an agent runtime should be running there, so it isn't run as shell commands.

#150Link

Messages from this machine's own agents are recognised as local even when the sender names this host.

A sender qualified with this daemon's own host ID is recognized as a local seat, avoiding false ownership refusals.

#144 · thanks @korallis, @Yi-111-aLink

Claude agents can be pointed at an Anthropic-compatible gateway through OpenRig's provider settings.

ANTHROPIC_BASE_URL can be forwarded through configured provider-auth environment forwarding, so Claude seats can use an Anthropic gateway.

#143 · thanks @FenjuFuLink

Claude usage-limit reset times are read correctly when Claude reports them as numbers.

Numeric Claude rate-limit reset timestamps are accepted.

#108 · thanks @dajiaohuangLink

Codex agents launched through a managed shell wrapper receive messages and queue nudges.

Messages and queue nudges reach a ready Codex seat launched through a managed shell wrapper instead of being refused as a bare shell.

#171Link

Pi agents keep line editing in terminals that report themselves as TERM=dumb.

Pi seats keep line editing with TERM=dumb.

#123 · thanks @shravansumanthananLink

OpenRig reads tmux window details reliably, and tells health it didn't ask for apart from a health check that failed.

tmux window fields with printable separators parse correctly, and health that wasn't requested is no longer reported as a failed read.

#101, #102 · thanks @dajiaohuangLink

A bundled team installs into the project folder you choose and runs from there, so its working directories and files keep working after setup.

Version-2 bundles copy their verified contents into --target and launch from there, so relative working directories and agent references survive after extraction. Without --target, rig up <file>.rigbundle installs into your current directory.

#146Link

In a project with both Claude and Codex agents, one set of shared skills reaches both, and your edited Codex copies are kept.

In mixed Claude and Codex projects, shared skills are also placed where Codex looks for them, and edited Codex skills are kept unless you force an overwrite.

#162 · thanks @a4w-h4yLink

Start with a small team that does one useful thing in your repository: one agent makes a change and a second checks it. Choose two Codex agents, two Claude agents, or a Claude owner with a Codex checker, using accounts you already have.

Three first-project recipes give you a small owner and checker team: two Codex agents (first-project), two Claude Code agents (first-project-claude), or a Claude owner with a Codex checker (first-project-mixed). Use the accounts you already have.

#147Link

The agent setting up OpenRig asks you once whether OpenRig's own commands can run without repeated permission prompts, and changes nothing if you say no.

Agent-guided setup asks once whether to allow OpenRig commands without repeated permission prompts. Yes adds native rig command rules at project scope, or user-wide if you choose, without granting general shell access.

The scope, loading and revocation of these rules weren't yet verified in this release.

#147Link

On machines not set to UTC, OpenRig compares an agent's activity against the real start of its session.

On hosts not set to UTC, identity and context-usage readers compare observations with the real start of a seat's generation.

#124 · thanks @Coder8124Link

OpenRig recognises when a Codex agent is at its conversation prompt and ready for input, including just after a dismissed hook-review panel.

Startup and resume checks recognize Codex's » conversation prompt, including a fresh prompt after a dismissed hook-review panel.

#111 · thanks @dajiaohuangLink

Codex agents with a custom status line are still recognised once their header has scrolled away.

A Codex conversation is recognized when its header has scrolled away and a custom status line puts the model name after other fields.

Recognition only; the separate stale restore warning in #116 isn't repaired here.

#125 · thanks @Hexgunner69, @AummadourLink

Codex agents can be launched from linked Git worktrees.

Codex fresh launches work from linked Git worktrees, resolving the worktree's Git directory instead of treating its .git file as a directory.

#126 · thanks @mgall-ibizdigitalLink

You can open the execution view for any catalogued project by naming it, not only for the default workspace.

rig view show execution reads a catalogued project's execution view when you name its --project and --mission.

It doesn't infer the project from your current directory.

#105 · thanks @dajiaohuangLink

The bundled Vault skill loads cleanly, and shipped skills are checked for valid headers.

The bundled Vault skill has valid frontmatter, with a check for shipped skill headers.

#115Link

The help guide is written for your agent: ask it to run rig context get help and it works through environment checks, setup problems and permissions itself.

One help path: ask your agent to read rig context get help for environment checks, setup and restart symptoms, permissions, instance layout and escalation. If rig can't run, the same guide is online at openrig.dev/help/agents.

#113Link

Every pull request now runs eight test jobs, including a scenario with a deliberately planted lost-work failure that the checker has to catch.

Pull requests now run eight test jobs, including an installed queue-durability scenario with a deliberately planted lost-baton failure that a checker must catch.

It doesn't certify every platform, provider or authenticated agent workflow.

#117Link

Each agent in a team can run under its own audited permission level, such as a locked-down reviewer beside a builder with full bypass, set for its future launches.

Choose permissions per seat: rig seat set-permissions records an audited choice for that seat's future launches, floor, full_bypass or inherit. Claude modes such as auto are accepted only when the seat's Claude advertises them.

Native enforcement across fresh launch, resume and fork wasn't verified. Status output doesn't prove a mode's effective permissions; check the running session.

#109Link

You can work in an agent's terminal yourself while OpenRig holds that agent's automatic messages in an outbox, so nothing types over you.

A typing guard for seats where you type by hand. It pauses all automatic input to that seat and keeps messages and wakes in an outbox, which you read with rig seat held-messages.

It covers OpenRig's own input paths, not other tools writing directly to the terminal.

#109Link

An optional, experimental classifier can label your agents' stream of observations, using Jev through OpenRouter. It's off unless you turn it on.

An optional classifier seat can have Jev, through OpenRouter, label Rig Stream observations. It's off by default and runs only when the classifier seat runs one foreground command.

Experimental. The labels are advisory, with no demonstrated accuracy, and nothing routes on them.

#109Link

Each Codex agent's tools run in its own app-server instead of one shared between agents.

Codex seats launch with --no-daemon when the installed Codex supports it, so each seat's tools run in its own app-server instead of a shared one.

#77 · thanks @reisalbuquerqueLink

A seat outlives the agent sitting in it: OpenRig tracks which occupant holds a Pi seat and ignores activity reports from an earlier one.

Pi seat activity reports carry the seat's occupant generation, and reports from an earlier or foreign generation are refused instead of being attributed to the seat.

Activity reporting from an installed Pi seat wasn't verified end to end.

#109Link

You can create OpenRig's Slack app in your own workspace from a manifest OpenRig prints offline, before any daemon or token exists.

rig slack manifest prints the Slack app manifest for the app you create in your own workspace, offline, before any daemon or token exists. --url gives Slack's create-app link with the manifest filled in.

Experimental. The setup steps haven't been confirmed against a real app creation.

#109Link

One action in the TUI opens every running agent in a rig as tabs in Herdr.

Open a whole rig in Herdr from the TUI. Every running seat opens in a workspace named after the rig, up to 16 seats per tab.

Check that the rig opened as expected in your Herdr version.

#109Link

Missions and slices created with rig scope no longer trip the readiness check when they have no metadata block.

Missions and slices created with rig scope no longer fail the readiness reader when their manifest has no metadata block.

#91 · thanks @shravansumanthanan, @kainne44Link

OpenRig moves to Node.js 22 or 24. If you're on Node 20, switch Node and reinstall; your data stays put and is upgraded in place.

OpenRig now requires Node.js 22 or 24 and uses better-sqlite3 13. Node 20 is refused with an explanation, and your data stays where it is: the daemon reopens the same database and applies pending migrations in place.

Node 26 and odd-numbered Node versions aren't supported or tested. On Apple silicon, use Node.js 22.

#16 · thanks @jimallenLink

The kernel starter tells you when it's showing a preview, that the runtime is picked for you, and which agents are actually running.

The kernel starter's summary says when it's showing the library preview, explains that the runtime is chosen automatically, and points to the seats actually running.

#109Link