OpenRig v0.6.9

OpenRig 0.6.9

0.6.9 is a quick fix release for Slack, kernel readiness and cross-host communication. A typed answer to a Slack decision is kept, Slack status shows the inbound records waiting to be retried, a kernel that recovered from a failed start reads ready, and a cross-host send or a long chatroom wait no longer reports failure when the work went through. A Slack connection that stops delivering is now caught and replaced, and an alert for a closed row is no longer posted late. Three of its twelve changes came from three outside contributors.

npm install -g @openrig/cli

It is built from main at 4b48ca21 (after #1063). Work merged to main after that point isn't in this release. If something breaks for you, please open an issue.

Before you upgrade

Restart the daemon after upgrading the CLI. The running daemon keeps its old build until it restarts: run rig daemon stop, then rig daemon start. There is one database migration: migration 098 adds an index on (qitem_id, transition_id) to the queue's transition history, and a 0.6.8 daemon still opens the upgraded database (#1043). And the bundled openrig-core plugin stays at version 0.1.8.

Behaviour that changed:

• Scope approval with --workspace. rig scope <tier> approve --workspace <path> now stamps the work tree you named. Before, it reported success while the stamp landed in the daemon's own work tree. If the named workspace has no missions/ folder, approve now refuses instead of stamping the configured one (#997).
• Cross-host sends over http. rig send <session> --host <id> to an http-registered host has a 30-second request budget, plus any --wait-for-idle time, instead of 5 seconds. If the answer doesn't come back, or the connection drops after the request went out, the send reads "Delivery UNCONFIRMED" (failedStep: "remote-outcome-unknown", exit 1) and tells you to check the target with rig capture <session> --host <id> before any resend. Only a host that was never reached reads as unreachable (#1048).
• rig chatroom wait. A long wait keeps waiting through a slow or restarting daemon instead of ending at the first failed poll: poll timeouts, connection refusals, and reset or closed connections are retried until --timeout. The first failure in a run prints one line on stderr. Other errors, including an error answer from the daemon such as a removed rig, still end the wait (#1047).

Highlights

Slack.

• A typed reply to a decision with structured questions is now kept on the row, in humanAnswers. Before, the decision closed with no recorded answer. A typed reply is placed under the first unanswered question and marked as typed, so text that matches an option's ID is never read as clicking that option. The decision still closes, and closing doesn't mean approval (#1045). The messaging-the-human skill says how to read it.
• rig slack status shows how many retained records for inbound messages, reactions and click answers are waiting to be retried; it counts records, not distinct messages. That backlog is kept across restarts, and if it can't be read, status says the count is unknown and why (#1036).
• A Slack alert whose first post failed is kept and retried when the gateway next starts. If its row has closed by then, the alert is no longer posted, and the row says why. Alerts for rows still open, decision-resolved notices and digests still post, and rig slack enable says how many earlier posts wait to be retried (#1051). Before, four alerts for long-closed rows posted after an enable 28 hours later.
• A Slack connection that stops delivering is caught and replaced. On one install, a connection stayed "connected" for an hour while Slack delivered nothing to it, and two button presses were lost. OpenRig now watches Slack's server pings and the echo of its own posts. When either stops, it opens a new connection and then closes the old one, at most once every 5 minutes; Slack's own refresh requests are handled the same way, without the limit. rig slack status adds a Delivery: line beside the socket state (delivering, not yet confirmed, events missing, no server pings, or Socket Mode disabled), with the last automatic reconnect and any held-back one. The connections view shows connected; delivering or connected; delivery not yet confirmed (#1052).

A kernel that recovered reads ready. When a kernel's first start fails and its seats then recover, for example after rig seat continue, rig status now reports it ready, with a separate line naming the earlier failure. Before, it kept reporting bootstrap_failed, and its agent list could show a seat twice (#1044, fixing #1042).

NixOS. Claude Code seats installed from nixpkgs, whose claude is a wrapper around .claude-unwrapped, are recognised as Claude and read running. Before, every one read attention_required, and each rig send warned that the runtime couldn't be established. A seat that already carries an attention marker from an earlier failed launch keeps it until rig seat clear-attention (#1053).

Dependency and install-script changes

• npm dependencies: none added, removed or changed, and the Node requirement is unchanged (node >=22). OpenRig's own version fields in the package files and the lockfile advance to 0.6.9 (#1062).
• Install scripts: unchanged. The package's only lifecycle script is still postinstall: node scripts/check-abi.mjs.
• Database: one migration, 098, adds an index on the queue's transition history (qitem_id, transition_id), so a row's latest transitions are read without sorting its whole history (#1043).

Everything else since 0.6.8

Off by default. The refocus work packet is in this release, off by default; no change unless enabled (#1043).

Docs. The what-changed note, capability map and changelog were written for 0.6.9, and they now say rig launch takes a rig ID, not a rig name (#1063).

How it was tested

• The final package: openrig-cli-0.6.9-4b48ca21.tgz, 4,139 files, SHA-256 d1adf1c08f9fd9c8a8da2113c783f6420c60ec4df76e357e9bbc14aea817af07, built once from 4b48ca21 in a clean environment. Compared file by file with the published 0.6.8 package, 174 files changed, 4 were added (migration 098's compiled files) and none were removed, all traced to the twelve changes. Installed from that exact package, the installed checks passed, including migration 098 and provider-free checks of the changes in #997, #1036, #1047 and #1048.
• The first-user check ran on Linux only. A fresh non-sudo user on Ubuntu, with no display, gave a Claude Code session the website's skill line (npx skills add mvschwarz/openrig --skill rigs) and asked it to set up OpenRig. The agent installed the exact package and started OpenRig, and OpenRig's operator set up a two-agent team, which built and reviewed a small command-line tool: 20 minutes 17 seconds from the ask to finished, reviewed work. The skill also loaded in a new session. It had help: the package came from a local registry instead of npm, Claude Code was installed and signed in beforehand, its first-run screens and folder trust were done as setup, the person answered the one question the agent asked (installing npm packages under their own folder instead of with sudo), and the person approved 10 permission prompts. What it found is under Known issues. It didn't exercise a real Slack button press or typed reply.
• A real Slack decision was checked separately, on macOS, apart from the Linux first-user check above: the same package in an isolated install with no kernel and a test Slack app. The Slack input was real, sent by an agent driving a Slack web client signed in as a person. A button press on a decision was recorded and handed back to the seat that asked, and a typed reply in the decision's thread then reached that seat as a linked message. On a second open decision, a typed answer given instead of pressing a button was recorded as the decision's answer and handed back the same way. It didn't cover the kernel's operator as the asking seat.
• Each change ran the repository's automated tests, merged into the main of its day, before it merged. The tests ran again on the release commit itself and passed, the package tests on macOS and the other checks on Linux.
• Not tested: a first install on macOS or native Windows with this package; Codex, as the person's agent or on a team; the Herdr and Ghostty views and desktop apps; the TUI in a live session; and a first install by a person whose terminal isn't already inside tmux.

Known issues

• The latest first-install check used 0.6.9 on Linux only (Ubuntu, a fresh user, no display, Claude Code only), with the help listed under How it was tested. Install, setup, a two-agent team and reviewed work all ran. macOS was last checked with 0.6.8, and native Windows hasn't been checked. It found the next four items.
• Attach commands can name the wrong tmux server. If the daemon was started from inside tmux on a non-default socket (tmux -L <name>), its sessions live on that server, but the printed tmux attach commands target the default one and report "no sessions". Attach with the same -L <name>.
• A team's own first steps can need your approval. In Claude Code's accept-edits mode, the operator's copy of the starter, the builder's first commands and the reviewer's test runs asked for approval: six prompts in a small task.
• A seat waiting at a permission prompt is silent unless you attach to its terminal. On a machine without a display, that means opening another terminal for each seat.
• A launched team writes into its working folder: its skills, its guidance (CLAUDE.md), .mcp.json, .openrig/, and .claude/settings.local.json with accept-edits as the default mode. Launched into your own project, it changes how your own Claude Code session behaves there: in the check, the person's next session started in accept-edits mode and read the team's guidance as its own.
• Help without a prompt has been checked in a live Claude session for only one selected lifecycle-help command (#927), as in 0.6.8.
• Codex team seats don't yet ask before lifecycle commands such as rig up and rig down. Claude Code team seats do.
• The send gate trusts the latest recorded hook, as in 0.6.8. If a seat's hooks are recorded out of order, a send can be held for a question that's already answered, or let through to one that's waiting.
• A Codex seat whose permission request was approved automatically can still read "needs input" (#896).
• After a restart, rig status shows Kernel: skipped whatever the kernel seats' state. Read them with rig ps --nodes --rig kernel --full.
• rig doctor and rig preflight report a harness you don't use as failed, for example Codex for someone who uses only Claude Code. Only the harnesses your teams use need a login.
• A resumed Claude seat whose session ID changed on resume still can't have its runtime confirmed, on NixOS or elsewhere.
• Slack channel map: replies are matched to a thread by its timestamp alone, missed-message recovery covers the default channel only, and private channels and direct messages aren't supported targets, as in 0.6.8.
• Refocus after compaction hasn't been proven on a long-running install.
• Older issues, as in 0.6.8: the starter's Codex reviewer needs a Codex newer than 0.145; a restore can report a problem with a seat that works (#273); a claude alias defined only in a nushell rc doesn't resolve; after a reboot, start the daemon with rig daemon start and bring your rig back with rig up <name> --existing; the web UI's file preview runs scripts, so preview only files you trust; browser access isn't complete browser isolation; and Codex network inside the sandbox hasn't been checked with real logins, managed policy bundles or on Linux.

Thanks

To the people whose pull requests are in this release: @DeryFerd, @haralez, in their first contribution, and @xecanto.

And to the people whose reports shaped fixes here: @AlexGhanem (#1037), @csaxton171 (#995) and @rickjgardner (#1042).