When a seat sits at a choice prompt and its row came from another host, the alert about it now still reaches someone, and one such row no longer stops the whole pass. The wake ladder used the row's original sender as a local destination for the alert's carrier row; a sender on another host failed local destination validation and threw, aborting the shared prompt pass, and the same choice in the ordinary ladder failed the whole tick. A shared carrier choice now picks an admissible configured operator or the original sender, otherwise the blocked seat itself, at the prompt pass, its consumed-hop continuation, and the ordinary ladder's continuation and operator-floor alert. The carrier is never nudged, the original sender stays as the row's source, and the existing human-alert policy (including explicit-only) is unchanged.
3 files: source (queue-wake-ladder.ts, +13 -6) and tests (+51). No new refusal, error code, timer or setting.
The TUI's terminal button now opens the scope you're looking at: an agent's page opens just that agent, a pod's page gets an "Open terminals ▸ pod <pod>" button, and the rig's page opens the rig. An agent row's term link and the attention card's chat line now open that one seat instead of its whole pod. The daemon gains a seat:<rig>/<logical-id> terminal view beside pod:, built from the rig's own seat list; an unknown or malformed seat gets the existing view_not_found error, and rig terminal open's help lists the pod: and seat: forms.
11 files: daemon terminal view (+18 -1) with its test (+21), TUI render, attention and link styling, CLI help, and TUI tests; +112 -24 in total. No new refusal or error code.
The README, getting-started and quickstart now install and add skills from the current release, v0.7.4, instead of v0.7.3. docs/releases/README.md says it holds the per-release notes for v0.1.12 through v0.6.3 plus v0.6.12, points to CHANGELOG.md and GitHub Releases for later ones, and its release steps match how releases are published now. Shipped skills and the kernel culture no longer route to a skill that isn't shipped: rig-lifecycle points to rig context get help, the kernel culture's restart case points to getting-started's "Incomplete setup and restart", and the dead sibling entries are dropped. Both skill copies stay identical and their digests are updated.
12 files, +28 -56: docs, skill text and the digest file only; no code change.
A queue item created while its recipient sits at a selection prompt now gets its original wake retried once the prompt clears, even after a daemon restart or when an idle hook masked the pane's attention state. A definite no-write prompt refusal arms recovery; the first positive clear can retry the durable failed wake intents, reusing the same row and frozen wake body. Delivered and indeterminate wakes are never re-sent. Each clear pass holds per-row reservations, so overlapping passes can't release each other's rows or re-arm a refusal. For #2219.
3 files: source (queue-repository.ts, startup.ts; +44 -16) and tests (+107 -5). No new refusal, error code, timer or schema change.
Node inventory now reads each node's activity by the node ID it already has, alongside the current session name, instead of resolving the name back to a node, and attention enrichment no longer repeats a hook read whose result was discarded. A newer same-named session on another node can no longer supply this node's activity or attention state. No-session rows and the standalone attention fallback keep their behavior. In one matched measurement (15 rigs, 75 nodes) the change removed 900 SQL calls per command and cut the CLI median from about 1,028 ms to 622 ms; no general speedup is claimed.
3 files: source +6 -5, tests +71 -1. No cache, schema or API change.
Queue wakes from the daemon no longer arrive as "From: <unknown sender>". A wake-ladder retry now names OpenRig (daemon@kernel) as its sender and keeps the row's own source visible in the body ("Row source: <seat>."), and a workflow's first entry wake names the session that started the workflow. Retry timing, caps and admission are unchanged. For #2223.
4 files: source (queue-wake-ladder.ts, workflow-runtime.ts; +7 -2) and tests (+54 -3). No new refusal.
Codex resume identity stays correct when a supported profile or working directory contains spaces. The daemon now reads each foreground Codex process's exact arguments from the OS (Linux's existing /proc sample, bounded macOS KERN_PROCARGS2) instead of splitting flattened ps text, so a valid managed resume isn't rejected and a UUID inside an option value isn't taken for the resumed conversation. Resume and fork proof, restart in place, permission recovery, effort and claim still require exact arguments, and report unknown or unverified when they can't be read. Ordinary sends, queue nudges and watchdog wakes still reach a stable foreground Codex whose arguments can't be read, without treating it as identity proof.
35 files: 9 daemon source files (+286 -52) and 26 tests and helpers (+639 -147). No new public refusal code, migration, dependency or public API change. The macOS argument helper runs once per foreground sample, uncached.
A seat whose model was changed with `rig seat set-model` keeps that model when it's launched from a snapshot restore: restore now reads the seat's one saved model, as the live profile already does, for both the resume and the fresh restore paths, instead of the snapshot's older model. A seat with no saved model still gets the snapshot's. For #2224.
2 files: source and tests (restore-orchestrator.ts and its end-to-end test).
`rig expand` with an explicit effort for a new member now keeps it, instead of silently launching at the default: the expansion route and the expansion spec both carry the member's effort as written, and the canonical RigSpec schema still trims a text effort and ignores any other value with an advisory, as before. No new refusal.
4 files: source +5 -0, tests +58 -0.
`rig chatroom watch --tmux` works for any rig name: the watcher goes to tmux as separate arguments after `--`, with no shell; a final `;` is escaped so tmux doesn't split the command; and the session name is encoded for tmux's format. The command prints the session name tmux reports, since tmux versions differ in how they rewrite characters such as `:` and `.` in a name. Finishes #1415 by @rudycelekli.
2 files: source +23 -4, tests +85 -0.
Co-authored-by: Rudy Celekli <[email protected]>
Per-rig node inventory now reads startup-proof history only for that rig's current nodes, scoped by node identity rather than the events' own rig id, since a node's history can predate its current rig. The per-node fold and the inventory it produces are unchanged, and other callers keep reading all history. In one matched private measurement (75 nodes, 30,000 proof events, 15 rigs) proof rows read fell from 480,000 to 60,000 and the CLI median from about 1,973 ms to 1,135 ms; a single-rig control was slower, so no general speedup is claimed.
3 files: source +10 -5, tests +35 -5.
The nodes inventory route checks that the rig exists with one bound query instead of loading the rig's whole graph and discarding it. A missing rig still returns the same 404, and the inventory and its enrichment are unchanged. In one matched private measurement the route's SQL statements fell from 478 to 401 (1 rig) and from 688 to 583 (15 rigs); no general speedup is claimed.
1 file: +2 -1.
Git over SSH inside a managed seat can now reach the daemon's ssh-agent for a passphrase-protected key: the daemon forwards its own SSH_AUTH_SOCK through the shared launch environment to every managed launch, and Pi and OMP pass it to the agent process. An empty daemon value counts as unset, so a socket only the seat's terminal has stays out. rig-spec.md says the socket is forwarded and how to check it with ssh-add -l. Finishes #1162 by @akushonkamen, for #1159.
5 files: source +7 -1, tests +18 -10, docs +3 -3.
Co-authored-by: akushonkamen <[email protected]>
Context section addresses now ignore headings and code fences inside HTML comment blocks, following CommonMark's comment blocks. Commenting out an old section no longer truncates the section before it, creates a duplicate address, or hides every later section. None of the 245 commented markdown files in our own packs changes.
3 files: source and tests +61 -1.
A slice's mission is now found when the missions root is given with a trailing slash or as a relative path: the slice path is resolved once against the root, and a path outside the root falls back to the main walk as before. Nothing else in scope resolution changes. Finishes #1468 by @rudycelekli.
2 files: source +14 -4, tests +37 -0.
Co-authored-by: Rudy Celekli <[email protected]>
A Claude permission notification whose dialog was never shown no longer leaves the seat marked as needing input until the next `Stop` or `UserPromptSubmit`. The openrig-core plugin now also relays `PostToolBatch`, and a batch settles only its own actor's strictly older permission marks once every tool in it has run, so a real pending prompt from another actor or a later batch is untouched. A Claude Code without `PostToolBatch` behaves as before.
11 files: source +144 -29, tests +431 -2, docs +21 -1.
A scenario that uses a step verb with no runtime binding (`restore`, `mutate` or `policy`) is now rejected when the schema loads, with `UNBOUND_STEP_VERB` guidance, instead of running its earlier steps (which can launch real seats) and then failing partway. `emit` stays separately gated and `seed_regression` stays accepted; the runtime check remains as a floor. Test system only. Three parked library scenarios now refuse at load; none is selected by CI.
4 files: test helper and test +37 -9 approx, docs; +62 -9 total.
`OPENRIG_URL=http://host:7433/` and `http://host:7433` now reach and identify the same daemon. The CLI reads the URL once through one shared reader that trims a trailing slash, so client requests, `rig send`, crash-cart, startup proof and the daemon-lifecycle identity checks all agree. Removing a trailing slash never changes a URL's origin, so the stop identity check still can't match a different daemon. Finishes #1462 by @rudycelekli.
8 files: source +62 -18, tests +169 -0.
Co-authored-by: Rudy Celekli <[email protected]>
`rig host doctor` now checks where a reply addressed to a machine's self-id actually goes, using the same lookup `rig send` uses (the registry id, then a declared `hostId`, then the first matching `hosts.yaml` entry), instead of assuming it reaches the entry being checked. A stale alias that wins over a working entry now shows up in the doctor's output. Routing is unchanged, and the new rows don't change the doctor's exit codes: the failing row appears only when the transport has already failed.
3 files: source +68 -14, tests +94 -0.
Slack alert selection now reads the latest owner-notification episode for each active row in one query, and leaves out episodes already posted before it loads full queue rows, instead of two lookups per active row. Bounded by eligibility, not by count: there is no row cap, so no pending ask is dropped, and queue creation order is unchanged. Open asks keep their posted episodes. A failed transition or receipt read now propagates instead of reading as an empty result, and the backlog seeding when a channel is enabled sees the same episodes. No live Slack or large-backlog timing result is claimed.
4 files: source +64 -15, tests +153 -3.
`rig terminal open ... --session <name>` now reaches the Herdr session the daemon is configured for, and never silently another one. A name that matches the configured session keeps its explicit socket; other names resolve separately with no fallback; Herdr's config home and session paths come from the daemon, not the caller. The resolved endpoint is carried through the CLI's follow and ensure paths too, which earlier stopped at the daemon's RPC. The Linux-only wiring test doesn't run in the macOS daemon CI job.
9 files: source +24 -19, tests +174 -10, docs +19 -4.
`rig edge add --help` no longer says both endpoints must be existing logical IDs. It says only `escalates_to` accepts a same-daemon canonical address that resolves when used, with `review-advisor@coord` as an example, and that cross-host and synthetic targets stay unsupported. Help text only; validation and routing are unchanged. Refs #1772.
1 file: +8 -4.
Scenario test fixtures no longer start a Node process for every tmux command. The fixture's tmux wrapper is now a POSIX shell script that keeps the private socket, the saved PATH and literal arguments, and execs tmux, so its exit codes and signals pass straight through. A new forwarding test covers both an exit and a signal with no Node on the saved PATH. Test helpers only; no product code changes, and no production speedup is claimed.
2 files: test helper +6 -11, tests +33 -1.
A scenario action that sets `send.verify: true` now runs `rig send --verify`, so scenario tests check what they say they check. Before, the adapter dropped the flag and ran an unverified send. False or absent values keep the existing arguments. Test helpers only; no product code changes.
2 files: test helper +2 -2, tests +5 -3.
When work owned by a bound terminal seat (`runtime: terminal`, such as a plain shell) is stuck, the stuck sweep's finding now goes to someone who can act on it instead of becoming the terminal seat's own row. It joins the fallback the sweep already uses for an address with no wake route and for an unclaimed hosted member: the operator seat when it's a person, then the row's creator, then the operator agent, and a terminal seat is never chosen. When none of them can be reached, the finding stays with the terminal seat and says why. The typing guard is unchanged. This covers the stuck sweep only; parked-owner watchdog reminders are separate.
2 files: source +11 -5, tests +34 -0.
A same-conversation account switch no longer leaves a Claude seat stopped when its running executable is outside the daemon's PATH. Before the takeover ends the old process, in-place restore reads the executable the seat is actually running, through the existing native witness, and carries it through the classic and managed resume builders; when it can't be read, launch resolution stays as it is today. The takeover also keeps the selected node identity through the guarded TERM, KILL and respawn instead of resolving a bare pane id again, so it can't act on another seat that holds the same pane id. The guard still checks the bound session, pane and occupant before writing. Config-dir selection and the resume token step are unchanged.
13 files: source +58 -25, tests +54 -6.
A cross-host `rig queue create --verify` now reads its delivery receipt from the destination daemon, so a successful remote create no longer reports a 404 and an indeterminate result. Verification reuses the destination reader that create reconciliation already selects, including the registered HTTP endpoint and its bearer, and a host naming the current daemon stays local. The receipt must match the created item's ID, destination, sender and body, so an older row reached by a reused ID can't read as verified. An unreadable or mismatched receipt stays indeterminate, and neither the create nor the wake is resent.
2 files: source +38 -11, tests +90 -0.
In a task-following view, a departed Codex agent's tile now closes once its composer is confirmed empty. Codex 0.164 draws a model and path status row and then a shortcuts row; the capture reader already recognized that two-row footer, but the cursor-bound reader follow uses accepted only one row, so every Codex tile read as unconfirmed input and stayed. The two readers now share the existing footer boundary. Typed drafts, literal placeholders, moved cursors, menus, incomplete frames and ambiguous captures still keep the tile, and only the viewer closes, never the agent. The same reader feeds delivery's draft-aware and openrig-urgent typing guards, so a truly empty Codex 0.164 composer there can now receive typed delivery.
4 files: source +22 -12, tests +94 -2.
`rig terminal open qitem:<id> --follow` keeps one Herdr workspace following a task: an agent that takes an open obligation in the task joins the view without taking focus, and one whose work there ends loses only its viewer tile after a grace period, with the agent and its conversation left running. An explanation strip says why each tile joined or left. A focused tile is kept briefly for reading, typed or unreadable input keeps its tile, and pins, temporary suppression and an eight-tile limit can be changed on purpose. A failed or incomplete read keeps the previous view; a task with no open obligation retires its follower and keeps the workspace. Following wakes on queue, session and node changes and one-shot deadlines, not by polling.
Qualified on Linux with Herdr 0.9.5 (protocol 22). Other platforms and other view kinds keep ordinary one-shot open. Also fixes the viewer inventory call that Herdr 0.9.5 rejected (`workspace list --json`).
21 files, +1265 -44.
`rig send` now waits up to 60 seconds for its result, on local and HTTP sends, plus any `--wait-for-idle` time. A send that answers after five seconds reports its real outcome instead of "Delivery UNCONFIRMED", which led agents to send the same message again. When there is still no answer, the guidance says a busy agent can hold delivered input off-screen, so an empty pane capture does not prove the message was lost: check with the recipient before sending again or filing the same work as a queue item. Nothing is retried, and no refusal is added.
Refs #2195. The send path's own latency on the reporter's machine is not changed here.
3 files, +57 -29 (source +17 -21, tests +40 -8).
OpenRig's own `rig scope slice create` and `slice move` number slices past 99, and the CLI audit has accepted those folders since 1016, but the daemon's scope audit route, which the web UI's Scope pages read, still required two digits and reported each `100-…` folder as a high naming violation. Both audits now use one shared pattern. The conventions doc also says what a slice move does to proof: a judgment binds the slice's path, the item's text and the policy, so moving or renaming a slice reopens its judged items, `rig proof show` lists them, and the scope audit checks structure, not readiness.
6 files, +47 −4 (source +15 −4, tests +26, docs +6). No new refusals.
The roadmap now lists 0.7.4 as released, with a link to its release and its published title, and points readers to the release notes for what shipped, the experimental and security notes for hosted members, upgrade instructions, credits and the remaining testing gaps. It replaces the 0.7.3 section; "How to help", "Testing" and the backlog sections are unchanged. Text only.
1 file, +4 -10.
The Pi terminal UI example said that whether Pi takes a wake and acts on it hadn't been checked. One native check has now run, on Pi 1.4.0 with OpenRig 0.7.4 and one model: a parked row's wake reached Pi in the same session file and Pi resumed the work, and a handoff reached a second `pi-tui` seat, which picked it up unattended. The first seat's task named the commands, so this shows the wake reaching Pi and Pi acting on it, not Pi choosing to park by itself. The same check found two unsafe cases, now stated as observed: with the default typing guard a wake submits a person's half-typed draft together with the wake, and a send while a Pi dialog such as `/settings` is open types into the dialog. The docs say to run the seat unattended, not where a person also types, and promise no remedy. How Pi takes a wake while it's busy, resume and other Pi versions stay unshown. The launcher is unchanged.
2 files, +14 −8. Text only.
The hosted-members reference described how to serve a hosted member over HTTP behind a tunnel or proxy, with no warning about what that exposes. It now opens with why the feature exists (assistants in a vendor's cloud can only reach a server on the internet) and a note: it's experimental, unsupported and off by default; nothing in OpenRig listens on the internet unless you set it up; serving `rig mcp serve --http` behind your own TLS tunnel or proxy with a token is like opening a port in your firewall, and anyone with the URL and a valid token can act as that member within its grant; treat the token like a password, give the member the narrowest grant, and revoke it when you're done with `rig mcp token revoke <name>`; OpenRig reachable from the internet isn't supported.
1 file, +4. Text only.
A running rig's Overview matched a Specs-library template by name, so a Claude-only kernel could appear to use the dual-runtime template, and a project rig outside the library said "NO RIG SPEC". The Overview now reads the selected local rig's existing `/api/rigs/:id/spec` export and labels it current configuration, not a library template. The existing review renderer supplies topology, configuration and YAML; if preview preparation fails, the actual export stays visible. A read failure no longer substitutes a same-named template, and a remote or undetermined host reads nothing local. The Specs library continues to show reusable templates, and nothing changes in the daemon.
3 files, +192 −53 (source +54 −53, tests +138). No new refusals.
Three things a hosted member is told were misleading in a native test, and the member repeated or acted on each. A hosted member with no wake trigger fell through to the general unroutable teaching, "Fix the address, or register the human with `rig gateway human add`". It now reads that the member is a hosted member with no wake trigger, so nothing can push work to it, and that it reads the queue when its owner next starts a session. The result is still `unroutable` with the same prefix, so the stuck sweep still tells the member's person, and an address no roster lists keeps the general teaching. The member workflow, now `member-workflow/v2` and quoted in `docs/reference/hosted-members.md`, says to describe reach from the grant rather than the tool list, and to close a finished item with `no-follow-on`. `rig_queue_update`'s closure-reason description lists the reasons it takes. No new reason is accepted, and nothing else changes.
7 files, +74 −9 (source +40 −5, tests +33 −3, docs +1 −1). No new refusals.
The terminal-Pi recipe said a community preset with `first_input: true` carries the startup pointer in the seat's first startup text file. That's true only for a file declared with `delivery_hint: send_text`: the first such file is folded into the first input after the identity context. A `.md` file left at the `auto` hint resolves to guidance, which a community seat doesn't take, so a person who wrote the pointer that way got nothing but a launch warning. The bullet now says so.
1 file, +3 −2. Text only.
A plain `runtime: terminal` seat running interactive Pi gets no queue wakes. A community-harness seat is an agent seat to OpenRig, so its wakes are delivered to the pane. This adds a copyable example that runs Pi's terminal UI that way: `docs/reference/community-harness-examples/pi-tui/`, with a `pi-tui` preset (`names_conversation` and `first_input`, no `resume`) and a POSIX sh launcher, a section in `community-harness-presets.md`, and stand-in tests against a fake `pi`.
The launcher, written for Pi 1.4.0 from its source, gives each seat its own Pi agent folder and session folder (a leading `~` in `PI_CODING_AGENT_DIR` is expanded as Pi does), copies the installed `openrig-core` skills it's given at each launch, and starts Pi with `--session-dir`, the session id OpenRig named and the first input passed byte for byte after `--`. On resume it opens the one session file whose first line, read as JSON, has the top-level `type` `session` and that `id`, and starts nothing otherwise, because Pi's own `--session-id` and `--session` can create or pick another session. Whether Pi takes a wake and acts on it, resume, and draft safety haven't been checked with a real Pi; the preset and docs say so. No core code, delivery or terminal behaviour changes.
4 files, +260 −1 (launcher +100, preset +14, docs +24 −1, tests +122). No new refusals.
Registering a remote host makes it visible in topology, but its attention items reach FEED only after `feed.subscriptions.<id>.enabled` is set, and nothing told the person so. After `rig host add` or `rig host pair`, the human-readable next steps now include, after `rig host doctor`, the local command `rig config set feed.subscriptions.<id>.enabled true`, using the registry id as given, dots included. An SSH entry is told that remote FEED needs an HTTP entry and how to pair one. An id that feed settings reserve, such as `progress`, gets a different-id suggestion instead of a command that wouldn't work. Registration still leaves the setting alone, and `--json` still returns its one result. The CLI reference describes the behaviour, and the tests run the printed command through the real `config` command.
4 files, +84 −7 (source +18 −2, tests +49 −5, docs +17). No new refusals.
A terminal member defaults to the `sends-only` typing guard, which holds OpenRig's own notices such as park reminders and watchdog messages. The reference didn't say what happens if someone sets a terminal member to `off`: those notices are typed into whatever the pane is running, and a shell prompt runs each line as a command, From and To lines included, because OpenRig doesn't check a terminal pane's foreground process. `openrig-urgent` and `draft-aware` type only into a recognized empty agent composer, so a shell prompt holds them. The paragraph says this below the modes table and advises keeping the default for a seat that may fall back to a shell.
1 file, +6. Text only.
The terminal-Pi recipe tells Pi to park a CI wait with `--wake-after`, which reads as if the wake will bring Pi back. In a plain `runtime: terminal` seat it doesn't: a parked row's wake isn't typed into Pi, and a handoff to that seat records a failed wake (`failed:terminal-seat`). A native check with Pi 1.4.0 in a real terminal seat showed both. The recipe now says so after its startup pointer, and that the person checks the seat's parked rows (`rig queue whoami --session <seat>` or `rig queue show <id>`) or tells Pi to continue the named row. It makes no claim about community-preset seats and promises no fix.
1 file, +5. Text only.
After `rig attach --self` inside tmux, the session could send with its team address, but a reply to it failed with `transport_unavailable`. The command asked tmux for the session, window and pane joined by newlines and split on them, but tmux writes control characters in that output as `_`, so it returned `name_@2_%2`, the split found no pane, and the attachment silently fell back to the external CLI. It now asks for `#{pane_id} #{window_id} #{session_name}` separated by spaces and reads the two ids by their fixed shapes, leaving the session name as the rest of the line, so names with spaces, underscores or id-like words resolve too. The pane argument is shell-quoted. Outside tmux, a tmux error or unexpected output still gives the external CLI attachment. The tests now render the format the way tmux does, including a real tmux server, and the end-to-end check delivers a reply to the original pane.
3 files, +78 −19 (source +10 −9, tests +68 −10). No new refusals.
A row created before its seat's pane was bound records its wake as unroutable, and the stuck sweep then reported an undelivered wake that nothing retried: the seat spent a turn on a false finding, and the row's own wake was never sent. Now, once that destination has a terminal binding, the sweep delivers the row's own durable wake intent instead of reporting it: it claims the intent, sends, and settles it delivered together with the row's result, so the outbox drain doesn't send the wake again, and it sends nothing when the intent is already sending or delivered. A failed send is still reported on the next tick, a row whose result didn't change is reported as before, the retry ladder and quiet hours are untouched, and an address that still has no binding is reported as before.
2 files, +79 (source +10, tests +69). No new refusals.
rig transcript --tail and rig capture --lines now send the same line count on every path. A count of 0, a negative number or a non-numeric value falls back to the documented default of 20 instead of reaching the daemon as zero, so rig capture --lines 0 shows the default view (20 history lines plus the visible pane) rather than the visible pane alone, and rig transcript --tail 0 returns the default 50 lines. A positive count is unchanged. Over SSH, a value parseInt reads as a positive count is forwarded as typed, so the remote CLI applies the same rule, and the local, cross-host HTTP and SSH paths agree.
6 files, +70 -4 (source +13 -4, tests +57). No new refusals.
Someone submitting a team to openrig.dev/rigs now learns before they submit that the registry's check runs rig bundle check on their folder at the submitted ref with the latest published OpenRig, and that any finding fails it. An exported team has no README of its own, so the publishing guide's submit section and the rig-bundles-and-shareable-artifacts skill now say to add one, declare it in rig.yaml docs, and run rig bundle check at the commit being submitted. The skill gains a short section from an exported team to a submission; its mirror and edge digests are regenerated.
4 files, +29 -2 (docs and skill text only). No behaviour, flag or check changes.
rig terminal open no longer counts a seat as opened when Herdr can't confirm its pane. When Herdr accepts a layout without a tab ID, or its pane list can't confirm a requested seat, that seat is reported as degraded with code pane_unconfirmed and a note to inspect before retrying. Confirmed seats still count, and a partly confirmed open still succeeds; an open with no seat confirmed returns ok false and a nonzero CLI exit. The CLI, the TUI's notices and the desktop failure path name unconfirmed panes separately from skipped seats, and unconfirmed panes get no restart-command report.
Labels are matched honestly. A listed pane counts for one seat at most. When a listed label could belong to more than one seat label (an exact label that is also a prefix of a longer one, or a truncation), those seats are confirmed only when the exact listed labels account for every candidate's seats; otherwise they read unconfirmed, and an undecidable pane never makes a seat read exited. Healthy paging, focus, starting-tab protection and workspace reuse are unchanged. Healthy provider fixtures now return real tab IDs and pane inventories.
15 files, +331 -84 (source +48 -28, tests +270 -56, docs +13). No new refusals; the new structured value is degraded[].code "pane_unconfirmed".
Main's documentation catches up with the accepted 0.7.4 candidate's release text, and its install pins point at the latest published release. The CHANGELOG gains the 0.7.4 section and the capability map its 0.7.4 teaching, both identical to the candidate's; getting-started's reboot troubleshooting row now says a kernel that was already down before the reboot stays down and names rig up kernel --existing, while main's newer rig start --last text stays. README, getting-started and quickstart install pins move from v0.7.0 to v0.7.3, the latest published release; the move to v0.7.4 follows at publication. whats-new stays at main's 0.7.1 note, because the packaged note must name the CLI package's version, and package versions, the lockfile and the packaged-plugin fixture are unchanged.
5 files, +383 -14 (docs only). No behaviour, flag or check changes.
Someone running interactive Pi from a terminal seat, or from a community preset's launcher, gets a written recipe for giving that agent OpenRig's coordination skills, which OpenRig doesn't install for those seats. The new section in the community harness presets guide copies whole skill directories from the installed openrig-core plugin into the seat's Pi agent directory, and puts one startup line in the seat's first turn that names the queue-handoff skill and carries the CI-wait instruction (rig queue block with an external blocker and a wake). Managed Pi seats and Workshop's pinned copies stay on their own routes, and the section says a copied folder and a startup line don't show that Pi discovered or follows the skill.
1 file, +43 (docs only). No behaviour, flag or check changes.
The ntfy and webhook notification adapters now cancel each response body they don't read, right after reading its status, so a slow or streaming endpoint no longer holds a connection open until garbage collection. send() still decides success or failure from the status alone and doesn't wait for the cleanup; a cleanup error is ignored and can't change the result. The new tests use a loopback server that holds the body open and assert that the server sees the response close, plus a rejecting cleanup that leaves the result unchanged, for both adapters and both a 200 and a 503.
3 files, +50 (source +4, tests +46). No new refusals.
The compaction receipt tests no longer fail when a scheduler pause uses up the fixture's 20 ms idle budget. The enforcer and the transport's injected clock read the fixture's stepped clock while the transport's idle deadline read the real Date.now and slept on real timers, so a pause could turn an idle first submission into not_sent before a cancellation assertion expected submitted_unconfirmed. The fixture now shares one clock for Date.now, the injected now() and the transport's sleeps, as production does with real time; the receipt helpers restore only their send spy, and afterEach restores all mocks. The test-layers guide documents the clock boundary. Production code, the 20 ms budget and the assertions are unchanged; real-timer deadline coverage stays in the transport suite.
2 files, +15 -9 (tests +10 -9, docs +5). No production change.
After rig host rename, the TUI's Topology explorer and host pages show the configured name beside the host's identity, for example "Mac mini 2 (mac)". The TUI reads the name the daemon already serves and keeps it separate from the identity used by commands, navigation, row selection and local reads, so a rename stays stable even when the name matches a registered remote host's id. Control and bidirectional-text characters are left out of the label, and the name is cleaned before the default check: the daemon's default name, an absent, blank or matching name, or one that becomes the default after cleaning, shows the identity once. Addresses the remaining local-name item in #2049, following #2052.
8 files, +154 -15 (source +58 -10, tests +85 -5, docs +11). No new refusals.
An explicit rig down now records the stop for a rig whose latest seat sessions are blank rollback sessions left by a failed start, once their tmux targets are confirmed absent, so rig start --last keeps that rig down. Before, rig down marked only exited or detached sessions, and a rolled-back start left the rig eligible for revival. Genuinely live or racing sessions are never marked, and crash recovery for rigs that weren't explicitly stopped is unchanged. The node inventory reports such a recorded stop as stopped on purpose.
rig start --help and getting-started now say which rigs --last brings back: a rig comes back unless every seat it launched was stopped on purpose. A rig taken down with rig down before OpenRig 0.6.12, or whose seats exited or were lost without rig down, counts as last running, and running rig down <rig> once (by id when names are shared) keeps it down. --last never selects the kernel; under --no-kernel its automatic restore is skipped too, and rig up kernel --existing brings it back.
6 files, +83 -7 (source +23 -7, tests +50, docs +10). No new refusals.
rig ps (through --full and the API) now reports periodicSnapshotActive as true only for rigs the periodic snapshot scheduler actually snapshots: not archived, with at least one node whose newest session is running. Stopped, zero-seat and archived rigs read false. The scheduler's running-rig query is exported and shared, so the flag and the scheduler can't disagree; the scheduler's own selection is unchanged. Following Christian Todie's change in cerebral-work/openrig PR57.
3 files, +80 -18. No new refusals.
The queue-handoff skill now says how to wait on something outside the queue, such as CI or a long job: park the row with rig queue block <id> --on external:<what> --wake-after <duration> --continuation "<what resumes>". The row stays yours, reads parked rather than stalled, and the timer wakes you. Text only, with the skill digest regenerated.
2 files, +6 -2.
docs/as-built/test-layers.md now matches scripts/run-pr-scenarios.sh and the CI README: the installed-scenario job starts fifteen fresh containers over nine case options (two baton cases three times each, the refocus-parked effect case three times, and six passing-only cases once each), and the --case and --mode options list them all. Text only.
1 file, +14 -9.
A task preview can report a verified provider terminal mapping, and an owner can ensure a missing viewer through POST /api/terminal/viewer/ensure without opening another whole-team layout. The operation re-derives current membership and the preview precondition, serializes creation per endpoint, reuses the returned pane and terminal pair, and records presentation provenance before any effect; a lost reply is inspected before any repeat, and an uncertain or changed identity stays unconfirmed. It doesn't relayout, close departed viewers, take over control, or start or stop agents. Writable shared tile and recovery attaches add tmux's ignore-size flag (read-only attaches keep -r), and CLI window reuse recognizes both writable attach spellings.
The existing open path keeps its current results and accounting: a stricter accounting of id-less or unconfirmed opens is deferred to its own change, with its consumers updated together. Strict verification applies to the new ensure and lookup paths.
19 files, +651 -27 (source +296 -9, tests +321, docs +34). No new refusals.
An existing stuck-sweep finding now closes only on the source's delivery, pickup or explicit custody evidence. A failed wake becoming unconfirmed, a fresh human-notification post window, an unreadable registry or a larger reporting-age threshold no longer closes a finding just by removing it from a report. Claimed items returned to pending take part in the existing stalled-pickup derivation, and human notifications stay separate from agent wakes.
Older human notices without owner-notification history can close on their item-scoped posted receipt when the recipient is known to be human and unchanged: a destination reroute, or a park whose person changed, needs a new matching notification episode, since the old receipt carries no recipient key. Closure notes name the evidence and record stuck-sweep@system as the actor, keeping finding ownership. Refs #1419, following #1449 and #1811; addresses the false findings reported in #2151.
5 files, +515 -19 (source +91 -8, tests +376, docs +48). No new refusals.
A fresh in-place Claude handover now sends its context packet only after it sees Claude's own drawn input frame on the current screen and the matching launch process, stable across the existing process observations and pane checks. Retained scrollback that looks ready, or a shell prompt line that starts with the same prompt glyph, no longer counts. If that proof doesn't arrive within the existing readiness timeout, the handover stops with a clear message and commits nothing.
Ordinary fresh starts, adopted seats, resume and fork keep their readiness paths, and visible gates and identity conflicts keep their specific results. Refs #1544, following the current-screen qualification in #1553.
6 files, +237 -54 (source +43 -19, tests +157, docs +37). No new refusals.
rig mcp serve with a --port outside 1-65535 (including 0) now prints one warning to stderr and still starts, so an MCP host can connect and list tools; only the daemon calls fail, as before. Nothing goes to stdout, the MCP protocol channel, and no other port is substituted. A non-numeric --port is still refused, and an empty --port keeps using the daemon's own port. This finishes #1416.
3 files, +102 -1 (source +4 -1, tests +98). No new refusals.
Co-authored-by: Rudy Celekli <[email protected]>
A send refused because of the target seat's runtime state (target_runtime_conflict, target_runtime_not_running, target_runtime_unverified) now returns 409, like the other seat-state refusals, instead of 500. When the refusal is a stale bound pane, it ends with the repair: "If the seat was resumed by hand in its session, run: rig reconcile-session <seat>". No text is typed in any of these cases, and rig send --json now exits 1 for them rather than 2.
3 files, +30 -2. No new refusals.
A rig's top-level seat has no delegation parent, so its recovery requests used to fall back to the operator or to itself. The wake ladder and the stuck sweep now honor a declared escalates_to destination, including a seat in another rig on the same daemon, and explain unavailable, ambiguous, self, cycle and unknown-topology fallbacks. Existing delegation parents keep precedence; named targets are kept as topology declarations through import, export, edges and snapshots, and resolved when used. Delivery is one hop per recovery handoff chain, and a consumed recovery uses its own operator continuation without suppressing unrelated work at the same destination.
An already-open recovery keeps its recorded owner even if the originating seat later gains a delegation parent or a changed escalation target; its wake still goes to that owner. Queue waiting and backstop views use the same resolution as delivery.
Implements the scope agreed in #605.
24 files, +1096 -105 (source +364 -90, tests +687, docs +45). No new refusals.
The roadmap now lists 0.7.3 as released, with a link to its release and its three themes (participant foundation, attributed shared-channel conversations, actions and perspective for the primary user), in the same shape as the previous release's section. The active section is removed; "How to help", "Testing" and the backlog sections are unchanged. Text only.
1 file, +3 -9.
Terminal preview and open accept qitem:<id> and show the current owners of that task's active work: pending, in-progress and blocked obligations through explicitly linked descendants, excluding closed predecessors and historical senders. Stopped, missing, external and unresolved owners stay named, and responses say which qitems contributed and report incomplete lineage instead of silently truncating it. Preview and open also return viewDescriptor {kind, name}, so a client can tell a following view from a fixed saved layout.
This derives membership only: no provider terminals are provisioned, no existing workspace is changed, and no agent lifecycle moves. Task views keep the read-only policy of derived views and grant no input. Lineage reads are bounded by explicit row, byte, link and per-record limits, using existing indexes; reaching a limit keeps the known members and marks the view incomplete. No new schema or index.
8 files, +591 -6 (source +261 -6, tests +285, docs +45). No new refusals.
The quickstart's "Learn it in this order" links to the onboarding page and the CLI reference are relative, so a reader opens the version they're reading (GitHub resolves them per ref, and the website rewrites them to the release tag) instead of main. Text only.
1 file, +2 -2.
When daemon start skipped the kernel on purpose, `rig daemon start --wait-for-kernel` now says why and how to bring it back, with the same message `rig start` gives (one shared helper), instead of a timeout header and an unrelated sign-in hint. The exit code stays 1; the timeout and failure states keep their messages.
4 files, +79 -10 (source +20 -10).
The compaction restart fixture gives transport deadlines and the enforcer's simulated sleeps one shared clock (`Date.now` follows the fixture clock), so a simulated wait no longer uses up real preparation time. The spy is restored by the existing cleanup. Test only.
1 file, +2 -0.
The portability report passes explicit `a/` and `b/` diff prefixes to its own `git diff`, so a user's `diff.mnemonicPrefix` setting no longer changes the file names it reports. The test covers both mnemonic-prefix settings with both `core.quotePath` settings. Default-config output is unchanged.
2 files, +4 -3.
The seat-launch environment test compares the paired CLI symlink's target by its canonical path, the same representation the launcher follows, so it passes where the temporary directory resolves through a symlink. Test only.
1 file, +2 -2.
The queue-handoff skill's writing paragraph is followed by its qualification: it's writing guidance, not a delivery filter or length limit. Uncertainty and limits that affect the action stay in. Early references, acknowledgements, requested progress updates and completion returns remain fine, and the sender judges how much context is useful. The skill's digest is regenerated. Text only; no behaviour change.
2 files, +3 -1.
A kernel that was already down before this daemon start now says why it stayed down, and names `rig up kernel --existing` to bring it back. `rig start`, `rig daemon start --wait-for-kernel` and `/api/kernel/status` show that reason; every other skip keeps `kernel rig already managed`, and `rig start` no longer gives the `--no-kernel` explanation for this case.
The reconciler records a detached session right after its transaction commits, before notifying, so a failure in the event bus's own post-commit work can't leave it uncounted.
6 files, +42 -5 (source +12 -4).
The shipped `queue-handoff` skill gains one paragraph on writing a handoff the receiver can act on after one read: open with the request or change that affects their next step, use full words, keep the limits that change that step, put reference IDs after the action, and put the complete request near the start of the task body. The skill's digest is regenerated. Text only; no behaviour change.
2 files, +3 -1.
CLI source comments drop internal tracking references. The daemon's copies of the four shared scope classifier files get the same comment edits, so the CLI and daemon copies stay byte-identical. Comment changes only; no behaviour change.
14 files, +24 -28.
`rig mcp serve --http`'s external grant options take names that say what they do: `--grant-service <url>` and `--grant-service-header-file <path>`, the answer schema `openrig.grant/v1`, and the recorded principal source `grant-service`. An external caller's access and scope use the same wording.
Unchanged: the key and instance patterns, the request and answer fields and statuses, the 503 `grant_authority_unavailable`, every refusal and its code, and the OAuth discovery paths. No old name is kept as an alias. A grant service and an OpenRig on different names fail closed with the existing 503. Rows already recorded keep the principal they hold, because stored principals are read as text and never re-validated.
Restart a running `rig mcp serve --http` together with the daemon. An adapter from before the upgrade keeps working until the grant service's cutover, but its requests are recorded without the grant principal.
14 files, +297 -287 (source and docs +136 -130).
Tests and one old release note use documentation addresses: `192.0.2.10` (RFC 5737), or a tailnet-range example where a test checks that range. One fetch-guard message no longer names an address. No behaviour change.
8 files, +23 -23.
Source comments in the daemon, TUI and UI packages drop internal tracking references, and the regenerated skill and context-pack mirrors follow. Comment and text changes only; no behaviour change. The scope classifier files are unchanged here, so their CLI and daemon copies stay byte-identical.
54 files, +114 -114.
Test fixtures use a synthetic tailnet name in the browser-boundary tests and a synthetic tailnet-range address in a posture test, keeping each test's address class. One fixture uses a non-dated example id. Tests only; no behaviour change.
4 files, +7 -7.
Daemon start brings back a kernel only when its own startup reconcile found that kernel's seats newly detached, as a reboot or crash leaves them. A kernel that was already down before this start, because an earlier start found it down and left it, now reads stale and stays down, with the reason in the boot log. Before, a later start restored it from an old snapshot and offered to resume its old conversations, even months later.
Startup reconcile reports the sessions it marks detached, and kernel boot receives them. A running kernel, one stopped with `rig down kernel`, an unclaimed one and `--no-kernel` are unchanged.
7 files, +70 -16 (source +24 -7).
The changelog and `rig mcp serve`'s help describe the HTTP grant option by what it does: the not-in-this-release line reads "grants from an external grant service for `rig mcp serve --http` (#2096)", and the help text and startup message say each request needs a key the grant service issues. Flag names, behaviour and the OAuth discovery help are unchanged.
2 files, +8 -8.
An OAuth-capable MCP client pointed at `rig mcp serve --http` can now learn how to authenticate from the server itself. With `--oauth-resource <url>` and `--oauth-issuer <url>`, given together and only alongside the external grant service flag, the server answers `GET /.well-known/oauth-protected-resource<resource path>` with the resource, its authorization server, the `openrig.work` scope and header bearers. That happens before the `/mcp` 404 and before any credential or grant check, whatever the Host. Its 401 names that document in `resource_metadata`, and adds `error="invalid_token"` only when a bearer was presented and refused.
Both values must be https, with no userinfo, query or fragment, written exactly as a URL writes them, and the resource path must end in `/mcp`. Anything else is refused at startup, so nothing is rewritten on the way out. Without the two flags, every response is as before. The key, the grant check and the caller's binding are unchanged, and there is no root document, `/mcp` alias or per-tool scheme. The issuer is served exactly as configured, so it should match the authorization server's own issuer byte for byte.
4 files, +186 -11, of which 109 are test lines.
The leak guard's term lists now come from an optional local rules file instead of a file tracked in the repository. Set `OPENRIG_LEAK_GUARD_RULES` (or pass `--rules`) to an absolute path, and every reader uses it through one loader: the leak guard, `build-package.sh`, the context packs, the skill mirror and the control-plane generator. The publishing rules, the frontmatter keys and the internal-section fence stay in the repository unchanged, so mirrored skills are the same.
Without the file, a contributor's `npm run build:package` still works and prints that the term checks were skipped. The release substance gate refuses to run without a rules file, so a release can't pass with the checks silently off. The tracked rules file is removed, and the tests write their own fixture rules.
16 files, +227 -244.
The review page's agents band and roster tell the truth about what a seat holds. Only open rows (pending, claimed, in progress or blocked) count as held, so a seat's handed-off and done rows no longer show as holdings. When the seat has in-progress work, that's what it's doing. A seat reads as parked only on a blocked row that names a blocker, and only when nothing is in progress, so a closed row's leftover `blocked_on` no longer marks it parked.
The roster's "recently holding" complement uses the same set, so a seat whose rows were all handed off still appears, holding nothing. The other readers of `ACTIVE_STATES` (needs-you and the slice phase) are unchanged.
Reported by @ziadeh.
2 files, +37 -10, of which 24 are test lines.
The TUI lists a host's rigs by name again, in the same order as `rig ps`, in the explorer sidebar and the host views. Before, it listed them in the order the daemon's rig summary serves them, which is creation order.
`hydrateSnapshot` sorts each host's rigs once, where the snapshot is built, comparing names the way SQLite's `ORDER BY r.name` does, so uppercase sorts before lowercase as in `rig ps`. The sort is stable, so two rigs with the same name keep their creation order. A drilled-into remote host's rigs are sorted the same way. Pods, seats and the daemon are unchanged.
Reported by @duncanleung.
3 files, +37 -17, of which 29 are test lines.
An assistant connected to an OpenRig team over the MCP server now learns from the connection how to work: its inbox is the items addressed to its seat, a wake only points at the inbox, and it claims an item, does it, then closes it with the answer or hands it on. When an item needs a person's approval first, it keeps the item and asks instead of closing it or acting anyway: it blocks the item on the person who sent it, with the question and a short form of what it will do as the summary, or, for an item from a seat or a shared channel, asks a seat as a new item and blocks on that. The item reads blocked while it waits, and the same item continues after the answer. Both paths are the queue's existing behaviour; the guidance was missing, not the mechanism.
The guidance is one versioned text, member-workflow/v1, joined into the server's MCP instructions, and docs/reference/hosted-members.md quotes it word for word, with a test keeping the two identical. rig_queue_update's blockedOn and rig_queue_list's owned descriptions say the same. A hosted member with no node or session can call rig_whoami and learn the seat it acts as; before, that call failed. A caller connected through an external grant service asks the team for work rather than being a member, so its instructions keep only the shared lines. No new refusal, prompt or required step.
4 files, +154 -10, of which 98 are test lines.
An OpenRig Cloud customer's connected assistant now hands its tasks only to the team it was granted, never to its own caller seat or another customer's caller seat. A customer's `rig_queue_create`, or a revision of one, addressed to a caller-shaped seat answers `out_of_scope` with the same message a customer already gets for a person's or another host's address, and nothing is written.
The change is one line: `customerScope`'s `destination` uses the existing `team` predicate (the grant's member seats minus the caller and any caller-shaped seat) instead of `member`. Self-hosted grants, the customer's show, list and artifact reads, the provenance-tag filter and every other tool are unchanged.
3 files, +32 -6, of which 25 are test lines.
When an agent asks a person a follow-up about a customer's Slack message, the person's Slack post now shows the customer's words and the agent's question without OpenRig's agent-only context: the routing footer, a shared channel's envelope (who wrote, the organization, its readable policy) and the attachments block OpenRig generated (workspace-local paths or transfer-failure diagnostics), in the blocks, the fallback text and long-ask parts alike.
The footer and envelope are cut by their last occurrence, since OpenRig always adds them after the sender's words. The attachments block is cut only by the length inbound recorded when it actually generated one (`slack-attachments:<n>`), at a section boundary, starting with OpenRig's own heading. And the projection runs only while the row's body still matches the digest the gateway recorded at creation (`slack-body:<hex>`): a body a handoff replaced or extended is shown whole, so a person never loses authored words. Look-alikes typed by a customer are kept verbatim. The durable row body, stored files, summary, thread, alert and mention are unchanged; there is no new refusal, setting or migration.
Slack messages received before this change carry no digest and are shown whole when later parked to a person.
3 files, +279 -6, of which 223 are test lines.
When an agent is down at a periodic snapshot tick, the snapshot now keeps that agent's last resume source, so a later `rig launch <rig> <agent>` resumes its conversation instead of coming back `awaiting-decision`.
The snapshot carries the agent's newest session only when it has a resume token and a `resume_if_possible` policy, and one source is chosen before FR-7 and passed into `postLaunchRestore`; the carry is revalidated before any launch effect. It applies only to a named agent's automatic periodic restore: an explicit `--snapshot-id`, `--fresh`, a whole-rig restore and `selectedHistory` keep their meaning, an agent without a token still starts fresh, and 0.7.2 still reads the new field. The idle-shell message points to the command that actually resumes.
Reported by @pr0xc3nt4ur1 in the linked issue, and built by @dajiaohuang, who traced the restore path past the early refusals first.
8 files, +407 -21, of which 290 are test lines.
When an OpenRig Cloud customer hands the team a task and the team later asks a person about it, that person now sees the customer's whole text. Before, a customer could tag its row with OpenRig's own Slack provenance tags, or with the workflow sign-off tag `gate`, so the person-facing view showed only part of the row, or only its summary, while the agent read the whole body.
The MCP server's `rig_queue_create` now drops, for a validated Cloud customer grant only (create and revision), the tags `founder-slack`, `inbound`, `shared-channel` and `gate`, and every `participant:` and `slack-` tag. The customer is identified only from the validated grant. The body, summary, other tags (including `workflow`, `workflow:` and `instance:`) and the request's success are kept; local, stdio and token-file callers and Slack ingestion are unchanged; there is no new refusal.
3 files, +80 -2, of which 71 are test lines, including real daemon routes where the person's render keeps the full body.
An OpenRig Cloud customer's caller seat that was created ahead of time but never launched now works. Before, the MCP HTTP server asked the daemon's `whoami`, which knows only seats that have run, so a pre-created seat was refused with `seat_unavailable` before any tool.
Now, only when `whoami` answers 404, the server reads the daemon's own rig and node lists and serves the seat when exactly one existing node's canonical name equals the seat the Cloud grant names. Two active rigs or two nodes with that name, a malformed rig-list entry, a failed or timed-out read, and any other `whoami` error are refused with the existing `grant_authority_unavailable`; a missing seat or a rig that exists only archived reads `seat_unavailable`. Nothing is created, launched or bound, and the grant, instance and revocation checks, customer scope and `principal:v1` are unchanged. The shared rig-name resolver gains an opt-in strict mode that only this check uses.
5 files, +275 -7, of which 227 are test lines, including a real-daemon test with a created, never-launched caller.
`rig_team`, `rig roster show` and `rig roster find` now say when a hosted member last called the team's MCP server, and the outcome of its latest ring. When there's no evidence, the answer is unknown, never idle. A roster row for a member on another host reads unknown instead of borrowing this host's record.
After a caller's grant authenticates, the MCP HTTP server writes the seat, the grant's name and the time to `mcp-http-presence.json`: mode 0600, beside the token file and never in it, at most once a minute per seat. An unauthenticated or failed request writes nothing, and a failed write never fails the request. The latest ring is read from the member's recent rows. Callers using Cloud grants have no presence.
The hosted-members guide now says a webhook receiver should tolerate a repeated `qitem_id`.
10 files, +207 -13, of which 96 are test lines.
A Pi seat whose saved history cursor isn't one Pi holds, such as an interface event id saved by OpenRig 0.6.11 to 0.7.1, now recovers it at the next start. When Pi refuses the history catch-up, the runner prints that the history catch-up didn't run, keeping that apart from whether the seat resumed, and re-reads the cursor from the tail with the same read-only refresh it already sends after every turn. Nothing is reset or replayed. It no longer prints a runner error and re-sends the same cursor at every restart until a turn completes.
On Pi, an event's own id no longer becomes the saved cursor; an explicit history entry id still does. OMP is unchanged.
Reported by smota in Discussion #2117.
2 files, +48 -2, of which 37 are test lines.
When an agent parks its own ask on the person it asked, OpenRig's Slack side now takes the agent from the row's source. The park's post stays in the ask's thread instead of opening a new top-level post, and a colleague's reply in that thread reaches the agent who asked, attributed to the colleague. The ask stays parked on the person until they answer, and their own answer still resolves it.
A Slack message routed to a person is recorded for Steering and the TUI when it arrives and is no longer posted back to Slack as a new ask carrying OpenRig's routing lines and the shared channel's policy text. If an agent later parks that message on a person, that park is a new ask and is posted as usual.
Threads whose root was recorded under the person before this change keep routing replies to that person.
4 files, +172 -4, of which 153 are test lines.
Main's openrig-core plugin manifests move from 0.1.17 to 0.1.21, and the packaged-plugin baseline fixture moves from 0.7.1 to the published 0.7.2 archive (plugin 0.1.19). The plugin's payload on main has changed since both published 0.7.2 and the 0.7.3 cut, so a build of main now passes the stock packaged-plugin version check instead of failing it.
3 files, +6 -6, metadata only.
With Pi cost reporting turned on, a seat name that once ran Pi and now runs Claude Code or Codex shows its current cost in `rig usage cost` and the TUI's Cost view, not its old Pi estimate: a stored Pi session replaces the seat's entry only when it's newer than the seat's latest context sample. An OpenRouter charge lookup that is retried while unacknowledged outcomes are being re-posted now finishes once the re-post ends, instead of staying pending until the seat's next turn. Both live behind the off-by-default `usage.pi_cost_facts` and `usage.pi_openrouter_charge` settings.
Found by oSquashBlossomo's review in their fork's PR #53.
4 files, +55 -2, of which 34 are test lines.
A hosted member, an outside tool on the team whose roster entry declares a webhook trigger, is now rung when work lands for it. The daemon POSTs a pointer to the row (its id, destination, sender and summary, never its body) to the member's declared webhook, taking credentials only from secret refs. Credentials in the URL are sent as a Basic Authorization header, and no credential appears in any recorded result or posted finding.
An accepted ring is recorded as accepted, not as picked up, on the wake that rang. A daemon restart doesn't ring that same accepted wake again, while a new wake for the row, such as an unblock or a resolve decision, still rings, and a failed ring is retried. A member whose entry declares no trigger stays unroutable, so its person is told, as before. `rig queue create --verify` says the trigger accepted the ring, not that the member picked it up.
14 files, +608 -75, of which 316 are test lines.
Before writing a preset, a community-harness author now checks that the harness answers one prompt on its own, outside OpenRig, using the folder the launcher gives the seat rather than the harness's default one. A provider, model or login problem then shows up in the harness itself instead of costing repeated seat relaunches, which can't fix it. "Write your own" points back to the step.
1 file, +9 -1, text only.
An ask to a registered person's own address, such as `sarah@external`, and a row parked on it now show in NEEDS YOU in the slice, mission and rig reviews (`/api/review/*`, read by the web review pages and the TUI), and the person is no longer listed as an AGENTS row holding that work. The reviews ask the queue's own participant facts, so a registered alias such as `sarah@host` counts too.
A registered shared channel takes correspondence, not decisions: a row sent to or parked on one never appears in NEEDS YOU, whatever its tier, and the channel isn't an AGENTS row. Typed gates such as `external:qa-pass` stay out of NEEDS YOU.
3 files, +110 -17, of which 47 are test lines.
A fresh `rig handover --source fresh` on Claude no longer reports the restore packet delivered just because paste and Enter returned. The daemon reads Claude's composer after Enter. A submitted packet is reported delivered. One still staged gets a single Enter retry on complete staged-text evidence, and if it stays staged the handover fails with `context_delivery_failed` and the successor is unwound. When the composer can't be observed or the result is unclear, the handover succeeds with `restorePacket: { status: "unconfirmed", reason }`.
`rig seat handover` and `rig handover` say the packet was sent but its submission is unconfirmed, give the reason, and say to check the successor before sending the context again. Rebuild handovers and the rest of #1544 are unchanged.
7 files, +213 -16, of which 101 are test lines.
An artifact whose frontmatter opens with `---` but never closes is now treated as malformed frontmatter and excluded from artifact-ready wakes, so an unfinished file no longer wakes an unfiltered artifact pool early. A file that uses a leading `---` line as a horizontal rule is excluded the same way; the option's documentation says so. An edge target with an incomplete header still counts as existing, so a missing-downstream-artifact repair wake isn't manufactured for it.
3 files, +59 -2, of which 52 are test lines.
A delayed older Claude hook no longer replaces the current state in send readiness, attention clearing, review telemetry or the wake scheduler. An old `Stop` arriving after a current limit can no longer permit a wait-for-idle send, and an old `Stop` arriving after a permission prompt can no longer settle that prompt's open wake alert. These readers now use the activity store's existing source order for Claude, as the limit readers do since #1908. Other runtimes keep arrival order.
9 files, +141 -9, of which 113 are test lines.
An agent's reviewed history can now be resumed by node ID. After `rig seat history` returns a history for an exact node, a client asks the startup review for it: the review names the node, the chosen snapshot or history, the planned settings sources and an opaque revision. Apply then rechecks all of them and resumes exactly that conversation through the existing restore engine. If anything changed, it asks for a new review instead of resuming something else, and it never starts a fresh conversation in its place.
The result reports what actually happened. A resume that ran but couldn't be confirmed reports `resume_unconfirmed`, and a permission that can't be resolved reports `permission_unavailable`. Default startup and restore are unchanged for existing callers.
This is the last of #1837's three stages, after #2051 and #2100. 18 files, +1056 -51, of which 621 are test lines.
OpenRig's MCP server now also serves clients on the 2026-07-28 MCP protocol: they don't send `initialize`, carry the version on each request, and may open with `server/discover`. Those clients reach the same tools and durable work loop over stdio and `rig mcp serve --http`. Clients on the 2025 protocol keep working on the same endpoint and process.
It moves from the 1.x SDK and its Express stack to `@modelcontextprotocol/server` 2.4.0, `core` 2.4.0 and `node` 2.1.2 (Apache-2.0). The 1.x SDK will not get the 2026-07-28 protocol. Token-file grants, Cloud grants and customer scope, principal attribution and the loopback Host check stay in front, unchanged.
Behaviour changes every client sees in `tools/list`: each tool's input schema is now advertised as JSON Schema draft 2020-12 (was draft-07), and the `execution.taskSupport: forbidden` field is no longer sent.
7 files, +870 -346: the 36 tool registrations move mechanically to `registerTool`, tests +151, and the lockfile accounts for most of the rest.
When work waits for an address nothing can wake, such as a hosted member that lives outside a terminal or a mistyped address, the stuck sweep now tells a person instead of the address that can't hear it. It tries the operator seat when that's a person, else the row's creator, else the operator agent, and skips any that is unset, the same address, missing or itself unreachable. The finding says why, and that a hosted member sees the work only when it next checks.
A seat that has launched since its wake keeps its own finding. The finding still closes when the work is claimed. Nothing new is refused.
3 files, +91 -1, of which 64 are test lines.
The Claude status-line reference now names the other-login case for rate-limit attribution. A helper Claude started from a seat's shell on a different login is attributed to that seat, like a same-login helper, so its rate limit can hold pending handoffs to every seat in that seat's Claude pool for one retry interval, even when the seat's own login still has room.
Docs only, one file, +5 -2.
When a seat parks a row on a person's own address, such as the `<id>@external` address their inbound Slack rows carry, only a Slack reply written after the current question posted now resolves it. That's the reply-ordering rule legacy human seats (`human@kernel`) already follow. Before this, a registered person's address skipped the check, so an early follow-up could answer a question asked later.
The person's earlier messages still reach the agent as context; only the automatic resume waits for a reply after the question. The resolver uses the queue's existing person-address check, so a registered alias counts too.
2 files, +62 -3, of which +3 -2 is product code.
CI now runs the Linux-only seat-environment test in its own job on pull requests and manual dispatch. The macOS package matrix skips it because it reads `/proc/<pid>/environ`, which left #2041's launch paths untested there. The test also checks that new and existing tmux servers give seats the runtime directory, the disabled session-bus default, and tmux's own terminal identity rather than the daemon parent's.
The job has read-only contents permission and no secrets, and takes about 90 seconds. The required checks are unchanged.
3 files, +61 -2.
A Claude seat that hits a rate limit now reads as at its limit, from Claude Code's typed `StopFailure` hook with `error: rate_limit`. OpenRig never reads the error text. The wake ladder then holds the seat's handoffs for its existing retry interval instead of typing into a stopped seat. Limit events are ordered by when the hook fired, so an older event arriving late doesn't clear or reassert a limit. When seats sharing a Claude home report conflicting limit windows, only the failing seat is held.
Known limit: a helper Claude started from the seat's shell inherits the seat's environment, so its rate-limit hook is attributed to the seat. On the same login that's right, since the quota is the account's. A helper on a different login can hold the seat's handoffs for one retry interval. Binding the hook to Claude's own session id would remove that.
17 files, +533 -47, of which 361 are test lines. The plugin version is unchanged.
`rig queue block <id> --on sarah@external --summary "…" --evidence-ref …` now parks the row and keeps both fields when `sarah` is a registered person, as the same park on `human@kernel` already does. Before this it refused with `summary_evidence_not_persistable`. The check uses the queue's existing person-address predicate, so a registered person's address or alias counts. A bare park on a person still needs nothing new, and other transitions still reject the fields.
2 files, +26 -2.
`rig mcp serve --http` now tells the daemon which grant's caller acted, and the daemon records it beside the rows that caller writes (identity_provenance `principal:v1`, plus a nullable identity_principal column, migration 140). A token-file grant is recorded by its name. A Cloud customer is recorded by id, grant id and version. The principal is sent only to an endpoint proven to be this host's own daemon (its /healthz self id, loopback with no forwarding headers), and recorded only on direct hops. Draft-aware rows keep it.
The header carries non-ASCII names as JSON escapes, so a token-file grant named in any script keeps working. Rows written another way are unchanged.
20 files, +557 -58, of which 315 are test lines.
Carries 0.7.3's capability map, with its `capability-delta-v0.7.3` marker, and the CHANGELOG 0.7.3 section from the release branch to main, so the next release builds on what 0.7.3 teaches. Both files are byte-identical to the 0.7.3 candidate (30a4ea13), and neither had changed on main since the cut. The CHANGELOG section is the candidate's text; the exact published notes are reconciled after publication.
`docs/reference/whats-new.md` waits for the version bump after publication, because a repo test checks that it names the packaged version. Versions, install pins and the plugin manifests also wait for the tag.
2 files, +456 -9, docs only.
Docs only. These are the gaps the 0.7.3 docs check found, fixed on main:
- The Hermes preset and its example no longer say a stopped seat's gateway exits once idle; that hasn't been checked, so they say to check with `ps`.
- The Codex permission envelope in `rig-spec.md` says OpenRig's tests prove the launch flags, not that Codex enforces them, and that an OpenRig older than 0.7.3 launches the seat without the envelope.
- Stopping a community seat says whether the harness's own processes survive isn't exercised, so check them after `rig down`.
- `getting-started.md` and `help.md` say `rig setup` and `rig doctor` run the tmux capture check (`tmux_capture`).
- `docs/as-built/cli-reference.md` lists `rig seat history`.
6 files, +18 -9.
`rig down`, `rig whoami`, `rig ask` and `rig health`, run in a tmux pane without OPENRIG_SESSION_NAME, no longer print "invalid option: @rigged_node_id" and "@rigged_session_name" lines. Those were tmux's own error output from the identity lookup asking for an unset option; the lookup already fell through correctly, and the error still reaches the code that handles it.
The OpenClaw native run found it. It has been there since rig down's own-rig check (#1838, in 0.7.2). CLI only, +21 -1, with a test that runs real tmux against an empty socket directory.
The TUI no longer shows "1 read(s) failed" on a seat whose runtime doesn't report effort, such as a community harness. The daemon's 409 effort_unsupported_runtime is an answer, and the panel already showed it correctly; the page reader just counted it as a failed read too. A real server error still counts.
The OpenClaw native run found it. It has been there since the effort read was added (#1529, in 0.7.2). TUI only, +18 -2, with one test for both the refused and the failing case.
A tool that lives outside a terminal, such as an assistant, a chat bot or a cloud routine, can now be seen as a member of a rig's team. A roster entry can say it's hosted (`"hosted": true`), and `rig roster show` and `find` then report the member as hosted rather than unmatched. `rig_team` lists the rig's hosted members with their authored capabilities and limits, no pane, and activity `unknown`: OpenRig doesn't observe such a member between calls, so it never reads idle. A roster folder or file that can't be read gives a generic `hostedMembersNote`, never an empty list.
The MCP server's instructions now name the loop a member uses on its rows (list, claim, then answer with a resolution or a handoff). Addressing rows to the member and working them under a grant already worked; this adds the team view and the guidance.
9 files, +258 -12. Docs: `docs/reference/hosted-members.md`.
`rig seat history <node>` lists an agent's captured startup histories for an exact node ID and validates a chosen one, in text or JSON. Each entry shows its resume type and saved token state, never the token. Eligible means the engine can attempt that resume, not that the native conversation still exists. A reference that is invalid or no longer current is refused rather than replaced with another history. Codex and Claude are covered first.
It reuses startup's current snapshot lookup, its restore-preview classification and each adapter's resume check, and doesn't launch anything or call a native loader. Existing startup and default restore behaviour are unchanged for valid inputs; malformed imported metadata now reads as unverified instead of crashing discovery.
This is the shared-selector stage of #1837. Applying a chosen history is a separate later change.
10 files, +637 -29, of which 394 are test lines.
`rig mcp serve --http --cloud-grants <url>` takes its grants from OpenRig Cloud instead of the local token file, for a Core instance whose callers are Cloud customers. Each request's customer key is checked against Cloud for this daemon's own instance id. Any answer but active is refused (401, or 503 when Cloud is unavailable), with no fallback to the token file. A customer grant reaches only the queue and artifact tools it names, sees only its own items and the team's questions to it, and every row it receives drops the parties outside its scope. Self-hosted token-file grants are unchanged.
The caller-seat create refusal (78f426ba) is reverted in this merge while it waits on a product decision; it comes back by reverting 0f93cfed. Named limits: the caller-seat read rule rests on Cloud's one-customer-per-rig provisioning contract, not general tenant isolation, and matching the instance is a configuration binding, not cryptographic authentication.
5 files, +765 -50, of which 374 are test lines.
`rig` or `rig tui` started in a terminal that reports 0 rows or columns, such as a detached, headless or just-resizing pane, no longer crashes on its first frame. It skips that frame and draws on the next resize. A size the terminal doesn't report keeps the existing defaults.
The crash has been there since 0.7.2. TUI only, +13 -3, with a stub test at 0 rows and 0 columns.
The Hermes example config and the community-harness presets guide now say that Hermes runs tool commands in its gateway, one per Hermes home, so one per seat with the example launcher. They said "one gateway per machine", which a two-seat run disproved: each seat had its own gateway, home and socket, and stopping one seat left the other running.
Docs only, two files, +5 -2. Hermes resume remains undeclared.
An OpenClaw seat whose local turn was interrupted, and which now shows OpenClaw's "Session … changed while starting work. Retry." frame, reads as needing attention on nodes, `rig ps` and the TUI, with "OpenClaw turn not recovered; inspect the pane before retrying". A send to it still goes through, as today, with an advisory that OpenClaw refused its last local turn and that `rig capture <seat>` shows it.
The recognizer reads only OpenClaw's own footer above the editor, so pasting the error into the input box doesn't produce the diagnosis. It observes; it doesn't repair native records, replay the request or start a fresh conversation. The presets guide recommends Gateway mode for unattended seats. 0.7.3 slice 06, OpenClaw (a).
When a wrapped Codex seat's pane holds a conversation other than the one its verified process owned, the generation-record route now says so: "The Codex conversation in the pane for '<seat>' isn't the one its verified process owned, so no generation record is served." `rig walk` prints this verbatim. Before, the case reused "The occupant binding changed while resolving", which was untrue for it.
Same `record_identity_unverified` code and 409 status; the binding re-checks are unchanged. Follows #2084 (Aschenbath).
A workflow whose done or handoff advances past a declared human park that nobody answered now says so in the existing advisory output and in the same transition note, on both the serial and dependency-graph paths. Nothing is refused: the step still proceeds.
The shipped `messaging-the-human` skill (all three copies) and the resolve nudge say that a response is not consent or authority, and show `--exit waiting --blocked-on <person>` for waiting on a person. Refs #1710.
The community-harness contract in `docs/reference/community-harness-presets.md` now has a test behind each claim with no native proof yet: delivery, refusing a shell or a numbered choice, an unrecognized prompt reading as unknown, no approval relay and no cancel verb, startup files not placed, the preset's own model, named and reported resume never starting a fresh conversation, stop and down leaving a sibling session untouched, and a single launch after an unconfirmed identity.
The survival of processes a harness starts outside its pane is not exercised. Test-only: six daemon test files, +286 -2.
A verified Codex seat launched under a shell or launcher gets its generation record again, so `rig walk` can check consumption instead of always reporting it unverified. The route compares the live pane root with `observedPanePid ?? observedPid`, the rule the current-generation helper already uses for Claude.
For a verdict that records both PIDs, the thread selected under that root must also be the thread resolved for the verified native process. A different Codex conversation started beneath a surviving wrapper is refused with the existing `record_identity_unverified` 409. Legacy verdicts that recorded one PID keep their previous check.
The diagnosis is @fsafey's, in #1799.
`rig export` now writes each pod's saved startup files under that pod, keeping their order, delivery hints, required flags, orientation and `applies_on` selections. Previously those declarations were dropped, so a re-imported rig could start members without their pod guidance. The CLI checks required rig and pod files against the output folder and warns once per missing one.
Files are referenced, not copied: when exporting to another folder, supply them there or import with the original `--rig-root`. Rigs with no saved pod file list keep their existing export behavior. Pod startup actions and member startup blocks remain separate work (#1631 stays open for them).
Daemon tests that use a mocked terminal no longer wait on real 200 ms startup sleeps. The existing `sleep: async () => {}` hook is injected at 14 `StartupOrchestrator` construction sites in 11 test files. No production code, assertion, timeout or concurrency setting changes. In the author's measurement the affected files' wall time fell by 84%.
Test-only, +15 -14.
`rig slack enable` treats the asks already open as seen, so none of them post: enabling never replays a backlog. `rig slack post-open-asks` now brings those asks into Slack through ordinary delivery, at the level each was asked at (quiet hours, digest and the posting floor apply), and says what became of each one: posted, already posted, queued awaiting its receipt, held, below the posting floor, no longer active, superseded, recipient changed, state unavailable, transport failed or uncertain. Running it again reuses each ask's one decision, so a confirmed post isn't repeated; one whose earlier attempt Slack couldn't confirm may post once more, marked as a possible repeat.
State that can't be read is never taken as absent. An unreadable dispatch buffer, seen store or attempt record reads as state unavailable or uncertain, and an attempted re-shown ask whose Slack outcome is unconfirmed, or whose attempt log can't be read, stays in the buffer for its next replay instead of being recorded as not posted. Named limits are in the PR body.
The need came from rakoort's report in #1679.
A sender who wants a busy Codex seat to do separate work is now told to create a queue row (`rig queue create --destination <seat>`) rather than to wait for idle. A saved row keeps the work apart from the short wake typed into the seat, and its state, not the wake, says whether the seat claimed or finished it.
`--wait-for-idle <seconds>` is described as it behaves: if the seat is still busy, or its activity is unknown, when the wait ends, nothing is sent (exit 1, "No text was sent.") and OpenRig keeps nothing to send later.
Text only, in the send advisory, `docs/reference/seat-delivery.md`, `rig send --help` and the MCP send tool: +13 -4.
A spec author can now tell from the docs what a restored seat receives. An exact resume (`rig up <rig> --existing` reopening the saved conversation) types no startup actions and delivers no startup files, `restore` ones included, apart from putting back a missing managed guidance block. `restore` items apply when a seat comes back without its earlier conversation: a resume that falls back to a fresh one, or a retried start.
The startup guide also says not to rename a managed Claude seat. OpenRig starts every Claude seat with `--name <session>`, and context usage, managed compaction and input-box recognition read the seat by that name, so a startup `/rename` breaks them until the next resume.
Docs only: `agent-startup-guide.md` and `rig-spec.md`, +12 -5.
`rig capture <seat> --readable` (or `--size WxH`) reads a seat whose pane is too small to read. It resizes the seat's window for the read and gives it back afterwards, through the same capture path.
The resize joins #2065's window pin record, so a web terminal opening during the read keeps its own pin, and the size is put back only by the last live holder. A pin left behind by a crash is repaired by the next capture. Nothing resizes without a written record, and one 8 s budget per request bounds a `--rig` or `--pod` fan-out (the CLI waits 15 s); after it runs out, seats read as they are, with a reason.
The cost: the seat's TUI redraws twice, and a viewer sees the resize.
Someone running the TUI inside cmux who uses a rig's `term ▸` link or **Open terminals** now gets the view as a new cmux workspace, the same result as `rig terminal open <view> --provider cmux`. Before, the TUI always ran `--window`, which never reaches cmux.
Detection needs `CMUX_SOCKET_PATH` and `CMUX_SURFACE_ID`, which the daemon's own environment scrubs, so a shared TUI in the daemon's tmux isn't read as cmux. Herdr or Rex inside cmux keep their view. A cmux preview sends no width, so the kernel view's plan matches its open, and a refused cmux socket names cmux's Automation socket mode. Outside cmux, nothing changes. Refs #1069.
A person whose tmux crashes on `capture-pane -p` now learns it from `rig doctor` (a `tmux_capture` failure) and `rig setup` (its tmux step), with tmux's own error, why it matters and the fix. Before, every seat failed at launch with "server exited unexpectedly".
The check runs the getting-started guide's existing command on a throwaway socket with no config, so a person's own sessions are never touched. Every command is bounded, and the throwaway server always gets a cleanup attempt. A server that won't start reads as not checked, not as a failure. There's no minimum tmux version. Refs #980.
The agent startup guide gains one table: what a seat is saved to use at its next launch, what the running seat actually has, and the action that brings a saved change to it, for model, reasoning effort, permissions, working directory, startup files and skills, and tools. Without live evidence it says unknown or not verified, never the saved value.
The quickstart gains a reading order for newcomers: how OpenRig works, first use, `rig <command> --help`, then the CLI reference.
The A2A walkthrough now fixes the five problems a cold read found. Start the sample peer yourself in a separate terminal (its address exists only while it runs); fetch the pinned sample commit; when `A2A_TEXT` is unset, the row body becomes the peer's message verbatim; the example asks for an exact reply; and a worker is woken with `rig send`, or by removing `--no-nudge` to get the normal queue wake.
No new interoperability claim is made.
The Slack setup guide now says that messages routed to the same continuing agent conversation can use that conversation's earlier context, whoever sent them. A queue row records who sent a message and which seat owns it; it doesn't start a separate agent conversation.
If people need separate conversations, route them to separate seats (`--inbound` names the seat a channel's new messages reach). Separate channels help only when their routing also keeps the conversations separate. A conversation shared on purpose is fine.
With a shared channel registered and no person, OpenRig records an act on the channel's ask as the person at the terminal (`human@host`). The Feed now serves that same actor on a channel's ask or a row parked on one, so the TUI's label, its success notice and the record agree.
A request that names a shared channel as the actor, without the terminal's primary-user authority, is now refused for drop, hold, route, handoff and annotate, as it already was for answer, approve, deny and resolve. Nothing is recorded. With the authority, a channel claim is replaced by the primary user for every verb, as before. Agents act as their own seat, so their routing is unchanged.
Left as is: if `participants.yaml` can't be read, no shared channel is known, so only asks and replies from before the file broke are exposed. The remedy is repairing the file.
The hermetic test helper no longer reports cleanup complete while its private tmux server's pane children can still write to, or recreate, the scratch HOME.
It records the server's panes and their existing descendants before the signal, waits a bounded 2 s without signalling any other process, then removes the root. An unknown process identity or a timeout keeps the fixture, and a failed cleanup stays failed on later calls. The new tests keep their own startup under teardown, and a repeated hangup no longer ends the fixture child before its final write. Test layer only; no production code changes.
`rig down` now names every community-harness seat whose pane it stopped: "Pane stopped: <seats>. A community harness's own processes may keep running after its pane; see its preset's limits." It also reports them in a new optional `paneOnly` JSON field. Before, a Hermes gateway that outlived its pane was silent.
OpenRig still stops only the pane, and only seats launched for a community harness are named, not a built-in runtime or a free-text namesake. Part of 0.7.3's Hermes work (slice 07).
This reverts #1345, the native Claude version-label witness, on main. Every release since 0.7.0 has shipped with it reverted, so main now matches what ships, and a release cut no longer needs its own hand-made inverse of it.
All nine files are patch-identical to the inverse in published 0.7.2. The two conflicts are resolved to keep every later change to claude-code-adapter.ts and startup.ts. Nobody running a published release loses anything. Re-enabling it later is a revert of this revert, once its native qualification (#86) answers.
The community-harness presets guide now says what a contributor's harness gets from OpenRig, capability by capability: launch, delivery, identity, resume, activity, attention, approval, cancel and transport. Each is marked supported, when declared, partly or no, and each says what the person sees instead. Anything unsupported reads as not known, never idle or ready.
It adds a five-step walk-through for writing your own preset over the Cursor, OpenClaw and Hermes examples, and the promotion test. Promotion to a built-in runtime is decided by the OpenRig maintainers, on evidence from OpenRig's own testing. Passing the checks isn't automatic promotion or a promise of upstream support.
After `rig slack channel-map set` or `remove`, the CLI now says a running connector picks up the change at a daemon restart (`rig daemon stop`, then `rig daemon start`). It also says not to use `rig slack disable` then `rig slack enable` for it, because enabling marks alerts still waiting to be posted as already seen. The old hint offered both as equal choices.
This matches the Slack setup guide and the known-issue line. Live reload is not part of this change.
Eight `rig queue` verbs take the actor from the seat's own identity (`OPENRIG_SESSION_NAME`) and ignore their deprecated `--actor`, `--from`, `--destination` or `--sender` flag. When `OPENRIG_SESSION_NAME` was unset, they said "--<flag> is required", which sent an agent to a flag that does nothing. They now say `OPENRIG_SESSION_NAME` is not set, give an example of setting it, and say the flag is ignored.
The two flags that are honoured, `create --source` and `whoami --session`, keep their message. How an actor is identified doesn't change.
## What a user gets
Applying a pod spec, launching a materialized member, or retrying a failed first start can still block the daemon while resolving profiles, even though preflight already uses a worker. These paths now await the existing profile resolver worker, so a slow skill scan or catalog read can leave the request thread available.
An apply reuses one lazy worker across members, without a scan cache: a later member still reads changes made by an earlier member's startup. Standalone launches and retries use a short-lived worker. Refs #1653, building on the preflight work in #1759 and #1873.
Worker rejections become member configuration failures. When every member fails, apply follows its existing service rollback and generation restoration. A materialized member returns a failed result; first-start retry refuses before changing retained seat/session state.
## How you verified it
Source: `1adc689a5797e23e4a4b0447c3ca9000e069b893`, based on `4e4cba36f9f454e927e9bd508f299bd09cc68886`.
- Three launch-path regressions failed against the original instantiator at the health/FIFO assertion. The test requires the FIFO to remain blocked when HTTP health responds, then checks the selected skill reaches projection. It also checks fresh reads and dependency order between members.
- Four worker-fault cases failed before the rejection handling: apply skipped service rollback, while materialized launch and retry threw. They now verify rollback, restoration of the replaced generation, and preservation of retained seat/session state. The complete worker file passes all 16 tests.
- Native Linux verification passed `npm run lint` and all 91 tests in `profile-resolution-worker.test.ts`, `spec-library-starters.test.ts`, `claude-activity-hook-delivery.test.ts`, and `rig-added-seat-culture.test.ts` (four files, no failures or skips). The tested staged tree matches this commit: `67bab58ce12b7019a300dadbe81b7dc5cf3f8d74`.
- The committed native Linux checkout passed `npm run build`, `npm run test:repo`, and the host-mode `up-relaunch-restores-a-two-seat-team.yaml` scenario (1/1). The scenario starts two stub members, stops them, and starts them again with the expected recorded membership and state.
- [Final PR CI](https://github.com/mvschwarz/openrig/actions/runs/40276062989) is still running. Its results will be added when the complete package suites finish.
- The staged portability report found no matching machine-specific values; the PR portability job also passed.
An initial full daemon run from a Windows-mounted WSL checkout was stopped after a file-mode mismatch and two timeout failures. The mode mismatch and preflight timeout reproduced with the base production code; the culture test passed individually on the base and initial async implementation. The first host-scenario attempt from that checkout also exceeded daemon startup readiness before reaching any scenario assertion; it passed after moving the same source to native Linux. The native Linux tests above use the existing assertions and deadlines. The interrupted run is not counted as a complete suite pass.
## Anything you were unsure about
The responsiveness regression uses the real instantiator and SQLite with a simulated runtime. The scenario DSL has no concurrent health assertion or filesystem gate, so the existing worker-test FIFO fixture exercises the blocking condition directly; the separate two-seat scenario checks CLI/daemon/tmux lifecycle plumbing. Native Claude Code/Codex behavior and other synchronous startup work are not established by these tests.
Worker creation and copying the resolution context add some overhead. The existing deleted-process-cwd fallback remains synchronous. No whole-daemon latency benchmark is claimed.
- [x] One concern per PR; no version bump; no `CHANGELOG.md` edit
- [x] Tests added or updated where the change is testable
- [x] I listed the checks I ran, their results, and any checks I could not run
<!-- This is an auto-generated comment: release notes by coderabbit.ai -->
<!-- coderabbit-ai-generated:v1 -->
## Summary by CodeRabbit
* **Improvements**
* Health requests remain responsive while profiles are being resolved during member launches, materialized launches, and first-start retries.
* Profile changes made during earlier members’ startup are picked up when resolving later members.
* **Bug Fixes**
* Profile resolution failures are reported through the existing launch and retry failure handling, without launching affected members or leaving altered rig or session state.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The CLI reference now lists the flags these commands actually take. `rig provider precheck` and `rig provider switch` gain `--token-file` and `--stored-login`, and `rig seat set-permissions` gains `--rules`, `--codex-permissions` and `--codex-profile`. None is marked required any more, because each command takes one of several.
The reference was regenerated at main by the docs-desk generator, not hand-edited. It changed exactly these three rows and the header's source commit and counts. `--token-file`, `--stored-login` and `--rules` shipped in 0.7.2; `--codex-permissions` and `--codex-profile` are main only.
Main's capability map now teaches 0.7.2, the same text the published v0.7.2 map carries. Before, main still read v0.7.1, because 0.7.2's map was written on the release line only.
The 0.7.2 map commit is ported unchanged. Two lines that main's default-person change made wrong are corrected: the last escalation step goes to the default person, or the only one registered, and reaches nobody when several are registered with no default. A workflow's human step points to `rig gateway default <id>`, with `workspace.operator_seat_name` still read first.
After someone watches a seat in the web terminal and closes it, the seat's window gets its normal size back in Herdr, `tmux attach` or the operator's own terminal. Before, it stayed at the browser's size, so a native client saw narrow text with a dotted background around it.
The broker pins and gives back the window by its id (`@N`). It records the prior `window-size` and the brokers holding the pin on the window, in `@openrig-window-size-prior`. The last live holder gives the window back. A pin whose holders are gone, after a daemon restart or crash, is given back by the next broker, and a window that no longer lists this broker, such as one a restarted tmux server reused, is left alone. Every way the broker lets go gives the sizing back before the registry drops it. `rig capture`'s small-pane hint now also says how to unset the window's own size.
Not covered: a browser that closes while the daemon is down (the window is repaired on its next visit, or by hand), and two brokers updating the record at the same moment.
On a fresh install with no one registered, the notice digest's skip reason now says "no person is registered" instead of "the human registry can't be read".
The registry loader reports "no fragments and nothing projected" as a refusal marked `noHumans`. The flush now checks that before treating the result as unreadable. A registry that genuinely can't be read is still reported as such, and dispatch is unchanged. The test uses a real fresh home through the read-only loader.
Follows #2063 (thanks to @Coder8124 for the skip reasons). Part of #800.
The shared `--workspace` help now says what the commands do since #1093: `slice create` and `approve` refuse when the named workspace's tree is missing, and `mission create` refuses a path that isn't an existing directory and otherwise creates the missions tree inside it. Read commands keep the fallback to the configured root.
Text only; no behaviour change.
The person at the terminal, the primary user, can look at a colleague's queue in the TUI and act on what that colleague was asked. The record keeps both identities: who acted and who was asked. Viewing someone's queue is never acting as them.
- `whose <person|all|default>` chooses whose asks the Feed shows, and its first line names whose queue it is and who acts. With a chosen default person the TUI opens on that person's Feed; otherwise it opens on the topology, as before.
- Acts on someone else's ask (approve, answer, or resolve a row parked on them) are recorded as the primary user, with the person asked in the audit notes and the transition ("by mike@external, the primary user at the terminal, on sarah@external's ask").
- A registered person without the primary user's authority still can't settle another person's ask, pending or parked; that's refused with answer_not_recorded and nothing changes.
- The authority is honored only on a Mission Control request with no seat identity header, which is how the TUI calls the daemon. Seats and the CLI keep their own identity. This is the existing trusted-network distinction, not authentication.
- A registered shared channel never acts: with no one registered, a terminal act on a channel's ask is recorded as human@host with the operator's words; a channel's own answer, approve, deny or resolve is refused before any change; and a customer's message in the thread is never taken as an existing answer.
- Otherwise, with no one registered, the Feed and its acts are as before.
The primary user is #1992's default person, or the only registered person; with several people and none chosen, acts record human@host. `GET /api/attention?view=` filters the Feed's person items and returns a `perspective` block, and delivered updates follow the same view.
On main after #1992, #2061 and #1998, resolveParked keeps the typed external:, fold: and auth: gates and folds #2061's asked-person check into asActor, which refuses another registered person the same way and still lets the primary user act. A typed gate has no asked person, so a primary-user resolve keeps the gate's note.
Guidance is in docs/reference/gateway-participants.md ("In the TUI: whose queue, and who acts"), with upgrade and rollback lines. No new schema, dependency, setting or route.
When the notice digest sends nothing, the watchdog's skip reason now says why instead of "nothing to flush":
- the person registry can't be read;
- no person is registered;
- every item is held for quiet hours;
- notices wait because several people are registered and none is the default;
- dispatch failed before anything was enqueued.
`runDeliveryDigestFlush` returns an optional `idleReason` only when it dispatched nothing, and the watchdog policy uses it as the skip reason. Dispatch itself is unchanged. A real-SQLite test covers each reason.
Part of #800.
`rig scope --workspace <proj> mission create <name>` and `slice create` no longer fall back to the global `workspace.slices_root` when the named workspace can't be used. They stop with an error and write nothing.
- `mission create` with a workspace that doesn't exist, or a workspace path that is a file, is refused, so a mistyped `--workspace` (or `OPENRIG_WORK_ROOT`) doesn't start a new tree there. The configured root isn't used.
- `slice create` refuses the fallback when the named workspace has no missions tree, because the mission it adds to must be in the tree you named.
- Unchanged from #1430: inside an existing workspace, a project's first mission goes to its declared `missions.root`, else `<proj>/missions/`, created if missing, with the same advisories, and reads resolve the declared root the same way.
#1430's tests that expected `mission create` to create a missing named workspace now expect the refusal, as does the workspace-is-a-file case; a new case covers `slice create`.
Refs #70.
A registered shared channel lets people who aren't registered, such as a customer, talk to a seat without registering each of them.
- In: an unregistered Slack sender is admitted only in a registered shared channel's own Slack channel, as that channel participant (`acme-customers@external`), including with no registered person at all. The seat's row carries a labelled block, last after the message: the channel, its organization and groups, who actually wrote (marked as not a registered person), and the channel's effective policy. It's tagged `participant:<id>`, `shared-channel` and `slack-sender:<user>`. A registered person writing there stays themselves.
- Correspondence by construction: a message admitted as a channel never becomes an answer, never closes or resumes an ask (even one addressed to the channel), and a click there records nothing.
- Back: a registered shared channel is a valid queue destination. A row to it posts as a notice, whatever its intent. An update with `--reply-to` lands in the customer's thread, and so does a later one; posts to a channel mention nobody. An ask to a channel is accepted with an advisory that nothing there will answer or close it, and its questions show as a list without buttons.
One participant per vetted channel, from #1992's participant file; no customer is registered and no second store is added. Admission fails closed: an unreadable participant file admits no channel senders, and a broken person registry still refuses everyone. Policy is readable context in the row; nothing enforces it.
Tests cover admission, channel-only setups, never settling anything, and the way back through the real Slack wire with a fake transport.
A registered host ID containing dots, such as `mac.local`, can now be enabled with `rig config set feed.subscriptions.mac.local.enabled true`. The host registry already accepted such IDs, but both subscription parsers rejected the key and the daemon's subscription reader ignored it.
Both parsers and the reader now accept dots in the host ID. Storage already treats the captured ID as one literal JSON property, so there's no migration, escaping scheme or registry change. Reserved toggles, boolean-only values and the other unknown-setting checks are unchanged.
Refs #2057; thanks to @AdamWhitehurst for the report and the config-side reproduction.
Tests cover both writers, persistence as one literal host key, read and reset, parser parity, and the real attention aggregator with mocked HTTP, including disabled-host filtering. No new refusal or error code.
* Prepare registered-person park resolution for remote verification
* test(queue): expect conflict when a park is already resolved
* test(queue): preserve asked-person semantics for terminal resolve
---------
Co-authored-by: dev-driver <dev-driver@openrig-build>
* feat(gateway): several people, shared channels, organizations, groups, readable policy and a default person
The gateway can now register several people and shared-channel participants
(one vetted Slack channel is one participant at <id>@external), group them into
organizations and groups, give each readable policy text, and name a default
person.
Storage keeps rollback safe. Person fragments keep the closed key set a v0.7.0
daemon reads, so an older daemon still loads every person. Everything new lives
in gateway/participants.yaml, which v0.7.0 and v0.7.1 never read. A broken side
file never disables the person registry; a person removed by hand leaves a
warning, not a broken file.
Policy is text agents read, shown organization first, then each group, then the
participant's own, each labelled with its source. Nothing enforces it or derives
it from names.
The default person serves needs that name nobody: escalations, the notice
digest, Mission Control's my-queue, the workflow fallback and pairing approval.
It's the chosen person, else the only one, else none with the reason, never the
first file by id. workspace.operator_seat_name keeps its existing meaning.
Verbs: `human add` accepts several people and takes --organization, --group,
--policy/--policy-file and --default; `human show` adds the placement; `human
set` takes organization, groups and policy; `human remove` also clears the
person's placement. New: `channel add|remove`, `org set`, `group set`,
`participants` and `default`.
A second registered person's Slack reply, typed or clicked, never answers,
closes or resumes another person's pending or parked ask. Main already guarded
this at two independent places; the new test pins both.
docs/reference/gateway-participants.md covers the commands, the default, upgrade
(nothing to do) and what a rollback to 0.7.1 or 0.7.0 changes. The
messaging-the-human skill points agents at `rig gateway participants`.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* fix(gateway): a person can't take a shared channel's id; upgrade note for several people
People and shared channels share one address space (<id>@external). Adding a
channel already refused a person's id; adding a person now refuses a shared
channel's id too, in the registry's own add path and before any write, so the
participant file, its default and the channel stay intact. Before, the add
succeeded and the participant file stopped reading: the chosen default, every
placement and policy were lost, and every repair refused.
`human remove` now deletes only a person's entry from the participant file, and
`channel remove` only a channel's, so neither can remove the other kind.
The upgrade note now covers installs that already had several people: choose a
default with `rig gateway default <id>`; until then escalations report
undeliverable:no-default-person and the notice digest waits.
The ordering tests now expect the list sorted by id, people and channels
together, and pick the person by id.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
---------
Co-authored-by: review50-r3 <review50-r3@openrig-build>
Co-authored-by: Claude Opus 5.5 <[email protected]>
Carry the corrected published 0.7.2 notes into the changelog on main, preserving contributor credits and verification limits. Only documentation changes; no tag, archive, npm or Release edit.
Clarify when Herdr may show a waiting seat as idle: a wrapped Claude footer or a visible inner tmux status line. Keep OpenRig's view and Feed as the route to find waiting seats.
Documentation only; matching mirrored skills and generated digests. The supporting evidence uses replay and screenshot-derived frames. No native runtime fix, historical causal proof, or live settings change is claimed.
A Claude runtime-switch successor uses the existing startup input-box wait and guarded staged-text Enter retries. Shared helpers keep the startup rules in one place; Codex successors retain their existing sequence. Confirmation still controls commit, with rollback and recovery unchanged.
Independent launch-sensitive source pair clear; exact-head hosted CI passed. Builder unit RED/GREEN and broader Linux A/B are attributed. The observed native long-handover cause remains unknown and this patch has not been shown to cure that case. Bounded observation adds waiting, and full staged matching uses the existing normalization. No new setting, refusal or repaste.
Registered remote hosts stay in the topology tree without a feed subscription. Drilling into an HTTP host lists its rigs and states, with host-qualified pointers for seats. Failed reads are distinguished from empty results, and local facts/actions are not presented as belonging to the remote host.
Reported by @AdamWhitehurst. Refs #2049. Local display-label item remains separate; this does not close the whole issue.
Verification: independent source review and required hosted CI. Builder Linux tests and two hermetic daemons exercise built hydrate/render, not an interactive TUI or a real second machine. SSH hosts remain listed but remote summary forwarding is HTTP-only. Remote TABLE retains small unused local health/queue reads; GRAPH may read unused local rig graphs, attached only to the local host and not rendered as remote. No remote seat actions are added.
`rig skill loadout --seat X --apply --wait-for-idle 60000` can wait a minute instead of failing at the client's five-second default. Its request timeout is the requested idle interval plus five seconds; without a wait option it keeps the existing client default.
This is the unchanged two-file loadout delta, now based on main after #2020 merged. It uses that client's long-request path for deadlines of at least 300 seconds, sends one POST with the full original wait, and reports the daemon response unchanged. No retry, continuation, outbox, route or shared-helper change is added.
Validation: paired source review and eight required CI checks pass at40367426. Existing fake-clock real-client controls cover six-second responses for60-/600-second waits, transport selection, exactly one POST, the timeout margin and unchanged output; the actual-main restack's own patch is byte-identical. These checks do not establish a native agent reading the skill list.
New scoped tmux panes keep tmux's own `TERM_PROGRAM` and `TERM_PROGRAM_VERSION` through the launch's initial environment reset. A managed Claude seat already forwards those names, but they were erased before that step, so Claude couldn't identify tmux and request the extended keys it uses for Shift+Enter.
The reset now keeps these two fields alongside `TERM`, taking the values from the newly spawned pane rather than the daemon or its configured baseline. It applies to fresh and successor panes that use the reset. No terminal option or session environment changes. On Linux, #2036 already joins a relative `WAYLAND_DISPLAY` selected through tmux `update-environment` to the seat's runtime directory.
Refs #2041; thanks to @AdamWhitehurst for the report and the environment evidence. The obsolete integration-test assertions and first-server fallback were fixed separately in #2047. This change addresses the terminal identity loss; the Linux Wayland statement is conditional on the selected display environment.
Tests cover present, empty and absent terminal values through the composed scoped reset and managed launch, including a conflicting daemon baseline. No new refusal or error code.
Include the inbound item in external reply hints so an agent can reply in the originating thread. Existing thread resolution and update validation remain in use. Validation: author-reported focused envelope tests and TypeScript builds; all eight required hosted CI jobs passed at the admitted head. No live Slack round trip was exercised for this review.
Adds per-seat Codex permission envelopes and profile setters through the existing audited permission surface. Inherited runtime switches carry the envelope; an explicit target mode intentionally replaces it only when the switch commits. Profile checks resolve the target seat home.
Independent source pair clear; exact-head hosted CI passed. Native sandbox/approval enforcement is separate. Existing unreadable/dual stored-record handling remains; no envelope-plus-explicit-switch refusal.
The clearing helper tolerates only the intended missing-column fixture case; other initial read failures roll back the existing transaction. Focused tests cover both discrimination and switch state restoration.
Keeps managing unchanged OpenRig config tables after a Codex save moves them, and preserves other tables printed between managed markers. Array-of-tables fragments project and replace their owned entries without repeating them.
Independent Claude/Codex source review retained across patch-identical restack; required hosted CI passed. Existing limits remain: moved array entries outside markers may duplicate, entries under owned array roots inside markers are replaced, and changed moved tables remain user-owned.
The first-run reference checker now discovers shipped `SKILL.md` files on Windows. Its walker uses native `path.join`, so testing for a literal `/SKILL.md` suffix returned an empty catalog on Windows; `path.basename(p) === "SKILL.md"` handles the native separator and matches the sibling scripts' existing idiom.
One line changes. Reference parsing, skill names and validation rules stay the same. The independent source pair is clear and all eight required CI checks pass. The contributor reports a native Windows before/after run:53skills discovered,489references checked,0failures; that run was not independently repeated by the desk.
What a person gets
After this, a person's own Codex hook trust survives OpenRig's next seat launch, so Codex stops asking them to trust the same hooks again every launch. OpenRig never adds a second set of its activity hooks either.
Before:
- **Codex 0.164.0 rewrites all of `[hooks.state]` when it saves trust.** That's its "Trust all", a `ConfigEdit::SetPath` on `hooks.state`. `toml_edit` then prints the rewritten table after the last hook group, which is inside OpenRig's `# BEGIN/# END OPENRIG MANAGED ACTIVITY HOOKS` block, ahead of the END comment. The END comment was the prefix of OpenRig's first trust table, and it moves with that table.
- **OpenRig's next launch replaced everything between the markers.** That deleted the person's newly trusted entries, so the prompt came back on every launch. Turning OpenRig's hooks off deleted them the same way.
- **When a save left the markers apart from OpenRig's groups,** OpenRig appended a second block, and the relay ran twice per event.
Reported by @borfast in #17. #2028 fixed the other half of that report, the trust key's group position.
If Codex already shows OpenRig's hook twice, from a config the old code doubled, remove the extra `[[hooks.<event>]]` groups that run OpenRig's relay, once. This change stops new copies; it doesn't remove old ones.
What changed
- **OpenRig's groups are read as TOML.** The config is split at its real table headers, never at text inside a string or an array, and each header's key is decoded in any spelling, such as `[[hooks."Stop"]]`. A group is OpenRig's when it's for one of OpenRig's four events and runs nothing but OpenRig's relay. A person's own group for the same event, inside the markers or not, is theirs.
- **Inside the block:** the activity-hook block rewrite and the strip that turns hooks off now keep every section between the markers that isn't one of OpenRig's groups, whole, with the comments just above it. Codex's `[hooks.state]` tables stay.
- **Groups without markers:** when the markers are gone but groups already run OpenRig's shipped relay, those groups are OpenRig's where they sit.
- Only the `command` line of each one's own handler is pointed at the current relay, so an upgrade still works.
- No second set is appended.
- Their trust is keyed by their own positions.
- **A check before writing:** the inline writers confirm that only OpenRig's groups and the `[features].hooks` flag changed and that the file still parses. Otherwise the config is left as it is, with a line in the daemon log. A config that doesn't parse is left as it is too.
- **Unchanged:** a person's own hooks, their order, and every other table.
Tests
`codex-hook-trust.test.ts`, "#17":
- **The fixture reproduces Codex's save from the inspected writer.** It is source-derived, not a captured native save. It takes OpenRig's launch of a config with a person's own hooks, then applies the 0.164.0 write: `[hooks.state]` and every entry, sorted, with literal-quoted keys and values, printed after the last hook group, with the END comment travelling with OpenRig's first trust table. A first case checks the person's trust really is inside the markers.
- **The next launch keeps:**
- the person's trust;
- their groups and order;
- exactly one set of OpenRig's groups, with correct trust.
- It's also idempotent.
- **Turning hooks off** keeps the person's trust.
- **With the markers gone,** with the current relay or an earlier install's relay, no second set is added, and the commands point at the current relay.
**Read as TOML** (`codex-hook-trust.test.ts`, "OpenRig's groups are found by what they are, not by their text"):
- a relay command example inside a person's multi-line instructions stays exact;
- a person's group for another event that runs the relay isn't repointed;
- OpenRig's group written with a quoted event key is removed when hooks are turned off, and replaced rather than kept beside the new one;
- a kept section whose multi-line string holds a `[[hooks.Stop]]` example stays whole, and the file stays readable;
- a person's own PermissionRequest group inside the markers is kept on a launch and when hooks are turned off;
- a config that doesn't parse is left byte-identical.
With #2034's source, the four behaviour cases above them fail. With this PR's first revision, the seven new cases fail.
Execution views read transition history for blocked Q1 lanes and Q5 rows before pickup immediately returns `parked`. Skip that unused read at those two callers. Live history stays fresh, and the separate armed-wake lookup and park outputs remain unchanged. Required-read errors still propagate; failures solely in the omitted read no longer fail the view.
Validation: 140 focused owner tests and daemon typecheck passed; independent QA passed 124 existing tests plus one adverse case, and both source reviewers approved. One contained same-snapshot product comparison reduced history reads from 246 to 4 and post-cursor work from 527 to 208 ms, preserving the full response except build identity. This is a local result, not a released-version or historical-incident cure claim.
When Claude Code 2.1.309 shows its "Resume session" picker instead of resuming an exact conversation (a bare `--resume`, or a name that matches no title or several), OpenRig no longer reads the seat as resumed and ready. Before, startup input or an ordinary send could land in the picker's search, and Enter could resume the wrong conversation. 0.7.1 behaved the same.
- The native resume probe and `checkReady` read the picker as `attention_required` / `claude_resume_selection_prompt`, in tall and default panes.
- Startup reports `attention_required` at once instead of waiting out its readiness timeout; the same attention set also covers the numbered and two-choice choosers.
- A plain send at the picker returns `target_needs_input` and types nothing.
The picker is recognised by its "Resume session" heading followed directly by its framed search box. It stops counting only once Claude's framed input box or a column-0 reply is drawn after it, so an old picker above a resumed session reads as resumed, and a card title that mentions "Claude Code v…" can't dismiss a live picker. The check is skipped for Codex and Pi panes. An exact id Claude can't find still reads as `no_conversation_found`.
Tests use the real 2.1.309 picker frame. Cost against main: source +36/-1, tests +126 (including a 4-line fixture). No new error code; the existing `target_needs_input` refusal now also covers this picker.
The first seat started by rig up on a new tmux server now reads the same scoped launch options as later seats. Reuse the existing server-start helper when the initial default-shell read is unavailable, then retry that read. Existing servers and the existing fallback/warning remain.
The Linux environment test now checks the scoped values instead of expecting inherited daemon values, and a private-tmux adapter case covers the first-seat path. The existing empty-server helper keeps an empty server available, as on other startup paths.
Validation: independent paired source review, builder Linux before/after controls and focused checks, required exact-head CI8/8. The Linux /proc integration test is skipped on macOS CI; no new Linux CI job or native provider acceptance is claimed.
Long --wait-for-idle sends no longer fail at Node fetch’s 300-second header limit. Requests with a budget of at least 300 seconds use node:http/https as one request, preserving the daemon’s deadline and occupant binding. Shorter requests keep fetch. A deadline remains a timeout even during body consumption; a dropped response body stays unreadable/unknown rather than claiming the message was not sent.
The HTTP test guard is installed only in the CLI suite; shared fetch guarding and cleanup remain. No dependency, setting or daemon route. The limited transport accepts string bodies and uses direct connections without global proxy agents.
Validation: prior independent paired behavior review, independent harness-only delta review, builder real 400-second wait and focused regressions, and required exact-head CI 8/8. This does not claim a native runtime-switch test.
Large execution views collect candidate rows in one synchronous SQLite call, making health checks and unrelated requests wait for seconds. Read WAL candidates through a request-owned readonly cursor that yields between slices, and serialize complete execution builds per projector. Transactions, memory and non-WAL databases retain synchronous main-handle reads.
SQL, bindings, row order and complete results are preserved. Candidates use one committed snapshot; later history reads can observe writes committed during yields. Native steps can still block, and queued execution requests can exceed the existing client deadline.
Validation: 138 focused tests, two independent transaction/cleanup adverses, and a matched source-built full-request case confirming complete-result parity apart from build identity and health-handler progress during the cursor read. This does not establish an overall request-time speedup.
Codex resume and legacy restore now put the conversation id before the queue-state and team-workspace `--add-dir` arguments. OpenRig reads a Codex's identity from its unquoted process line, so a path containing a space there could be mistaken for the conversation id, leaving continuity unverified and later delivery refused.
The shared builder (`buildCodexResumeCore`) moves the already-resolved directory segment after the id, keeping directory order, permission choices and resolver calls. Callers without that segment produce the same commands. Process lines in the old shape are still read, so a seat already running that way is identified as before. Together with #2037, which did the same for an in-place restart, every Codex resume OpenRig builds is `resume <id> --add-dir …`.
Tests: a spaced shared-docs root and a spaced legacy team workspace each read the expected conversation id, through the real adapters' commands and the production process-line parser. Cost: 3 files +32/-6. No new refusal or error code.
A Codex seat launch now finds the project and hook trust tables Codex already saved in `~/.codex/config.toml`, whatever quoting they use, and updates them in place. It never appends a second table for the same key. Reported by @borfast in #2029.
Codex saves its tables with TOML literal (single-quoted) keys, such as `[projects.'/home/me/app']` or `[hooks.state.'…/config.toml:session_start:0:0']`. OpenRig looked only for the double-quoted spelling, missed them and appended a duplicate. Codex then refused to start, and so did every other Codex session on the machine, until the duplicates were removed by hand.
If Codex already refuses to start with "trying to redefine an already defined table", remove the extra double-quoted table it names, once. The trust writers leave a config Codex can't read exactly as it is, so that one removal is the whole repair.
What changed:
- The four trust writers (`upsertCodexProjectTrust`, `upsertCodexHookTrust`, `upsertCodexHookDisabled`, `rekeyCodexHookStateText`) and the owned plugin's content-approval check (`planOwnedCodexContentApproval`) find a table by its parsed key, read with the adapter's existing `smol-toml`, not by its text. Bare, double-quoted and single-quoted keys, spaces around the dots and a trailing comment all match.
- A header-shaped line counts only when it really opens a table in the document: swapped for a probe header the document doesn't already have, the parsed document gains that table. A table example inside a multi-line string, such as a person's `developer_instructions`, is left exactly as it is, and the real table is written.
- When the document already defines the key another way (an inline table or dotted keys), the writer leaves the file as it is; Codex's own trust prompt stays the fallback. The trust writers also leave a config that doesn't parse as it is, since appending can't make it readable.
- The helpers live in `domain/toml-tables.ts`, shared by the adapter and the owned-plugin check. A person's other tables and values are unchanged.
Not in this change: the rest of #17's repeated trust prompt (Codex re-saving `[hooks.state]` inside OpenRig's marked hook block) is #2035.
Tests cover single-quoted, inline and multi-line-example cases through the writers, `deliverStartup` and `ensureCodexActivityHooks`, the owned plugin's renewal, an unreadable config, and a probe-named key. Cost against main: source +77/-12 (the adapter, the owned-plugin check and the new `toml-tables.ts`), tests +134/-1. No new refusal or error code.
On Linux, when the daemon has an absolute `XDG_RUNTIME_DIR`, a seat now gets it, together with `DBUS_SESSION_BUS_ADDRESS=disabled:`. Tools whose sockets live in the runtime directory (an MCP server's daemon, gpg-agent, rootless Podman) work in seats without per-tool setup, and the seat's D-Bus clients don't discover or autolaunch the session bus on their own. Refs #2030; reported by @borfast.
`disabled:` was chosen from the libraries' sources: libdbus 1.16.2, GLib 2.88.0 and sd-bus 259.5 fall back to the runtime-directory bus, or autolaunch, only when the address is unset, and refuse an unknown transport before opening a socket. A Linux control with a throwaway bus confirmed it. This is default hygiene, not isolation.
It applies to the scoped tmux launch (fresh launch, restore and handover successors) and the managed Claude launch. A seat's own `XDG_RUNTIME_DIR` (from `env:`, a one-off name or tmux `update-environment`) leaves both names as before, a seat's own address is kept, and an empty address is filled. Unchanged: `terminal.inherit_tmux_environment` on, macOS, and a daemon started without `XDG_RUNTIME_DIR`. Pi and OMP agent processes keep their fixed list.
Changed behavior, accepted deliberately:
- `systemctl --user` connects to `$XDG_RUNTIME_DIR/systemd/private` regardless of the bus address, so a seat can reach the person's user service manager.
- A shell startup file that sets only `XDG_RUNTIME_DIR` used to let a classic seat's clients find the bus. Now the seat keeps `disabled:`. Set the address in the seat's `env:` to keep the bus.
Known limit: Codex starts its stdio MCP servers with a fixed list of variables, so a Codex MCP entry still needs `env_vars = ["XDG_RUNTIME_DIR"]` in `config.toml`. Codex hooks and shell commands, and Claude Code's MCP servers and hooks, get it with no setup.
Cost: source +56/-8 (`seat-runtime-dir.ts` new, `tmux.ts`, `startup.ts`, `claude-managed-launch.ts`), tests +114/-3, docs +10/-1. No new setting, refusal or dependency.
`rig seat restart <codex-seat> --keep-conversation` reads complete when the same conversation resumed, and the seat can be messaged afterwards, when a directory Codex was given has a space in its path, such as a working directory named `my repo`.
Before, in that case, the restart reported incomplete ("no single Codex process resuming this conversation was observed"), `reconcile` read continuity unverified, and an ordinary `rig send` was refused. The same conversation was running the whole time.
The cause: the relaunch reused the running Codex's own `--add-dir`s, git dirs included, and placed them between `resume` and the conversation id. OpenRig identifies a Codex by its process line, which joins argv with spaces (both `/proc` and `ps`), so that line named `repo/.git` where the id belongs. A shell or `node` wrapper isn't involved; the proof follows the chain from the native Codex through `node` and `sh` to the pane.
The change, in `codex-runtime-adapter.ts`: for an in-place restart, the running `--add-dir`s are reused unchanged and now follow the conversation id. Nothing is resolved again, and the running seat folder isn't added twice.
Not changed here: an ordinary resume still puts its queue-state `--add-dir`, and the restore path its team-workspace argument, before the id. Those are read wrongly only when that path has a space, and they're a separate fix.
Tests: the real process-line parser and pane observer read the id from a relaunch whose working directory has a space. Cost: source +4/-3, tests +29/-1. No new refusal or error code.
The execution view counted post-claim transitions for every candidate, including blocked and closed rows whose pickup logic never reads the count. Restrict this caller’s correlated count to pending and in-progress rows. Preserve historical rows and bodies, project/mission filtering, park/wake output, and the live bookkeeping-only fallback in the same SELECT.
Validation: 122 affected tests and daemon typecheck pass. Independent Codex and Claude source reviews pass. QA independently repeated all 122 tests and checked full-document parity through the real views route for project filtering and claimed-pending pickup; both adverse cases passed. The recurring severe-stall investigation remains open.
The parity test sets aside the free-disk reading (`q6_parallelism.df_margin.available_kib`), which is taken live at read time and can differ between the two documents it compares; every other field is still compared.
When a seat's session is confirmed missing, the stuck sweep sends its finding to a live recovery seat. The finding's reason now says which rule chose that seat, so whoever receives it knows why it landed on them, and which setting to change if it shouldn't have:
- "... so this finding goes to operator-admin@kernel, the operator agent (agents.operator_session)"
- "... goes to approver@r, the operator seat (workspace.operator_seat_name)"
- "... goes to sender@r, the row's creator"
Before, it named only the destination. The recovery seat is picked over the same candidates, in the same order, with the same predicate, so routing doesn't change. The sentence for "no live recovery seat is available" is unchanged.
Tests pin the rule name for each of the three outcomes; the operator-seat case only checked the destination before. Cost: source +12/-3 in `queue-stuck-sweep.ts`, tests +5/-3. No new refusal or error code.
An ordinary `rig send` into a Pi v1.4.0 extension input or editor dialog now returns `target_needs_input` and types nothing. Before, the message could become the dialog's answer, because Enter submits it. The deliberate, reasoned and audited input route is unchanged.
This covers default 80-column panes, where the help row wraps over up to three rows, and tall editors whose opening rule is outside the transport's 20-line capture. An editor dialog is recognized by its bottom rule, the complete four-action help with exactly one blank row on each side (Pi's `ExtensionEditorComponent` draws a spacer before and after it), and the dialog's closing border. So a draft in Pi's own main editor that quotes the help text still sends. Inputs keep the field, spacer and nearby opening-rule checks. #2015's later-composer and fence veto and its six-row footer limit still apply.
Pi renderer source: earendil-works/pi v1.4.0 at `4a080252f06caf63a525d7873c5d94d3c23887e0`. The fixtures reconstruct that renderer; they aren't native captures.
Limits: this stays a bounded screen heuristic. Clipped or incomplete help, more than three wrapped rows and arbitrary custom extension UIs keep their prior classification. A draft that copies the dialog's complete chrome, spacers included, still reads as a dialog: the sender is told and nothing is typed.
Cost: source +29/-5 in `session-transport.ts`, tests +105. No new refusal, error code or native runtime change.
A Codex seat without a pod restores through `CodexResumeAdapter` (`rig up --existing`, or a restore after a reboot), and that path added none of the git metadata `--add-dir`s #2000 gave fresh, resume and fork launches. So a default workspace-write seat restored that way couldn't write its worktree's `.git`, and commits failed. It now gets the same git dirs from the same resolver, then its seat folder, after the conversation id, so the `ps` proofs still read the id. They're added only on the plain workspace-write floor, since a named profile isn't checked for read-only on this path and Codex refuses a writable root under a read-only sandbox. Seats in a pod restore through the launch adapter, which #2000 already covers.
Tests use real temporary repositories: an ordinary repository's restore adds `<cwd>/.git`, and a linked worktree's adds its worktree and common git dirs, never the `.git` file.
Claude members that share a project folder can keep distinct, durable tool rules. Declare `claude_permissions.allow`/`deny` in the spec, or replace a retained seat's rules with `rig seat set-permissions <seat> --rules <json-file> --reason <why>`. The update is audited and takes effect at the next managed launch or resume. It doesn't restart the seat or change its permission mode.
Migration 139 stores one current record per node. Fresh startup, resume, legacy restore and same-seat handover read it, and a fork copies the source's current rules independently. Rules compose into the existing single `--settings`, keeping defaults, hooks and compaction settings, and are never written into the shared project's Claude settings. Status and export show the current plan. Stored Claude rules stay dormant while a seat runs another runtime and apply again when it returns to Claude.
A stored record that's invalid or unreadable refuses that seat's launch, fork or export with a repair message, rather than launching without its denies; the fork API reports `permission_rules_unavailable` (409) before creating a child.
Native check on this head (Claude 2.1.309): two members in the same folder get their own rules (one reads and writes a file the other is denied), a user-wide allow doesn't override a member deny, managed policy wins, and a setter change applies at the next launch, not in a live process. Not proven: that handover and restore keep the same conversation (the rules are carried in the launch arguments), and deny enforcement under bypass mode, which isn't claimed.
Limits: allow lists don't withdraw inherited grants; these are native tool rules, not OS or credential isolation. The pre-feature reader `75c1f045` opens the upgraded database but leaves the rules out of launch arguments, so before going back to older code, set equivalent native rules yourself.
Cost at this head against main: source +206/-27 in 24 files, tests +416/-7 in 13, docs +54 in one. One migration and one new error code.
A draft-aware message to a Claude seat pastes its text, then checks that the composer still holds only that paste before pressing Enter. When Claude replaces the mode footer with "paste again to expand" after the paste, that check read the composer as changed, so the message never submitted and later wakes could stall behind the leftover paste. The shared reader now treats those recognized noninteractive footer hints as part of the same composer. The lease, the original-empty check, the target and occupant, geometry, cursor and paste-label checks all remain. No extra input, delay or retry.
Refs #14. A native A/B on a fresh Claude seat delivered the long message and its dependent wake on both arms, so it shows no regression, but the original failure didn't reproduce, so #14 stays open.
Coming back to a Herdr view with `rig terminal open <view> --provider herdr` always adds a new numbered workspace; reusing an open one is the `--window` path from inside Herdr. The shipped `openrig-herdr` skill told agents to reopen with the explicit form, so people got a duplicate workspace. The skill, the getting-started guide and the capability map now say to focus the open space, or from inside Herdr run `rig terminal open <view> --window`, which reuses a matching space, and that `--provider herdr` adds a workspace each time. The `--provider` help text says the same.
A known-issue line: Herdr's own status for a seat can read idle or unknown while OpenRig shows it waiting (`needs-input`), because OpenRig doesn't feed Herdr a state. Use OpenRig's view or the Feed to find waiting seats.
Text only; the skill's mirrors and digests are updated together.
A seat restored with `claude --resume` can stop at Claude's resume chooser ("How would you like to resume?", or a numbered conversation list). In a tall pane OpenRig reported it as resumed instead of asking a person to choose, and a Codex model chooser in a tall pane read as `awaiting_runtime` instead of `model_selection_gate`. The reverse happened at the bottom of an ordinary pane: an old chooser above a resumed session's composer read as live.
Both choosers are drawn at the top of a fresh pane, and tmux keeps the blank rows under them. Each window now ends at the last drawn row, and a chooser counts only while it's the last thing drawn. For Claude, nothing of Claude's own may follow the last option: a composer, a `Claude Code v` header or a reply retires it, and Claude's input frame (a rule, the `❯` row, a rule; the top rule carries the session name on a renamed seat) counts as the composer. A bare `❯ N.` option row under a live chooser is still an option. A conversation list's heading is read from the whole capture, so a long live list still reads as the chooser. For Codex, the options count only when no composer row or `OpenAI Codex (v` header follows them. The probe still never answers a chooser.
Known limit: a frame drawn under a still-live chooser would read as resumed; no recorded layout does that.
Tests: tall and bottom-reaching live choosers for both harnesses, history above resumed sessions, long lists, numbered drafts in labelled and plain frames, and the restore orchestrator's chooser cases.
On the default workspace-write floor, a Codex seat's own topology folder (`<topology root>/rigs/<rig>/seats/<seat>`, home of its `LEARNED.md` and recap) sat outside its writable roots. So the seat couldn't keep its own `LEARNED.md` for its next occupant, and `rig context recap-write` failed with EPERM. The folder is now added as an `--add-dir`, created first if missing (including the rig's folder), because Codex can't create a folder outside its writable roots.
It follows the git metadata dirs' rules: fresh, resume and fork add it after the git dirs, and on resume and fork after the conversation id, so the `ps` proofs still read the id when the path has a space. A rebuild keeps the observed envelope, a provably read-only profile gets none, and an in-place restart keeps the running process's own `--add-dir`s. The restore path's resume adds it only on the plain workspace-write floor. The name must be canonical with safe segments, and a symlinked `rigs`, `<rig>`, `seats` or `<seat>` segment gives no folder and creates nothing through the link.
Because the seat can now write its own folder, and the daemon writes there for it through the recap route with wider file access, the recap store now refuses to write through a link at `RECAP.md` or `recap-superseded/` (dangling links included). That's an intentional refusal of a layout that worked before. The current recap, the archive and the link's target keep their bytes, and the error is the existing `recap_write_refused`. The direct write, the daemon fallback and folder creation are unchanged; the check runs before the write and doesn't cover a change made in between.
Codex inline hook trust was keyed as if the managed hook group were always at position zero, so OpenRig's trust entry could miss the hook Codex actually runs. Trust keys now use the managed group's actual position, the one Codex reads. A person's own trust hashes and disable choices are preserved, nothing new is trusted, and an old zero-position entry fails safe. The JSON hook route and hash algorithm are unchanged. Refs #17.
Thanks to @dajiaohuang.
A service bundle installed on a machine without Docker Compose v2 used to leave a half-made rig. Install now runs a read-only `docker compose version` before the install target is written and the team is created, and stops with `compose_missing` if it fails: "The install target wasn't written and no team was created." A preview (`rig bundle install --plan`) still returns its `planned` result and `services_plan` stage, and reports the failed check as a warning that an install on this machine would stop first. No Docker daemon is needed for the preview. The message keeps Docker's own reason line, not its trailing `See 'docker --help'`.
When `compose up` or `compose down` fails with Docker's own missing-plugin words, the error names the missing Compose. With Compose missing and no containers labelled for the project, there's nothing to take down, so an install's rollback can remove the rig. With containers, or with Docker unreadable, it still fails and names the missing Compose. Empty container inventory doesn't prove volumes or networks were removed. Plain `rig down` keeps the rig record, and `rig down --delete` behaves as before.
Bundles without services never run the check.
`transport-routes.test.ts` checked that a timed-out `--wait-for-idle` send returns 409 and sends no text, using a 1 ms wait in real time. On a loaded runner the first pane observation could finish after that wait, which by design reads `target_activity_unknown` instead of busy, so the test failed now and then (it failed one required CI run). A fake clock now drives the expiry, so the test checks the same outcome without depending on runner speed. No product code changes.
When a seat dies holding work, the stuck sweep's finding now goes to a live recovery seat when one is available, in this order: the operator agent (`agents.operator_session`) when one is configured, the operator seat (`workspace.operator_seat_name`), then the stuck row's creator. A candidate is skipped if it's unset, if its own session is confirmed missing, or if it's the dead seat itself. If none qualifies, the finding is still created, since it's owed work, stays addressed to the missing session, and its reason says no live recovery seat was available. A finding that can't be created is reported as a failed pass, as before.
`workspace.operator_seat_name` is the person approvals reach (the workflow human resolver and Mission Control's default queue read it), so it isn't repointed. `agents.operator_session` already named the operator agent's session for the UI's operator chat; the sweep now reads it first, so recovery can reach an agent while approvals stay with the person. A person's address (`@external`, or a human seat such as `human@kernel`) never counts as the operator agent. With the setting unset, routing matches the previous behaviour whenever that fallback is eligible; the self and confirmed-missing filtering now applies to the operator seat and creator too. The wake ladder is unchanged.
Tests in `queue-stuck-sweep.test.ts` cover the agent-first route, a missing agent passed over, the no-live-seat case two ways, and how the setting resolves.
The installed prompt-state scenario (#2002) drew its working Claude frame at the bottom of the pane, so it couldn't catch the tall-pane case #2005 fixed: a fresh seat draws its input box near the top of a tall pane, with blank rows under it. The scripted pane is now 45 rows, with the frame inline and top-aligned and the cursor in the input. Admission checks the real pane height (at least 40), the exact full-screen row count, a drawn mode footer and at least 20 blank rows below it. New controls reject short geometry, truncation and an all-blank capture. #2002's other controls are unchanged.
On #2005's parent (`a5289131`) the scenario stops at the named #1955 assertion: the quoted-selector working send is refused, in a 45-row pane with 35 blank rows. At this head it passes. Test and docs only, 3 files, +23 -10.
`startup_assisted: true` means a person checks startup submission after the attempt. The first turn may already be running, including when `first_input` passed it at launch, so the docs keep the no-resend guidance and say plainly that it's a check, not a hold.
The Cursor reference preset now uses `startup_assisted: false` with its existing positional first prompt, and the obsolete assisted-paste limit is removed. In native qualification at `802d44a2` (Cursor Agent 2026.10.22-27dcf5f), a 1996-byte first prompt arrived as one positional argument and got the expected first reply, and same-chat snapshot resume worked. Later native tool approvals remain separate, and full unattended tool-workflow completion isn't claimed.
Runtime code, the launcher and the orchestrator's assistance cases are unchanged. One test assertion follows the preset.
OpenClaw seats can run either an embedded local agent or a TUI client of an existing Gateway. The reference launcher keeps OpenRig's named conversation, checks the exact native key at its owner before resume, and passes the generated first startup input through `--message`. Both examples use the existing format-1 `names_conversation`, `resume` and `first_input` fields, and each seat keeps its own client state. An unavailable lookup is distinct from a confirmed missing key, and neither silently starts a replacement. Stopping a Gateway client detaches it without stopping the Gateway or an accepted turn.
Native qualification on `8f3d7a6c` with OpenClaw 2026.10.6 covered the Gateway journey (first input, a task, snapshot, same-conversation resume, a useful reply with no startup replay) and, for the local agent, first input, a task and a readiness-gated resume of a completed conversation in the same session UUID. A resumed process doesn't mean the native TUI has finished its database startup checks, so the guide says to wait for native readiness before sending work. A local turn interrupted by a stop may leave native recovery work that refuses a later request; the local preset says to finish the current turn before stopping, and this launcher doesn't repair or retry it.
No core plug-in contract change. Docs, presets, the launcher and one example test.
Queue history reads call the wake lookup once per transition. Preparing the same indexed statement for each call added avoidable work to health-diagnosis reads with long histories. Prepare it lazily once per repository instance and keep every lookup fresh; no query results are cached. Availability, ordering, misses and errors retain their behavior.
Validation: 140 affected tests and daemon typecheck pass. Independent Codex and Claude source reviews passed on the identical two-file change. A real-database test checks a warmed miss, insertion, update and deletion.
In one synthetic daemon replay with 100 owned diagnoses and 6,900 history transitions, reference/candidate/candidate/reference evaluation means were 918/759/745/1,014 ms: combined 966 → 752 ms. All 12 evaluations retained complete coverage and all 16 native-consumer checks passed. Reference drift was 96 ms and individual ranges overlapped. This is a local improvement on that workload; the recurring severe-stall cause remains unresolved.
`rig queue resolve` now also releases an item parked on a typed blocker, such as `external:<what>`, `fold:<what>` or `auth:<what>`, once that blocker is met. The supplied evidence is recorded with the transition as a wait resolution, not as a human decision, and the item moves back to in progress with its owner nudged, as `resolve` already does for an item waiting on a person. Items blocked on another queue item, malformed blockers and items that aren't blocked are still refused. The mission-control architecture doc describes the widened eligibility.
This is the widening agreed on #1785 instead of a new `satisfy` verb. Thanks to @dajiaohuang for the change and to @BillyOutlast for the report from their fleet.
An adopted Pi TUI can keep an unknown runtime and has no managed-runner hook, and the shared pane classifier didn't recognise Pi's extension selector. So an ordinary `rig send` into a window waiting at an approval dialog typed its text and pressed Enter, which chose the highlighted answer (by default Yes).
The classifier now recognises the current Pi selector by Pi's own chrome: an option block with exactly one arrow-selected row, the navigate/select/cancel help row, and the closing border after it. The footer isn't read, so unnamed sessions, missing usage counters, extension status rows and below-editor widgets don't decide recognition, and rebound keys and any choice labels work. A later editor border or a closing Markdown fence marks the selector as history or a quote. The existing prompt guard then refuses with `target_needs_input` and writes neither text nor Enter. Ordinary unknown-runtime sends and the audited deliberate-interaction override are unchanged.
Limits: up to six non-blank rows may follow the selector's border (the footer, a status row and widgets). Past that, or under a widget that draws its own border, it fails open to the previous behaviour. Pi's text-input dialogs aren't selectors and aren't covered.
Tests: `send-prompt-guard.test.ts` covers ten layouts with null, unknown and Pi runtimes, selected No, history and quoted output. Source +24, tests +85.
A default workspace-write Codex seat couldn't save its handover recap: `rig context recap-write` wrote the topology seat folder from inside the seat's sandbox and failed with EPERM, so a rebuild recovered only from git.
The CLI still tries the local write first. Only when the OS refuses it (`EPERM`, `EACCES`, `EROFS`) does it send the recap to a new `POST /api/context-packs/seat-recap`, and the daemon writes it. Both paths use one `writeSeatRecapAt` for the address checks: bounded names, an existing rig, no symlinked or file segment in the rig, `seats` and seat folders, and the existing supersession and addressability rules. A link already at the recap file or its archive folder is followed, as the local path always did. The Markdown heading parse the route uses is now a linear scan with the same accepted headings, so a long recap can't stall the daemon.
Validation: CLI and route tests cover the fallback, a timeout reported as UNKNOWN, an unreachable daemon and each address check; the heading scan matches the old regex on a large differential set and stays fast on the inputs that made the regex slow.
Moving between TUI pages forgot the activity stream's connection state. A new page treated a connected stream as disconnected and polled every 30 seconds instead of every five minutes, and returning to a cached page after a disconnect could bring back `connected` and wait five minutes for its next read. Connection state now belongs to the live refresh owner, outside cached page loads, so navigation keeps the real state and its cadence.
Thanks to @Nikhi00718.
When a seat's session disappeared, the stuck sweep addressed its recovery finding to that same dead seat, and the seat kept reading idle at prompt, so nobody was told.
A stuck-sweep finding whose route is a seat with a confirmed-missing session now goes to the configured operator seat, or else to the stuck row's creator, the floor the wake ladder already uses, and its reason names the missing session and where the finding went. That seat's activity reads unknown on the queue's surfaces. The check is one predicate reusing node inventory's own confirmed-missing rule, so no verdict, a stale verdict from before a relaunch or handover, or an unreadable store still reads not-missing. Live seats keep their findings, and orchestrator routing is unchanged.
Validation: the sweep, wake-ladder, node-inventory and projection suites pass, and the three routing cases fail on the old sweep. Daemon typecheck passes.
Agents asked how far to trust a delegated result didn't reach the delegating-work skill, although its body already covers that. The skill's description now ends with one trigger sentence: "Also use it to decide how far to trust a delegated result." The body and every other byte are unchanged; the shipped copies and digests match.
In a lab measurement (Sonnet 5.5, Claude Code 2.1.310, one skill listed), the skill activated on 5 of 5 runs for each of two target prompts and on 0 of 36 near-miss runs. There's no claim for other harnesses or models.
Thanks to skills-sme@lab, and to Matt Pocock's writing-for-agents and Lauren Tan's pstack Eval, which shaped the method.
`rig provider switch --seat <seat> --token-file <path>` moves one Claude seat onto a prepared subscription token, on the same conversation, the same config directory and the same pane. `--stored-login` moves it back to the config directory's stored login.
- OpenRig stores a reference to the token file (a label and path), never the value. The launch reads the file as Claude starts and exports it only into Claude's process, so the value never reaches OpenRig's database, rows, argv or logs.
- The seat keeps its pane: Claude ends in place, a shell respawns in the same pane with its scrollback, and restore's own resume step brings the conversation back.
- The report names the source the seat actually bills. The token survives the managed environment reduction. Variables that would outrank it are unset for that one process, which also hides them from Claude's tools and hooks. With `--stored-login`, an inherited `CLAUDE_CODE_OAUTH_TOKEN` is reported rather than silently used, and a launch-time fallback warning reaches the report.
- Outcomes are honest. Only a refusal before Claude is touched reads as unchanged. A pane that was ended but not resumed, or a thrown step, reads `unknown` with the snapshot's recovery command, and nothing is retried.
- The whole switch runs in the seat's existing lifecycle lease, so a second switch waits and rechecks. A failed registration never kills a kept session. The printed way back quotes the token path.
One nullable column (migration 138) and one event type. No account registry, vault or new route. Native validation on prepared homes is next.
A `rig send` to a Codex seat that is mid-turn printed only "target pane appears mid-task; sent anyway". Codex folds such a message into its running turn, and in a measured run the turn then answered only the new message.
When the target seat runs Codex and no `--wait-for-idle` was passed, the advisory now adds that the message joins the running turn and may redirect it, and names `--wait-for-idle <seconds>` for separate work. `docs/reference/seat-delivery.md` says the same. Other runtimes keep the existing warning; sends stay advisory, with no new mode, refusal or default.
Validation: the existing busy-send test now covers Codex and Claude, and the session-transport suite and docs guard pass.
After a team's tmux server dies (a crash, OOM or kill) and leaves its socket file, `rig down` reported "Could not confirm session … is absent: no server running" for every seat and stopped nothing, so `rig archive` refused live sessions and `rig up` refused a running rig.
`rig down` now treats tmux's own "no server running on <socket>" diagnostic from the daemon's probe as positive absence: it records the sessions as intentionally stopped and clears their bindings, without killing anything or starting a server, and archive and up then proceed. The rule lives in one shared predicate beside `SessionProbe`, used by teardown and the import guard, and matches only the start of tmux's diagnostic (stderr, or the line right after a `Command failed:` wrapper). A missing socket file, a permission failure, socket-path text and any later line stay uncertain, as before. The session-absence check uses the same start-of-diagnostic boundary, and the probe rethrows the original error so its reason stays readable.
Scope: a reboot that clears the socket directory is not covered. Validation: focused teardown, adapter and guard suites pass, including path-text, newline-path and mixed permission controls that kept the rig and binding, and daemon typecheck passes. Native acceptance (kill a disposable team's server, then down, archive and up) is separate.
A prompt visible only in a seat's pane must appear as needs-input across the API and CLI, and quoted approval text above a working Claude composer must let coordination messages through, while an actual waiting prompt still refuses them. Both regressions escaped to users (#1946, #1955).
Adds one installed `prompt-state` scenario using adopted scripted panes, the real daemon, CLI and tmux path, actual timer wakes, and a read-only check that no hook supplied the activity. It checks that attention clears on a working pane, that both quoted-text forms admit a send and a wake, and that a real dialog refuses both; the refused wake is tied to the watchdog's own attempt record and refusal reason. No production source or provider calls.
Validation: the installed case passes at this head in about 21 s in its disposable container (peak memory not sampled). On rebuilt historical sources it fails at the named assertions: the pane-only attention check on 32633a3d, and the quoted-selector working send on the parent of db863940. The scenarios use controlled pane layouts and don't prove native runtime behaviour.
A fresh, working Claude seat in a tall pane (40 rows or more), with quoted approval text above its input box, refused sends and queue wakes as if it were waiting at a prompt, which is #1955's bug again. It also happened just after a cancel or clear redraw. Claude Code draws inline, so the rows under its footer stay blank, tmux keeps those blank rows in a capture, and `findClaudeComposer` took the last 20 physical lines before dropping blank ones, so in a tall pane it saw only blanks.
The 20-row window now ends at the last drawn row. The bound and column preservation are unchanged, and the status scan above the box still stops at the nearest unindented row. The draft-aware typing guard and the running check use the same function.
Validation: the tall-pane cases fail on the old source and pass after. Every dialog layout drawn high, with blank rows under it (permissions, the question picker, the MCP menu), still reads as attention, and sends to them are still refused. Native confirmation in a tall pane is separate.
A person who declined `rig setup` could still get Codex config writes when the kernel started, and a project task handed to the kernel operator could be implemented there instead of by a team.
The installer guide now says, before installation and startup, what each step writes: setup writes `~/.tmux.conf`, and starting Codex seats writes workspace trust and selected config fragments to the home `config.toml`, which skipping setup or turning hooks off doesn't suppress. A separate Codex home also selects login and session state, and a project config or worktree doesn't redirect these writes. It explains why individual approvals prompt often, keeps the one optional remembered-rule offer, and rules out broadening other settings to avoid prompts. The operator's role and startup context put project work on the chosen team's queue.
Guidance only: no setup mode, configuration or runtime change. Validation: docs guard, the first-run reference checker and the global-skill fixture checks pass, and the canonical and packaged `rigs` skill copies match. Whether agents follow it is for the first-user checks.
On Linux, `rig seat restart --keep-conversation` rebuilt a Codex seat's resume from `ps` output split on whitespace. With a cwd such as `/home/u/my repo`, the restart passed `--add-dir '/home/u/my'`: the seat lost write access to its `.git` and gained it on an unrelated prefix.
The restart now reads the running process's exact argv from `/proc/<pid>/cmdline`, next to the `/proc` reads it already makes, and uses it for the writable roots, network and daemon options, and the settings and effort comparison. A value containing a space no longer reads as settings drift. If `cmdline` can't be read, it falls back to `ps` as before. Nothing new is refused. The process facts are still read separately, as before; this is not a guard against pid reuse.
Validation: the new restart case fails on the old source and passes after, and the restart suites and daemon typecheck pass. The real `/proc` reader test runs only on Linux, so CI's macOS runner skips it; the NUL-splitting parser is tested on every platform.
Contributors now get the correct vercel-labs/agent-browser source link and an accurate description of our retained copy, rather than an unsupported "tracks upstream" claim. Its upstream Apache-2.0 license travels beside it and beside dogfood; the three shipped obra/superpowers derivatives (systematic-debugging, test-driven-development, verification-before-completion) also include their upstream MIT license. Check dates name the compared upstream revisions and say no content sync occurred.
Skill bodies, triggers and companion workflow files are unchanged. Mirrors, edge digests, the docs guard and the exact upstream license bytes are verified. Metadata, notices and regenerated hashes only.
Thanks to the authors of vercel-labs/agent-browser and obra/superpowers.
The dashboard shows a neutral "Boot not tracked" badge for `kernel_state: "skipped"`, keeping the daemon's reason visible. An existing managed kernel and an explicit auto-boot opt-out can both produce this state; ready-agent counts do not turn it into a healthy verdict. Unavailable or malformed responses still show "Unknown".
The added component cases fail on unchanged production code and pass with the fix; they exercise the real query hooks and rendered card with synthetic HTTP responses. The dashboard documentation describes the new state.
Reported by @Kero-66 in #1915.
A Codex seat in workspace-write could commit, but after `rig down --snapshot` and `rig up --existing` it resumed without `.git` among its writable roots and could no longer commit. The fresh launch adds `--add-dir` for the seat's git metadata (#121); `codex resume` and `codex fork` were sent without it.
`prepareLaunch` now resolves the git dirs once per launch, with the same rules as before: a linked worktree's real git dirs, never a `.git` file, and none for a provably read-only profile. Fresh, resume and fork all pass them, and a fresh launch's command is byte-identical. A rebuild keeps its observed permission envelope, and an in-place restart reuses the running process's own dirs. On resume and fork the git dirs follow the conversation id, so the `ps`-based resume and fork proofs still find the right process when the cwd contains a space; Codex 0.164.0 parses options after the id as options.
Validation: 11 resume and fork cases fail on the old source and pass after; the Codex adapter suites pass, including new cases with real temporary repositories and linked worktrees. Two independent reviews, one with a security lens. Native acceptance (commit, restore, commit again) is separate. The pod-less legacy resume path is unchanged.
Unknown-readiness diagnosis currently runs a full tmux environment listing for each relay prerequisite alias while holding the seat’s send lease. Read requested presence booleans from one fresh listing instead. Keep scalar fallback for custom adapters; a failed batch returns UNKNOWN without exposing values. This intentionally uses one snapshot and one failure outcome rather than separate alias reads.
Validation: 559 focused tests and daemon typecheck pass; independent Codex and Claude reviews pass. A single instrumented comparison recorded lower preflight intervals, but both arms still had one five-second timeout. This removes redundant subprocess work; it does not claim to eliminate send timeouts.
CHANGELOG 0.7.1 now includes the service-bundles entry already published in the 0.7.1 release notes, as the last "Running a team" bullet before "Reliability".
The entry matches the published body after whitespace normalization and the changelog's heading nesting, and it is the only insertion. Documentation only: no release, package or version change.
A Pi extension dialog is shown in the seat pane and cancelled, with the seat marked as needing attention. The signal survives turn end and idle heartbeats until a new agent run starts. Extension notifications are shown without generating a response or attention.
The runner reuses the existing RPC cancellation policy: it replies only with the request's own id and cancelled: true, so nothing is approved, and it cannot answer dialogs in the pane. The pane explains the cancellation and asks the operator to review the request. Dialog title and message are stripped of terminal and control characters and capped before display. OMP behaviour is preserved.
Validation: five new controls fail on the prior source and pass after the change (the four dialog methods and a notification); the Pi and OMP runner suites pass with one worker. Two independent reviews, one with a security lens. Real Pi acceptance is separate; no native process or provider call ran.
The packaged-plugin baseline now records the published 0.7.1 instead of 0.7.0: tarball sha256 c1637bbe (matching npm's integrity) and openrig-core 0.1.18. It's generated by the script's own refresh command from `npm pack @openrig/[email protected]`. The 0.7.2 cut's plugin check compares against the release users actually have.
Fixture only: +4/-4. No code changes.
`rig provider switch`'s printed undo and `rig auth switch` restore a saved Codex login's bytes. They now say only that. The output says sign-in is unverified, that saved credentials may expire, be revoked or be superseded by a refresh elsewhere, and that you should restart the affected seat and use the existing account verification, since a fresh sign-in may be needed.
Before this, the undo printed `activated_profile` and exited 0, which reads like restored access. Codex keeps a refreshed token only in its active `auth.json`, so an older saved copy can go stale.
Text only: +23/-3. No behaviour, refusal or JSON change.
A backlog of queue notifications can hold startup in sequential verified deliveries until the CLI readiness deadline expires. Start the daemon-owned recovery pass after listening. During shutdown, finish the delivery in flight and stop later claims, including released members of combined wakes; unattempted notifications remain for the next start.
Validation: 125 focused tests and daemon typecheck pass, with two independent source reviews. An independent four-stub-seat, 40-notification replay reproduced the reference readiness failure at 21.17s; the repair reached health at 2.96s and attempted all 40 (20 render-verified, 20 awaiting confirmation). Consuming-agent acknowledgments and large-database startup remain unqualified.
Main now carries what 0.7.1 published.
- `CHANGELOG.md`'s 0.7.1 entry is the published v0.7.1 Release body, word for word, reflowed to the file's line form. That includes the credits for all reporters and all 22 known issues. It replaces the earlier draft the tag carried.
- `docs/reference/whats-new.md` carries 0.7.1's entry from the tag, with one line narrowed to what's true at source.
- The root, cli, daemon and ui package versions and their lockfile entries move from 0.7.0 to 0.7.1, matching the v0.7.1 tag. The packaged whats-new must name the package's own version.
No other changes.
A community-harness preset can now set `first_input: true`. OpenRig then hands the harness its first startup turn at launch, through the harness's own route (OpenClaw's `--message`, Cursor's positional prompt), instead of pasting it into the pane after start. Without this, OpenRig could report a seat ready while its identity text sat unsent in the composer.
- OpenRig composes exactly the first startup text it would have pasted, writes it to a per-attempt 0600 file in an OpenRig-owned folder, and passes `OPENRIG_FIRST_INPUT=<path>` at launch. The preset's launcher hands it to the harness.
- Only that one send is skipped. Later startup files, `after_ready` actions and ordinary sends go through the pane as before.
- The record says the first input was passed at launch, not confirmed submitted, and only once the transport actually attempted input. An uncertain launch never replays it.
- Readiness stays process-only, and `startup_assisted` is independent. Built-in runtimes and presets without the field don't change.
The two reference launchers (OpenClaw, Cursor) use it. Argument-based harnesses see the first turn in their argv, which may face platform argument-size limits; that's in the presets doc.
The MCP read tools `rig_status`, `rig_slices`, `rig_mission`, `rig_context_pack` and `rig_context_get` were tested only against a mocked client. Now each runs through the daemon's real routes too, so a change to `/healthz`, `/api/slices`, `/api/missions` or the context-pack library response fails CI instead of silently breaking the tool for an MCP client.
The cases check what a client would see: healthy status, filled slice and mission summaries, a cut page that says so, pack and file contents, and no local path in any answer. `rig_status` covers only the healthy pass-through; an unhealthy daemon's mapping isn't exercised here.
Test only: +77/-2 in `packages/cli/test/mcp-operations-daemon.test.ts`. No source change.
A focused TUI view that shows a health summary (the instance Table, the rig and pod Table, and Overview) now loads the existing health projection that summary displays. Served findings and coverage appear after hydration instead of staying at "Not assessed". Other focused views keep the findings read lazy.
An empty projection still reads as "not a healthy verdict", and a 503, an unrequested read or a remote-host summary stays honest. Pod summaries keep the rig scope. The still-resolving `pendingDrill` first frame isn't covered.
This carries @Kero-66's original fix and report forward, with their commits and authorship kept, through @Aschenbath's resubmission. Thank you both.
When `rig queue create` gets no answer in time, or an unreadable one, the CLI now reads the row back once by its ID before it reports anything. The create is never sent a second time.
- A row that is exactly this create is reported as created: "The create committed after all: row … (read back by its ID)", exit 0, printed as for any create, with `--verify`'s delivery result when it was asked for.
- A row with that ID that isn't this create stays INDETERMINATE and names what differs (destination, source or body), with "Don't reuse this ID for other work".
- No row yet, or a read-back that fails too, stays INDETERMINATE and says why. The `--id` retry is kept.
"Exactly this create" means the same destination, the same body, and the source the daemon actually stores for this request. The CLI takes the sender it actually sent, canonicalizes it as the daemon does (trimmed, its own host suffix removed), and stamps the forwarding daemon's host id only on a genuine forward. A `--host` naming the daemon's own id is a local create, unstamped, by the daemon's own self-host rule. When the host id it needs can't be read, the outcome stays unknown. No host suffix is optional.
Before this, a daemon that answered after the deadline left the person with a failure or an unknown outcome while the row already existed, so an agent could create the work twice. #1911 made the timeout read INDETERMINATE; this adds the read-back on top. No new refusal, replay, route or flag.
`docs/reference/seat-delivery.md` said the typing guard has three modes. Since #1770 it has six. The page now lists `openrig-urgent`, `urgent-only` and `sends-only` alongside the others, in the intro, the mode table and the `--mode` line, using the CLI help's words. It also states the existing rule that lifecycle work is refused at `openrig-urgent` and `urgent-only`.
Docs only: +10/-5, one file.
The internal testbed image moves from Node 22.22.1 to 22.23.4 (CVE-2026-111497). Its download is checked against Node's official SHASUMS256, and the check binds the extracted archive, so a mismatch stops the build.
The scenario runner now settles its containers by recorded id instead of `rm -f`. It removes the cidfile only after a confirmed removal, so a re-run into the same folder isn't refused, and it prints a retained container's name.
This image isn't shipped. Its rebuild hasn't been qualified on its own: the first ordinary run of the route that consumes it is the proof.
After a power loss and `rig start`, a team of plain terminal seats that restored fresh now reads `fully_restored` instead of partial. A `builtin:terminal` seat runs no agent command, so a fresh shell is the whole seat. #1328 already relaunches such a seat fresh, but the restore rollup counted it as a lost conversation.
Restore now records `noConversation` on an ordinary terminal seat's result, using the same predicate that relaunches it fresh, and only when its saved startup actually ran. These still make a rig partial: an agent seat started fresh, a terminal with a resume token or a changed runtime, a terminal whose saved startup failed, and any failed, waiting or attention seat. `rig restore status` keeps older attempts' recorded verdicts.
`rig down`'s notice now names the terminal sessions it stops.
The real check stays Fleet's power-loss run on the 0.7.2 candidate.
ROADMAP.md's "Planned for 0.7.1" heading is now "Planned for 0.7.2", since 0.7.1 is out. It lists 0.7.2's selected themes, each marked "(if ready)": outside assistants over MCP, more harnesses as seats (Hermes, OpenClaw and Cursor), per-seat accounts, member permissions, stream decisions, and named people in Slack. The existing Subscriptions line moves with it, unchanged. No dates and no other changes.
A signed-out Codex 0.162.1 seat reports that sign-in needs attention and gives the existing `rig seat continue` hint, instead of waiting for the readiness timeout. This extends Aschenbath's #1967, which did the same for Codex 0.164.0, to the older chooser: its two-line introduction and three numbered choices.
The same shared matcher accepts the older heading as a second form. The panel must be complete and current: both heading lines exact, exactly three choices in order with one selected, and the continue footer last. Partial or quoted panels, unverified wrappers and a newer composer don't become sign-in gates. No text or keys are sent. Existing 0.164.0 matching is unchanged.
The available 0.162.1 capture covers the chooser only, so its API-key entry screen isn't newly qualified.
Source +11/-4; tests and fixtures +39/-17. No new setting, reason code or dependency.
Four lines in docs/as-built/arteries.md's regression log, in its existing form: date, issue, artery, and which layer missed it. Nothing else in the file changes.
- F1 (0.7.0 candidate), launch: a fresh Codex kernel stopped at Codex's hook review. Caught at the cut by native first-user and daily runs; missed by the stub layer. Fixed in #1824.
- B6 (0.7.1 candidate), launch and resume: an upgraded Codex seat stopped at "Hooks need review: 6". Caught at the cut by a native upgrade run; missed by source tests, stub scenarios and the installed-upgrade check. Fixed in #1948.
- Pane-only attention (0.7.1 candidate): a Codex seat at a prompt only its pane showed read as working. Caught at the cut by real work; missed by fixtures that all carried hook signals. Fixed in #1946.
- #1955, delivery: quoted approval text in a working Claude seat's output read as a waiting prompt. Present since 0.7.0, found during the 0.7.1 cut by real work, and fixed for 0.7.2.
The log exists so each line becomes a scenario; where one is owed, the line names it. Docs only: +4/-0.
ROADMAP.md stops listing work 0.7.1 already shipped. The five Planned 0.7.1 entries that the published release delivered are removed: team skills, interruption levels (including terminal presets), permissions, bundles, and community contributions, each matched to its merged milestone PRs and the published 0.7.1 release notes. The subscription entry stays, because 0.7.1's boundary record marks that increment partial. Nothing else in the file changes: no rewording, dates or new entries.
An agent can move one Codex seat to another subscription login with one command, and the seat keeps its conversation: `rig provider precheck --seat <seat> --to-account <name>` shows the Codex home the running seat uses, what the seat is doing and every peer on that home, and `rig provider switch --seat <seat> --to-account <name>` performs the move. Before this, `rig provider switch` always answered `failed_safely` with `switch_execution_not_yet_wired`.
How it works: the switch composes `rig auth`'s file operations, now in the daemon (`@openrig/daemon/codex-auth`, with the CLI path a re-export), and the in-place `rig seat restart --keep-conversation`. It plans the restart first, which stops nothing, and checks that the login is saved in that home. It then saves the outgoing login as a unique `before-switch-<time>` copy, never replacing an earlier one; a save that fails for any reason other than "no active login" stops the switch before anything changes. It activates the chosen login and restarts the seat in place. The report reads `rebind_in_progress` with the verify step, `failed_safely` with the way back, or `unknown` with the restart's recovery command, never retried. Switches on one Codex home run one at a time inside the daemon, and a switch that waited behind another rechecks its seat before it changes the login. Every same-home peer is listed with what will happen to it, from Codex 0.164.0's own source: it keeps its old login in memory until its next token refresh, then stops with "signed in to another account". Each peer gets a pasteable `rig seat restart <peer> --keep-conversation --reason ...` step, and the person is told not to sign in again in that home. After a CLI timeout, the message says the switch may still be running or queued behind another.
Limits: Codex seats only (a Claude seat is refused with `rebind_unsupported_for_runtime`), Linux only (the restart reads `/proc`), and the login must already be saved in the seat's own home. A restart that never settles holds its home's queue; switches there wait, and their CLIs report unknown after 120 s. Auth contents never enter returned metadata, logs or argv: files are copied by descriptor through a scrubbed buffer.
Validation: the new tests fail on main and pass now, including a failed outgoing save, two switches in one second, overlapping switches on one home, and a switch whose seat became ineligible or moved home while it waited. The provider-switch and route suites and the CLI tests pass, and the independent security review's real-file controls pass. Native proof with two logins in one home and a control seat is Quality's.
Claude can refuse a startup request, for example on an expired login, after OpenRig has checked readiness for the next startup input, so the next input could be pasted and submitted into the refused turn. OpenRig now checks again before that later input's Enter, using the existing refusal classifier. A visible refusal leaves the paste alone, holds the remaining inputs as owed, and reports attention required. The message says OpenRig pasted the next input but withheld Enter, so it may still be in the input box and shouldn't be resent. A fresh start keeps the fresh-launch recovery command; a resumed or forked start keeps its conversation and says to clear or send the staged text after signing in. `seat continue` can't replay the staged input.
Cost: one extra readiness observation per later Claude startup input, and manual inspection when a refusal leaves text staged; no added sleep or request-completion wait, setting or code. A refusal arriving after the final observation can still race Enter, so this isn't an atomic delivery guarantee.
Validation: an ordered no-model discriminator drives the real Claude readiness check, classifier and file delivery with simulated terminal I/O, using the retained native refusal frame. A refusal after the check, or after the paste, let the next Enter through on the old source (2 of 6 cases) and is held now. Healthy, stale-refusal and unavailable-capture controls keep their behaviour. The message correction failed four staged cases before it and passes now, and the startup-orchestrator, startup-submit-confirmation and native-resume-probe suites pass. Native invalid-login and same-home sign-in recovery remain unverified by this change.
Follow-up to #1869.
A managed seat can keep an unrelated project pane beside its recorded tmux pane. `rig send` and queue wakes now keep targeting the recorded pane instead of refusing the whole session because a sibling pane exists. The guarded write still requires the persisted bound pane to be present and writes to that immutable pane ID, not to the session's selected pane. The readers that decide whether the seat can take input read the recorded pane too: the readiness probe's terminal command and screen captures, the fresh-hook veto, the Codex foreground check (the session name is kept for identity), and the copy-mode cancel. The private unbound probe and other paths without an immutable managed pane stay single-pane strict.
Validation: a sibling-pane regression fails on main with `ambiguous-pane` and passes now; split-session tests where the recorded pane differs from the selected one cover the fresh-hook veto and the Codex foreground check, and the existing probe-context expectations now name the recorded pane. The native-claude-delivery, seat-delivery-guard and session-transport daemon tests pass, and lint covers the daemon build and typechecks.
Thanks to @Vaishnavi220506, and to @tianqizhao0704 for the precise report.
Sharing an exported team no longer silently omits its local culture file. `rig export` copies the declared file's bytes next to the YAML for a local daemon, creating declared subfolders, keeping any existing file or symlink with a check-it warning, and skipping a source or destination that would leave either folder. A missing, unsafe or remote source is reported as could-not-copy alongside the existing guidance, and the YAML export still succeeds. Export also names each seat whose agent ref leaves the folder, whether `path:`, absolute, or a relative `local:../` ref like the shipped starter team's, and says how to make it portable. It warns when the installed name remains `starter`, since a bundle's name doesn't rename the rig. The bundle guide covers archive vendoring, README inclusion and checking the culture file over localhost tunnels.
Cost: one declared culture-file copy on local export plus targeted guidance; no agent-tree copying, automatic renaming, new API or live-rig change. Remote and tunnelled exports still need the culture checked from the daemon host, and a successful export is still distinct from a portable, validated bundle. Validation: the escaping-relative-ref case fails before the fix and passes after; 31 export/import checks and the CLI typecheck pass at this head, and the first head's 148 focused checks and daemon build passed. The symlink fixture is skipped on Windows.
A pod-aware seat that has never successfully launched is no longer left at a tmux shell after a daemon restart. OpenRig persists the validated launch recipe when it materializes the seat, and when restore has no startup context and no resume request, it uses the existing validated pod launch effect to start a fresh harness. The seat's saved model, policy, effort, environment, session source, restore policy and cwd stay authoritative over the recipe's defaults. Resume stays fail-closed when there is no durable startup context. A recipe-backed fresh launch starts the provider harness and may consume provider usage; that is the intended consequence of repairing a seat that otherwise has only a provisional shell.
Limits: only pod-aware seats with a validated persisted recipe and a matching member definition fresh-launch automatically. The recipe's shape, including every member launch addition, is checked before the provisional shell is retired; legacy seats, malformed recipes and recipes whose member was removed surface attention_required with the shell and binding kept. A recipe is configuration evidence, not proof that the provider executable, credentials, workspace or external files are still available, so those checks stay in the normal launch path. The validated rig specification is stored per node so one seat can be rebuilt after a restart, a small storage cost for per-seat recovery. The new migration is 136_node_launch_recipe.
Validation: composed tests through the real restore-to-instantiator callback cover no recipe, invalid JSON, a malformed member addition and a missing member, each ending attention_required with the shell and binding kept, and the saved model, effort, Codex profile, cwd and permission policy reaching the launch input without stubbing the launch binding. Daemon build and lint pass, and the node-launch-recipe, restore-orchestrator and topology-ingress tests pass on the author's machine; six existing Windows path assertions are unrelated.
Refs #49. Thanks to @Vaishnavi220506.
A Claude seat that OpenRig compacts now gets its post-compaction turn boundary on the next poll, so its restore starts by itself. Before this, the boundary waited for whatever changed the screen next: about 70 s in a native Claude Code 2.1.309 run, when Claude's own 60 s idle notice happened to arrive, and 21 minutes on a seat whose activity hooks didn't reach the daemon, until someone typed to it.
Why it waited: right after `/compact`, every row above Claude's input box is indented compaction text and PostCompact hook output, so `findClaudeComposer` never reaches the status head within its 20-line window and the pane reads `unknown/no_activity_signal` by design. The post-compact drain is pane-only, because the newest hook can predate `/compact`, and the hook after compaction (`SessionStart` with source `compact`) reads unknown too.
The change: the managed compaction's turn-boundary send, and only that send, passes `postCompactTurnBoundary: true` beside `readinessFromPaneOnly` to the pane classifier. For that send, a complete framed empty Claude box with its mode footer reads idle when every row above it is Claude's tool or hook output, that is a `⎿` row or its continuation indented five or more columns, and none is a task-list row. That is the post-compaction screen. A working seat's streaming reply text (two columns in) or a task list pushing the live status out of view still reads unknown. Live status, a typed draft and dialogs are checked first and still refuse. Every other send, the restore and audit stages, the input-box check after an uncertain `/compact`, the typing guard and the occupant gates are unchanged.
Validation: the new file's cases fail on main's classifier and pass now, including the hidden task-list and streaming-reply screens and the real `SessionTransport.send`. 1,348 tests across the 35 daemon files that exercise the classifier, the activity probe and the compaction enforcer pass, and the daemon typecheck is clean. Replaying the native 2.1.309 run's 318 captures: all 91 stall captures go from unknown to idle, the 12 compacting captures stay active, and none changes outside the stall window. An unassisted native compaction is still to be run. Cost: source +38/-4, tests +165/-7; no new setting, refusal, code or timer.
A fresh Codex user who declined Codex's offer to remember an OpenRig command rule then approved 22 escalations one by one during setup (23 requests, one interrupted; 21 began with `rig`). The rigs skill now explains, when that offer is declined, that even routine status and screen reads may keep prompting, and offers the existing operator conversation. Only after the user explicitly chooses the operator route does the installer stop polling, and the operator follows the work through the team lead's queue task and its handoffs. The default Claude installer and a Codex installer whose user accepts the rules keep their existing relay and follow-through duties, and users who prefer the installer keep their chosen per-command approvals. The rules offer now says it applies from the next session, and both handoff routes carry the user's constraints and declined choices.
Text only: the rigs skill, its identical shipped copy and the kernel operator role. The existing optional command rule, sandbox and setup behaviour are unchanged, and general network access is not enabled as a workaround. Checks: diff check, docs guard, skills mirror check and byte equality of the two skill copies; text scenarios cover the Claude default, Codex accepting, Codex declining and choosing the operator, and Codex declining and staying. No native prompt-count improvement is claimed; a fresh-user native trial is Quality's.
Someone typing a multi-paragraph message in a Claude seat's input box that starts with a blank line could have an agent's `rig send` typed into or submitted with their unsent text: the box's empty prompt row plus its mode footer read idle without the continuation text being inspected. The classifier now reuses `composerRegion` just before its idle shortcuts: when the Claude prompt row is empty but the recognized box body has text, it returns unknown, so the typing guard and the composer's stop-and-show protect it. Codex seats are excluded, and the existing input guard, deliberate-input handling and delivery paths are unchanged.
Validation: the new fixture (a blank first prompt row, an indented draft on the next row, a framed box and the accept-edits footer) reads idle on unmodified source and unknown now; 216 tests pass across claude-warning-footer-readiness, composer-input and seat-delivery-guard. An independent base/candidate/composed matrix confirmed the change, that empty and whitespace-only boxes keep their result, that Codex's empty-placeholder box stays idle, and that it composes with the post-compaction boundary change in #1971. This repairs the tested blank-first shape, not every draft layout. Cost: 7 source lines and 7 test lines, no new refusal, setting or code.
When Codex is waiting at its initial sign-in chooser or API-key entry, startup now reports `attention_required` with `login_required` and a sign-in explanation, instead of eventually reporting a generic readiness timeout. Startup context stays pending, nothing is typed into the login screen, and `rig ps --nodes --json` shows the reason and the continuation hint through the existing startup and inventory path.
The shared probe requires a native Codex process, or the adapter's verified native descendant, and a current, complete login panel with nothing after it. It distinguishes older composer text above the panel from a newer composer below it, and an unverified wrapper is checked and recaptured before readiness or menu automation. Detection is limited to the captured complete English chooser and API-key layouts; other authentication screens keep their existing handling. Claude's refusal handling from #1417 is unchanged: its persistent "Not logged in" footer alone still doesn't prove a login blocker for gateway users.
Validation: fixtures captured from the official Codex CLI 0.164.0 in a fresh container with no credentials and networking disabled, covering the chooser and API-key screens in wide and narrow terminals and managed --no-daemon launches. The new regressions fail on the original probe; 558 focused readiness, adapter, startup and inventory tests pass. The startup regression uses the real Codex adapter with captured terminal content, real SQLite persistence, the nodes HTTP route and the CLI JSON projection, and checks the attention status, the login explanation, held startup context and zero delivered files or keystrokes. This verifies recognition and startup propagation, not a completed native login. docs/reference/help.md covers finishing the sign-in and continuing.
Addresses #6. Thanks to @Aschenbath.
When the stuck sweep closes its own finding, its transition history and `queue.updated` event now name `stuck-sweep@system` as the actor. Previously they credited the finding's source agent with that automatic action. The finding keeps its source, destination and claim, and the underlying work is unchanged. The closure query no longer reads the unused `source_session`, and the coordination architecture document explains the difference between ownership and the actor.
Addresses the closure-attribution part of #1419, following the retry-suppression fix in #1449. It covers attribution only, not every delivery or pickup evidence-policy case in that issue, and existing transition history isn't rewritten.
Validation: three regression cases failed before the fix, recording the source agent instead of the sweep, and pass after it; 183 tests pass across the stuck-sweep, human-custody, wake-ladder and pickup daemon files, covering pending and claimed findings, durable transition and event actors, unchanged ownership and source work, and no second closure on the next sweep. A posted human notice keeps the person's original ask open. Build, lint and the UI tests pass.
Thanks to @Aschenbath.
At startup the daemon checks whether another running OpenRig daemon already has the same database open. An inconclusive check used to read exactly like a clean one, so someone who turned on `daemon.db_conflict=stop` got no sign that it hadn't run. Now a check that can't get an answer adds one warning to the existing database-warnings list, which reaches `rig daemon start` and `/healthz`, with either setting: "Couldn't verify whether another daemon has database <db> open (<reasons>): ownership is unknown, not confirmed clear. Startup and database writes continue", plus, under `stop`, that it stops only on a confirmed conflict.
`lsof` now reports why it had no answer (not installed, timed out, or failed); exit status 1 stays a clean "nothing holds this". A matching record whose listener doesn't answer, times out, or gives an answer that can't be read (the body aborts, or a 200 isn't JSON) is unknown. A holder whose own files can't be read is unknown unless a record confirms it. Definite answers stay non-conflicts: a record for another PID or database, an unreadable record, and a listener answering for a different PID. The stop is unchanged: `daemon.db_conflict=stop` still stops only when an open-file holder, a matching `daemon.json` and a listener reporting that PID agree, and the confirmed-conflict path, its message and `--allow-db-conflict` are byte-for-byte as before. getting-started.md gains one sentence. Known limit: a recorded listener answering non-200 still adds no warning, as before.
Credit: Calvin Edwards (@calv-io-n) found that an inconclusive check reads as no conflict, in factory-level/plantworks#114; that change refused the start on an unknown result, and this one says so instead.
Validation: daemon-db-conflict.test.ts runs the real createDaemon to its first database open with fake lsof and fetch: missing, timed-out and failing lsof, a slow or unreadable listener answer, and an unreadable holder each warn in both modes without stopping; clean boots add no warning; the existing confirmed-conflict, go-ahead and cross-home cases are unchanged. 17/17 there and 7/7 in daemon-db-path.test.ts; the independent review's 9 controls pass. Cost: source +43/-13, tests +75/-2, docs +3; no new refusal, stop, setting or code.
When a seat waits at an approval or question prompt and its tmux pane is smaller than a standard terminal, the prompt can be cut off, so `rig capture` showed only the bottom of the menu ("1. Yes 2. No") and whoever was looking couldn't see what the seat was asking. Now `rig capture` and the MCP capture tool check whether the captured screen is at a permission or selection prompt, and read the pane's size only then. Below 80x24 the result carries `promptPane: { width, height, hint }`, and the CLI prints the hint on stderr, for example: pane 18x12 is smaller than 80x24, so the prompt may be cut off; resize it (tmux resize-window -t =<seat>: -x 120 -y 40) and capture again. The command includes the daemon's tmux server flags when it doesn't use the default server, and targets `=<seat>:`, the seat's own session's current window, so a same-named window in another session is never resized.
Other capture callers are unchanged and make no extra read: send verification, walk, the previews and attention recovery. There's no polling and no new setting, and `rig capture --help` describes the note.
Validation: the tests alone fail on main for the small-pane note, the route asking for it and the CLI stderr note, while the no-change cases pass (a normal-size pane, a shell in a small pane, a caller that doesn't ask). A real private-tmux control, with a window named like the seat in another session, failed on the first head (it resized that other window) and passes now, including for a seat name with a space and an apostrophe. 312/312 across the capture, tmux-server and session-transport daemon files and 19/19 in the CLI capture tests.
A team imported with `--materialize-only` could not start one ordinary seat: launch entered restore and reported “no startup context.” Retain each materialization’s declaration in the existing startup record, then let positional `rig launch <rig> <seat>` use the shared validated-spec launch ingress for that never-occupied seat. Resolve it with current saved settings and policy provenance, reporting changes from the declaration. Other seat records and IDs stay intact; successful first start captures context for later restore.
Cost and limits: one retained declaration per materialization, no migration or setting. Source files must remain available. Present or indeterminate targets and consequential races stop with distinct remedies; ordinary metadata edits do not refuse. Old materializations are not retrofitted. Explicit snapshot/subset launches remain restore; `--plan` remains restore selection.
Validation: the unchanged topology-ingress pin fails before the final correction and passes afterward, alongside all 17 HTTP/SQLite first-start controls. Daemon typecheck and daemon/CLI/TUI builds pass. The local full daemon run had 1,171 passing files, 39 failing and 4 skipped; after fixing missing local builds and temp/tmux environment prerequisites, all 39 failed files passed one qualification (210 checks). The latency control passed separately at 43.4 ms against its unchanged 250 ms budget. The original full run remains red; this is not a single clean full-suite pass. Fake runtime/tmux adapters cover authored startup and preservation; native provider readiness is untested.
An agent that reaches OpenRig through MCP (a desktop app, or an assistant on `rig mcp serve --http`) could claim and close an item but couldn't hand it on, so passing work along meant close-and-create, which loses the link a delegator follows. Two work tools now call the daemon's existing routes, the same ones `rig queue handoff` and `rig queue unclaim` use. `rig_queue_handoff` closes the item as handed off and opens its successor in one transaction, with lineage in `chainOfRecord`; the task's text, tags and priority carry over unless given, and a note, summary and person-route `evidenceRef` are optional. `rig_queue_unclaim` returns an in-progress claim to pending for the same seat with its reason recorded. Both are annotated destructive.
Scope for an authenticated caller matches `rig_queue_update`: the item's owner must be in scope, and a handoff's next seat too, so it never reaches a seat outside the grant or a person. A timeout says the outcome is unknown and to check `rig_queue_show` before retrying; a repeat after it landed answers `qitem_already_terminal` and creates nothing. The server instructions gain one sentence, and the openrig-user skill, its digest and the capability map's MCP sentence are updated (36 tools, 19 work tools). Not included: cross-host handoff, `targetRepo`/`gate`, `fallback`, hosted grants, the 2026-07-28 protocol and principal attribution.
Cost: source +58/-1, tests +92/-10 in 3 files (about 1.6 test lines per source line), docs +15/-9. No new refusal, error code, route, setting or dependency. Validation: 70/70 across the four MCP queue/HTTP/server/operations files and 9/9 in the other server-building MCP files; 8 of the new cases fail against main's `mcp-server.ts`. The independent security review ran 74/74, including real HTTP grants whose owner and destination scope checks each fail when removed. HTTP fixtures use in-memory SQLite and inert delivery, not native desktop-client or remote deployment proof.
An open rig view keeps a seat’s tile when its tmux session is replaced. The shared command waits up to 30 seconds for the same session name and managed node identity, then reattaches by exact tmux ID. It checks the name returned by tmux before reading identity, so a missing target cannot select a sibling. Removed or absent identity markers keep one-shot attachment. Herdr reuse and TUI/CLI copy guidance read the separate short recovery command.
Cost: one shell per tile, with metadata polling only while disconnected. A deliberate detach takes about two seconds to close; a replacement delayed beyond that live-session grace can require reopening. Close and reopen views created before this change. No watcher, setting, schema or provider-specific recovery mechanism.
Validation: real private tmux reproductions cover four-seat replacement, removed identity, a missing target during replacement, and disappearance before opening; each fails before its corresponding fix. The last two exposed the CI failure without increasing any timeout. All 458 affected terminal contract and CLI window checks plus the daemon typecheck pass locally at this revision. Earlier round checks also covered TUI rendering and CLI/TUI typechecks; those were not repeated for this shell-only correction. Tests use the actual stop adapter/composer because the scenario runner has no terminal-view action. Native Herdr/cmux/Rex apps and SSH were not run.
Addresses #1939. Native Herdr, cmux and Rex and real SSH were not run, so the issue stays open for the reporter to confirm.
## What this changes
Two comments, and no logic. They now say how much of the quoted-prompt veto's (#1955) premise has been observed natively.
The veto treats prompt-looking text above Claude's empty input box as quoted output, but only when Claude's own timer row runs directly above that box. That rests on one fact about Claude's screen: a real dialogue replaces the input box, rather than being drawn beside the running timer row.
## Why
#1955's comments stated that fact outright and pointed to "the native captures here". One of those fixtures, `claude-permission-2.1.300`, holds transcribed menu excerpts rather than full screens (its `.md` says so), so it can't show where a dialogue sits. #1955's PR body was corrected at the time, with the claim labelled an inference until a native check.
## What the native check showed
The check ran on Claude Code 2.1.309, on #1955's fix and on a build without it:
- **Protected dialogues:** the MCP enable menu, a Read permission dialogue and an AskUserQuestion picker each replaced the input box, and each refused a send.
- **Parallel calls:** this included a turn with two Read calls issued in parallel. Twenty sampled frames show the waiting dialogue, and none shows it beside a hook timer row.
- **Fix versus no fix:** quoted selector text, and a permission phrase in a running Bash command, refused a send and a queue wake without the fix, and were delivered with it. That held in the fresh running-hook window too.
**Not covered:** other Claude versions, macOS, Codex (not run), and any layout the run didn't exercise. The comments say the observation covers the exercised layouts, not every version.
## The changes
- **`session-transport.ts`, the timer-row comment in `classifyPaneActivity`:**
- states the dialogue geometry as natively observed on 2.1.309, including parallel Read calls;
- scopes it to the layouts exercised.
- **`claude-quoted-prompt-veto.test.ts`, its header:**
- the same statement;
- names which fixture shows geometry: the 2.1.289 picker is a native screen. The 2.1.300 permission menus are excerpts, so they test only the menu text.
Comment lines only: +12/-6. No code, test assertion, matcher, refusal or setting changes.
## What a user gets
An agent that sees `stale`, or two copies of one skill with different hashes, in `rig skill audit` learns what that means before it refreshes anything:
- **What the audit is:** a date and hash finding, not a judgment of whether the copy is safe to refresh.
- **What answers "can I refresh this?":** the existing read-only check, `rig skill loadout` without `--apply`, and what each of its answers means.
It also learns where nothing can answer: a global or untracked copy has no install record. So it doesn't overwrite a copy whose history is unknown, and doesn't treat every difference as a deliberate fork.
## The change (text only)
**`rig skill audit --help`** now says:
- **What the audit reports:**
- declared provenance;
- whether a verified date is within 90 days and names an evidence source (`stale_verified` and `bare_verified`, which are state `stale` in `--json`);
- the content hash;
- whether a copy is byte-identical to a bundled plugin skill.
- **What it doesn't:** whether a copy is safe to refresh.
- **For a managed copy in a working folder, the read-only check:** `rig skill loadout --runtime <claude-code|codex> --cwd <target> --project-root <project> --json`, without `--apply`. Its answers:
- `current`;
- `stale`: still OpenRig's last projection, so `--apply` can refresh it;
- `conflicting`: read the detail. It can also mean the target couldn't be inspected, so any difference is unknown, and a confirmed difference doesn't prove a deliberate edit;
- `shadowed`: read the detail;
- `missing`.
- **`rig skill loadout --seat <session|self> --json`** (0.7.1 and later) lists a seat's own skills and where they're stored, without classifying them.
- **A global or untracked copy:** its origin stays unknown. Ask the skill's owner, and don't move global skills into a project just to get a record.
**The audit's human output** gains one closing line, on PASS and FAIL: the audit doesn't say whether a refresh is safe, plus the read-only `loadout` command and a pointer to `--help`.
**`docs/reference/project-workspace.md`:** one paragraph in its managed-skills section says the same.
No new check, refresh, classification or record.
## Checked against the source
- **`packages/daemon/src/domain/skill-audit.ts`:**
- **freshness:** the 90-day window (`FRESHNESS_WINDOW_DAYS`); `stale` is set for `stale_verified` or `bare_verified`.
- **content hash:** `hashSkillFolder` hashes the folder's top-level files.
- **bundled match:** requires the plugin's exact file set and bytes.
- **refresh state:** the audit reads no ownership record and classifies none.
- **`packages/daemon/src/domain/skill-catalog.ts`, `classifySkillProjectionTarget`:**
- **`current` / `shadowed`:** an equal digest, owned or not;
- **`stale`:** an owned target still at the prior projection, "can be refreshed safely";
- **`conflicting`:** a different digest, and also the `catch` when the target can't be inspected;
- **`shadowed` also covers a kept copy:** a same-named unowned skill, or an owned plugin copy edited after projection, as its detail says.
- **The read-only `--seat` inspection** (`inspectSeatSkills` in `seat-skill-apply.ts`) lists skills, storage and delivery without per-copy statuses. Those come only with `--apply`.
- **`--seat` is first in 0.7.1:** it's in the 0.7.1 line and not in 0.7.0's `skill.ts`.
## Proof
- **RED:** the two new cases in `packages/cli/test/skill.test.ts` fail on main's `skill.ts`.
- **GREEN:** the file passes, 6/6.
- **Not run locally:** the CLI typecheck, which CI covers.
## Cost
- **Source:** +21 lines in one file, help text plus one output line.
- **Tests:** +21.
- **Docs:** +18.
- No new option, setting or refusal.
## What a user gets
A managed Claude restore reads the generic `post-compact-extra.md` without stopping at a Read approval. The same holds when the compaction
settings move the extra instruction file or the restore maps somewhere else, when the configured file is a symlink, and when the setting
has stray spaces around it.
## Why it happened
#1940 grants a seat's restore reads as `Read(//…)` allow rules. It covered the per-seat `<home>/compaction/post-compact-extra/<seat>.md`.
When a seat has no per-seat file, the restore request names the generic `<home>/compaction/post-compact-extra.md` instead (the default
`policies.claude_compaction.message_file_path`), and nothing granted it. A managed restore on a Claude seat with OpenRig's core plugin
stopped there at an approval; one approval let it finish.
The two compaction settings that move these files had the same gap:
- `message_file_path`, when set to another file;
- `preparation_root`, where restore maps go when it's set.
## The fix
- **The generic file is always granted.** The restore request names it even before it exists, so whether it exists at launch says
nothing about the restore.
- **The configured extra file and `<preparation_root>/<seat>/*/RESTORE-MAP.md` are granted too.** Both Claude launch paths (fresh or
fork, and resume) take an optional `restoreReadPolicy`. The daemon resolves it at each launch from the same compaction settings the
restore uses. Without it, the grants are as before plus the generic file.
- **The configured file is granted as the restore request names it.**
- It goes through the same trim as the restore's resolver, one shared helper, so a padded setting grants the file the request names.
- The whole file, not only its directory, is resolved, so a configured file that is itself a symlink has its target granted too.
- The grant is still that one file at its two spellings.
- **Every rule is at both spellings,** the resolved path and the real path, as in #1952.
- **Still not granted:** the session transcript, which the restore request names only when both the restore marker and a restore map are
missing.
- **Not covered: a relative `message_file_path`.** The restore request names it as written, relative, while the grant resolves it under
the daemon's working directory, which can differ from the seat's. Such a seat still gets an approval, so it fails safe. An absolute-or-empty
check like `preparation_root`'s would close it, separately.
- **A test pin:** `s03-bound-launch`'s check of `startup.ts` text now expects the new constructor line.
Source: +42/-8 in five files (`managed-restore-read-access.ts`, `claude-compaction-enforcer.ts`, both Claude adapters, `startup.ts`).
## Tests
- **New:** the generic file, a configured extra file and a configured preparation root are each granted at both spellings, and nothing
else in those directories or another seat's maps is; both Claude launch paths grant the configured extra file the restore will name.
- **A parity test** renders the restore request the enforcer actually sends, and checks every file it names against the granted rules,
where it's named and where it resolves. It runs for the default settings, a configured extra file and preparation root, a configured
file that is a symlink, and a padded setting. So a restore file added later without a grant fails here, not at a native approval.
- **#1940's exact-list cases** now expect the generic file.
RED, the tests alone on main (`c061d705`, run 40151781330): exactly 8 tests fail, all in `managed-restore-read-access.test.ts`. They are
the six launch-shape exact-list cases and the two new tests. Nothing else fails.
GREEN at `f6566d9b` (run 40154339522): all 8 jobs pass.
Round 1 RED, the parity test alone on `f6566d9b` (`de3ebe30`, run 40157449038): exactly the symlinked-file and padded-setting cases
fail; the default and configured cases pass, and nothing else fails.
Round 1 GREEN at `4f6b804b` (run 40157573273): all 8 jobs pass.
The managed restore case that stopped at the approval still needs a native rerun after merge.
The parked-owner watchdog reminds a seat that is idle at its prompt while it holds open queue rows. It ran on its next 120 s tick, so a seat that had just handed work to a peer, or just asked a person a question, got "You are parked …" within a couple of minutes of ending its turn. It then spent a turn on the reminder, or re-asked the person.
**What changes**
- The parked diagnosis reports `activity.since`: when the seat's arbitrated state last changed (its activity, or its needs-input count, reason or evidence rung). For a stopped seat, that's when its current waiting state began.
- The parked-owner consumer skips a seat whose waiting state has been unchanged for less than 5 minutes, recorded as `waiting-grace` in the evaluation notes. A seat still idle with its rows after that is reminded on the next watchdog tick, exactly as before. If the start isn't known, the reminder goes as before.
- A seat at an approval or question prompt gets no grace. The consumer's refused attempt there is what starts the prompt-blocked alert to whoever can clear the prompt, so that alert is not delayed.
- The reminder now tells a seat waiting on a person's answer not to ask again, and to hold the row with `rig queue block <id> --on <who> --wake-after <duration>` (a hold on a person also needs `--summary` and `--evidence-ref` unless the row has them).
- A held row with a live wake still doesn't count as parked, so that hold keeps a long wait quiet.
- There's no new setting. Both cases in the report end the seat's turn, so one default covers them.
- `docs/reference/seat-delivery.md` describes the grace and the prompt exception.
**Tests**
- RED, the first tests alone against main: 3 failures.
- a seat that started waiting 30 s ago is reminded on that tick;
- the grace doesn't reach the consumer through the shipped diagnosis;
- the diagnosis has no `since`.
The cases that keep today's behaviour pass on main too: the reminder after the grace, and the reminder when the start is unknown.
- RED, the prompt test against the first fix: a seat stopped at a prompt 30 s ago was skipped instead of attempted (1 of 37).
- GREEN: 247 of 247 across the 11 daemon files that build the parked consumer or call the diagnosis.
Addresses #1933.
## What a user gets
Some Codex users keep their hooks in `hooks.json`. Before this change, OpenRig always added its activity hooks as an inline block in
`config.toml`, so their Codex home mixed both formats and Codex warned about it at startup. Now, when a Codex home has a `hooks.json`,
OpenRig puts its activity hooks there and moves its own old inline block out. A Codex home without a `hooks.json` gets exactly what it got
before.
Your own hooks, their order, their trust and your disables stay as they were. This covers OpenRig's own block only: if you keep your own
inline hooks in `config.toml` beside `hooks.json`, they stay where they are, and Codex may still warn about that mix.
## How it works
- **OpenRig's groups:** one group per activity event (`SessionStart`, `UserPromptSubmit`, `Stop`, `PermissionRequest`), marked with
`statusMessage: "OpenRig activity"`, which is also what Codex shows while the hook runs.
- An existing OpenRig group is replaced in place.
- Otherwise the group is appended after your groups, so your groups keep their positions, and Codex's trust is keyed by position.
- **Recognising OpenRig's group:** only its exact authored shape counts. That's one handler with only OpenRig's fields, its timeout and its
label, running the activity relay from where OpenRig ships it (this install or an earlier one). A group of yours that runs your own
script, even one with the same file name and label, is left alone, and OpenRig adds its own.
- **Trust:** written only for OpenRig's groups, keyed by the real path of `hooks.json`. Your groups are never trusted on your behalf.
- **OpenRig's old inline block** in `config.toml` moves out. If you had disabled one of its hooks in Codex (`enabled = false`), the disable
moves to the hook's new `hooks.json` key.
- **Turning hooks off** (`runtime.codex.hooks_enabled: false`) removes only OpenRig's groups. Codex keys trust and disables by position, so
when a removed group sat before yours, your later groups' trust and disables move with them to their new positions.
- **Both files are checked before anything is written.** The proposed `config.toml` must parse and equal the current one plus exactly the
planned fields. Otherwise neither file changes, and a warning says so. The same applies to a `hooks.json` that can't be read as hooks.
- **Per-seat homes:** a seat with its own `CODEX_HOME` uses that home's `hooks.json`.
## Credit
fsafey/openrig#7 found this problem and handled more cases. The disable migration and the trust re-keying on removal here follow the same
idea. Not carried: a warning when your own inline hooks remain beside `hooks.json`. Your hooks are left where they are.
## Tests
`codex-activity-hooks-json.test.ts` covers:
- OpenRig's groups added after yours, and trust for exactly them;
- the old inline block moved out, while your inline hooks stay;
- idempotence, and a new relay path replacing OpenRig's group in place;
- a malformed `hooks.json` left alone;
- removal;
- a seat's own `CODEX_HOME`;
- no `hooks.json`, which gives today's block.
**Round 1 adds:**
- a disabled inline hook moving disabled, with the enabled case as a control;
- removing OpenRig's group from between two of yours, so the later one keeps its trust and disable;
- a quoted `"trusted_hash"` that would have become a duplicate key, which now leaves both files untouched;
- your own relay with OpenRig's file name and label, which is kept, and OpenRig's group is added after it.
Round 1 RED, the tests alone (`7a6b2e81` on `9f4cbe98`, run 40151455871): exactly the four new tests above fail; the enabled control
passes, and nothing else fails.
Round 1 GREEN at `30069c00` (run 40155470675): all 8 jobs pass. The first fix head, `50550a57` (run 40151457584), failed two removal
tests. Its check before writing compared a planned `config.toml` holding an empty `hooks.state` table against text that had dropped the
table with its last entry, so it refused and left OpenRig's groups in place. `30069c00` compares the two without an empty table, which
means the same as none.
Thanks to @fsafey, whose PR in their fork found the mixed-format problem and showed where trust is keyed.
## What a user gets
A queue wake refused at an approval prompt retries once when observed attention clears to work or idle, instead of waiting for the stuck sweep. Hook updates and changes in existing pane captures use the same activity resolver as status; the prompt refusal and all delivery checks remain.
## How you verified it
Baseline: three missed-retry assertions fail; the existing sweep control passes. With the change: 114 checks pass across focused queue, outbox, structural activity, wake-ladder and startup suites, including a real hook update through the assembled queue and a split correlated return whose uncertain sibling stays outside the clear retry. General recovery of that sibling remains covered. Daemon typecheck passes. No native model run; tests use real SQLite and domain code with simulated transport results and pane frames. Required CI is pending.
## Anything you were unsure about
Only pending prompt-refused wakes qualify. Existing outbox claims preserve the frozen notification and exclude delivered, uncertain, retained or active sends; legacy nudges retain their existing path. Unknown observations do not clear attention, and a retry refused again stops until another observed clear or the existing backstop. No new timer, schema, reason code, or extra capture. Cost: +51 net source lines, +144 test lines (2.67 added test lines per added source line), a small session set and one destination-scoped recovery pass per observed clear. A clear the daemon never observes still relies on the sweep.
## What a user gets
In a Slack channel where many agents post, the person sees who is asking before the ask. Every gateway post now starts with its sender, `From <seat> on <machine>`:
- as the first block, above the headline;
- as the first line of the fallback text a notification shows.
Before, it was the last block and the last line.
A wake-rung escalation (the queue's last rung, which posts a stuck row to a person) now says which seat the work is waiting on: `Waiting on <seat>: <the row's summary>`. Before, it showed only the row's summary, often with no seat named at all.
## The change
- **`slack/message.ts`:**
- the sender line moves to the front, in both the blocks and the fallback text, and now reads `From …`;
- it's still named once, with the same caps and the same fallback budget;
- at Slack's 50-block limit the repeat note is still the block left out. It's now found by identity, since it's no longer the second block.
- **`operator-delivery-engine.ts`:**
- the escalation's summary names the seat the row is waiting on;
- its sender is unchanged: the row's own. So a reply in the thread still goes where the row's posts go;
- a row with no sender is still signed with the queue's place. The stuck seat didn't send the escalation, so it isn't shown as the sender.
- **Not in this change:** a separate "what you need to do" line. No row field holds a one-line ask (`humanIntent` is `decision` or `update`, and `humanDetail` is free-form), and this change adds no parsing.
## Tests
- **New** (`slack-sender-first.test.ts`):
- the sender is first, and named once, for a full session, for a session plus its machine, and with no seat;
- the 50-block limit drops the repeat note, never the sender or the ask;
- the escalation headline names the waiting seat, with and without a row sender, while the sender stays the row's own.
- **Fail-first:** all 6 new tests fail on main.
- **Existing tests that pinned the old order** (the sender last, the body at block 1, a lowercase `from`) are updated to the new order in five files.
- **After the change:** all 80 Slack, gateway and delivery test files pass (1,186 tests), and daemon `tsc --noEmit` is clean.
## Docs
`docs/reference/slack-app-setup.md` now says each post starts with its sender.
## What a person gets
Take a row that was claimed, parked (blocked) for an hour, then resumed with `rig queue update --state in-progress`. If it then went quiet, the stuck sweep could report "stalled-after-claim on <row> (77 min)". In fact it had been active for about 7 minutes, and the finding's own "why" line said so: "no meaningful queue change for 7 min".
Now the headline and the body's `age:` line count from the same moment as the stall decision, and round the same way, so all three agree to the minute.
## Why it happened
Line numbers are at `c3c514f2` unless marked "this head".
- **Which clock the age used:**
- A stalled candidate's age came from the claim time: `ageMinutes: minutesSince(row.claimedAt, now)` (`queue-stuck-sweep.ts:467`).
- That age is printed in the summary (`:743-745`) and in the body's `age:` line (`:400-406`).
- **Why that clock included the park:**
- `claimed_at` is written only on claim (`queue-repository.ts:2570`, `:2579`).
- The generic state update that resumes a parked row (`:3165-3173`) doesn't touch it, so the claim time still counts the parked hour.
- **What the decision already used:**
- The stall decision itself anchors on the latest of claim, last meaningful change and post-claim heartbeat (`queue-pickup.ts:98`), and its evidence floors the minutes (`:101`).
- `minutesSince` rounds instead (`queue-stuck-sweep.ts:308-312`). So the headline could also differ from the "why" by a minute even without a park.
## The change
- **The age:** for stalled-after-claim candidates only, `ageMinutes` now comes from the candidate's existing `evidenceAt`, which is the same anchor as the decision. It's floored by a small `wholeMinutesSince` helper (`queue-stuck-sweep.ts:316`, this head), and assigned at `:478` (this head).
- **What doesn't change:**
- which rows are judged stalled;
- `evidenceAt` / dedup / recurrence;
- routing and `claimed_at`;
- every other finding kind's age.
- **Two regression tests** in `queue-stuck-sweep.test.ts`:
- claimed → parked → resumed → quiet: the summary and body count minutes since the resume, not since the claim;
- a 30 min 40 s stall reads 30 in the headline, the body and the "why" alike.
- **Limit:** a finding that's already open keeps its stored text. Only findings created after this change get the corrected age.
## Overlap
#1313 ("distinguish input waits from stalled claims") edits `queue-pickup.ts` and `queue-stuck-sweep.ts` too, but not this age. This change touches only the sweep's helper and that one assignment, so whichever lands second rebases.
## Checked
- **Tests:**
- With the fix: all 16 test files on the sweep and pickup paths pass on this head, 373 tests.
- Without the fix: against the old `queue-stuck-sweep.ts`, exactly the two new tests fail (102 pass).
- **Review:** an independent review found nothing to change. It confirmed `evidenceAt` is the same anchor as the decision, and that the age stays a display field read only after the stall decision. It ran `queue-stuck-sweep.test.ts` on an export of this exact head (104/104).
- **Merge:** it merges cleanly with current `main`.
## Cost
One helper, one assignment, two tests (+48/−4). Display only.
## What a person gets
`rig seat restart --keep-conversation` restarts a Codex seat in place. When that restart can't prove the resumed conversation, the result used to end with this:
> The original Codex exited, but the resume was not proven: Codex resume could not be proven within the resume window: … The session was preserved; nothing was restarted.
The last sentence was false: the pane had restarted. It now reads:
> The pane restarted: the original Codex exited and the resume started in the same pane, but it wasn't proven: Codex resume could not be proven within the resume window: <reason>. Check the pane with rig capture <seat>.
- **Same fix, second case:** an in-place restart whose records name a different conversation (disproved, not just unproven) gets the same correction.
- **`account.startupGate`** no longer carries the false sentence either.
- **Other paths, unchanged:** every other caller of the adapter, where nothing was restarted, keeps its existing wording, which is true there.
This follows up #1950, where both readers noted the sentence. #1950 fixed one cause of an unproven resume, the home lookup; this corrects the message for every other cause.
## The change
Wording only. There's no change to proof logic, timing, launch, recovery or outcomes.
- `codex-runtime-adapter.ts`: the unproven and disproved results also carry the detail without the closing sentence, in a new optional `resumeDetail`. The existing `error` text is unchanged.
- `runtime-adapter.ts`: that optional field, with a doc comment.
- `seat-restart-in-place.ts`: the in-place `incomplete()` result uses `resumeDetail` and says the pane restarted. `remainingStep` is unchanged.
- `seat-restart-in-place.test.ts`: two cases, unproven and disproved, driven through the adapter and the restart service. The result says the pane restarted and never says "nothing was restarted", and the adapter-level error keeps its existing text for the other callers.
**Launch and resume is an artery** (`docs/as-built/arteries.md`). Only text changed: nothing that decides proof, timing or recovery reads the new field.
## Checked
- **Tests:** the three test files that cover these messages pass in full on this head: `seat-restart-in-place` 106/106, `provider-sign-in-fact` 30/30, `codex-rebuild-permissions` 13/13. Against the old source, exactly the two new cases fail and the other 104 pass.
- **Review:** an independent review found nothing to change. It checked:
- that both callers of the in-place result come after the original process was stopped and the resume started in the same pane;
- that earlier stop and respawn failures keep their existing paths;
- that the new field has no consumer that makes a decision.
It also ran the in-place file on an export of this exact head (106/106).
- **Merge:** it merges cleanly with current `main`.
- **Not done:** no live seat was restarted for this.
## Cost
Message text, one optional field, and two tests (+38/−5).
## What a person gets
`rig queue update --help` lists `canceled` both as a `--state` value and as a `--closure-reason` value. So the natural way to cancel a row looks like this:
```
rig queue update <id> --state canceled --closure-reason canceled
```
The daemon refuses that with `closure_fields_not_admitted`, and until now nothing said what to type instead. Now:
- **The help says it.** The description gains "To cancel a row: --state done --closure-reason canceled." The `--closure-reason` text now reads "Required for state=done. --state canceled takes no reason, except 'superseded' (with --closure-target = the successor), which records a supersession, distinct from an abandoned cancel."
- **So does the refusal.** The `closure_fields_not_admitted` message ends with "To cancel it: --state done --closure-reason canceled." The error code, the HTTP 400 and the CLI's exit code 1 are unchanged.
## The change
Text only. There's no change to which forms are accepted.
- `packages/cli/src/commands/queue.ts`: the `queue update` description and the `--closure-reason` help.
- `packages/daemon/src/domain/queue-repository.ts`: one sentence added to the refusal message.
- Tests:
- `packages/cli/test/queue.test.ts`: the help says how to cancel a row;
- `packages/daemon/test/sweep-a-closure-coherence.test.ts`: the refused form's message names the working form.
The wording is deliberately narrower than "closure fields go only with `--state done`". That wouldn't be true: parked rows, handoffs and supersessions also carry closure fields.
## Checked
- **Tests:**
- With the fix: both changed test files pass in full (daemon 7/7, CLI 165/165).
- Without the fix: both new tests fail against the old source.
- The built CLI's `--help` shows the new text.
- **Review:** an independent review found nothing to change. It checked the wording against the closure validator and the existing plain-cancel and supersession tests, and ran both new tests.
- **Merge:** it merges cleanly with current `main`.
- **Credit:** reported by the QA lead and a team lead, who both hit the refused form while closing rows during a release check.
## Cost
Help and error text only, plus two tests.
## What a user gets
A send or queue wake to a Claude seat that is plainly working is no longer refused as "at an approval prompt" just because the seat quoted approval-prompt text in its own output, such as a selector like `› 1. Yes, proceed (y)` or "Do you want to proceed?".
Real approval dialogues stay protected: the permission dialogue, AskUserQuestion, and the MCP server menu.
## The defect
`classifyPaneActivity` looks for prompt signatures in the last 12 non-blank lines: numbered selectors, plus phrases such as "Do you want to proceed?". Quoted text matches as well as a real dialogue does.
- **The ordinary pane probe:** a quoted selector reads as `selection_prompt`. This is pre-existing and was observed on a working seat.
- **#1864's fresh running-hook path:** this path narrows selectors to the current dialogue, but still scans the permission phrases across the whole window, so a quoted phrase reads as `permission_prompt`. This was found by reading the source and hasn't been seen on a real seat.
Either way the send is refused with `target_needs_input`, and delivery stalls until someone notices.
## The fix
One condition in the existing detector, `session-transport.ts` +9/-2.
- **When it applies:** for a Claude read, when Claude's own timer row (for example `✶ Churning… (12s · …)`, including the `running … hook` form) runs directly above its complete, empty input box. The box must be framed, with a recognised mode bar.
- **What it does:** the turn is running and no dialogue is open, so the prompt scan ignores the text above that box.
- **Only the timer row counts.** A selector-shaped "mid-work" line doesn't, so a prompt whose selector sits just above the box isn't mistaken for work.
- **What stays protected:**
- A dialogue that replaces the input box never meets the condition, because no empty input box is at the bottom. The native AskUserQuestion capture (`claude-question-picker-2.1.289.json`) shows that layout.
- **Correction (provenance):** an earlier version of this body cited the 2.1.300 permission fixture as showing this. It doesn't establish screen geometry: `claude-permission-2.1.300.md` says those are ConPTY menu excerpts with separators removed, not full-screen captures. No retained full-screen native capture shows where a Claude permission dialogue sits, or one beside a running hook timer.
- **So this is an inference [I]:** "a real permission dialogue never shows beside Claude's running timer row above an empty input box". That includes parallel tool calls, where one tool's hook timer runs while another asks permission. It's for Quality's native check. The latest PermissionRequest hook still overrides first (`classifySendReadiness`).
- A prompt drawn above the input box (`send-prompt-guard`'s FORWARD-FIX layout) has no timer row, so it's still refused.
- **Unchanged:** Codex, other runtimes, and reads without a runtime (the display surfaces).
## Limits, deliberately conservative
These still read as attention, as today:
- **an idle Claude seat** (no timer row) with quoted prompt text above its input box. Nothing on screen tells that apart from a prompt drawn above the box;
- **a draft in the input box;**
- **a mode bar outside the recognised list,** such as the default "⏸ manual mode on";
- **an unframed input box.**
## Tests
`packages/daemon/test/claude-quoted-prompt-veto.test.ts`, +120.
**The classifier:**
- quoted text reads as working with a timer row, in both modes;
- the native permission (Bash, Edit, WebFetch), AskUserQuestion and MCP dialogues, and a prompt above the input box with a listed phrase, all read as attention under every option set;
- with no runtime, a Codex runtime, no timer row, an unrecognised or non-mode bar, or a draft, the result is identical to before.
**The real send path,** `SessionTransport.send`:
- delivered for the working seat with quoted text, through both the ordinary probe and the fresh running-hook path;
- refused at a real permission dialogue and at the MCP menu, through both paths.
**Results on Build:**
- **Before the fix,** the new tests against the base source fail 3 of 12, on exactly the working-seat cases. The ordinary probe refuses on the quoted `› 1. Yes, proceed (y)` (`selection_prompt`), and the fresh-hook path on the quoted "Do you want to proceed?" (`permission_prompt`). The protection cases pass on both sides.
- **With the fix,** 1,723 tests pass across 40 files: every test file that refers to the classifier, the send probe or `target_needs_input`. That includes `send-prompt-guard` (FORWARD-FIX 1), `claude-question-picker` and `session-transport`. The daemon builds, and its typecheck exits 0.
## Cost
Source +9/-2, tests +120. No new refusal, matcher, error code or setting.
## What a user gets
Managed Claude compaction shows the owed restore stage and its last delivery result in `rig compact --state` and seat status. Active-work idle waits show as waiting, without marking the stage held or raising a failure notice. Repeated actual failures create one queue item for the delegation owner or registered human fallback; changed reasons update it without another wake.
## How you verified it
Baseline RED exposed missing diagnostics; round-one RED reproduced false busy-stage failure counts and a notice callback running inside the real lifecycle lease. After correction, 85 focused daemon tests pass, including three busy-stage polls, unresolved/rejected callbacks, retry, restart, cancellation and notification deduplication. Daemon typecheck passes. Initial author checks also passed 210 daemon and 63 CLI tests. The stub runtime cannot perform native Claude compaction; these fixtures do not establish the original native stall's cause. Required CI will run on the new head.
## Anything you were unsure about
Notices start after the guarded operation settles and do not delay its drain. The human fallback is a plain ask: urgent-only subscribers are not paged; every-ask subscribers keep their usual notification. Cost: one small record write per unsuccessful poll and at most one diagnostic item per attempt (+124 net source lines, +149 net test lines; 1.09 added test lines per added source line). Existing owner-closed dispositions stand; an open notice is not automatically closed when the stage later progresses. No new reason codes, scheduler or delivery permission; idle, occupant, typing, retry and cancel behavior stays.
## What a user gets
A managed Claude restore on a Mac reads its own restore files without stopping at a Read approval, the same as on Linux. The same applies on
any machine where the OpenRig home or the seat's project is reached through a symlink. One gap remains on every platform and is fixed separately: the generic `post-compact-extra.md` fallback isn't in the grant yet, so a restore that reads it still asks once.
## Why it happened
#1940 grants a seat's restore reads as `Read(//…)` allow rules built with `path.resolve`, which keeps symlinks. Claude Code's
[permission docs](https://code.claude.com/docs/en/permissions) say allow rules "apply only when both the requested path and the file it
resolves to match". On macOS, `/tmp` is `/private/tmp`. So a read of the compaction packet under `/tmp/claude-compaction-restore/…`
resolves to `/private/tmp/…`, which no rule covered, and the restore stopped at the approval. #1940's native A/B ran on Linux, where `/tmp`
isn't a link, so it couldn't show this.
## The fix
Each base directory (the OpenRig home, the seat's working directory and the packet root) now gives two spellings, and every restore file
is granted at both:
- the resolved path, as before;
- the real path, with symlinks followed.
A directory that doesn't exist yet, such as the packet root before the first compaction, keeps its remaining path under its nearest real
parent. Where nothing on the way is a link, the two spellings are equal and the rules are exactly as before. The grants still cover only
the seat's own files. `managed-restore-read-access.ts`: +34/-10.
## Tests
- **New:** a symlinked home, project and packet root (the packet root not yet existing) are each granted at both spellings, and every
grant stays inside the fixture.
- **#1940's exact-list test** now expects both spellings. On a Mac runner that includes `/private/tmp/…`.
RED, the tests alone on main (`69a2eb76`, run 40141826010): on the macOS runner, #1940's six launch-shape cases fail because nothing is
granted under `/private/tmp` (the bug itself), and the new symlink test fails too. Nothing else fails.
GREEN at `12d84fa2` (run 40141827784):
- attempt 1: every job passed except one daemon test file, `rex-transport.test.ts`'s timing case, unrelated, which also flaked on another
branch tonight; all the restore-read tests passed;
- attempt 2: all 8 jobs pass.
A native check on a Mac seat is still needed.
## What this fixes
`rex-transport.test.ts` › "ends a run that does not answer in time, with its process group" failed intermittently on macOS CI runners (for example run 40141827784, attempt 1). The failing assertion was the last one: an instant check that the script's backgrounded `sleep` was gone (`expect(() => process.kill(child, 0)).toThrow()`). The deadline and timing assertions before it passed.
`stopGroup` returns once the run's process group is empty and the direct child is reaped. The orphaned `sleep` is reaped by the system on its own schedule, so on a loaded runner it can still be listed for a moment after the run settles. An empty pid file would also have read as pid 0, and `process.kill(0, 0)` signals the test's own process group.
## The change (test only)
- **The orphan check:** wait up to five seconds for it to go (`expect.poll`), instead of reading the process table at one instant.
- **The pid:** assert the pid read from the file is a real one (an integer above 1).
- **The deadline:** one second instead of 300 ms, so the script's start fits well inside it on a loaded runner.
- **The elapsed bound:** under two seconds, which is the deadline plus `stopGroup`'s one-second grace. It still fails if the deadline stops ending the group at once.
No product code changes.
## Proof (local, macOS)
- **The test alone:** 8 of 8 repeated runs pass, and the whole file passes 24 of 24.
- **Without the immediate group kill at the deadline:** the test fails (2,050 ms against the 2,000 ms bound).
- **Without the deadline:** the test fails (it times out at 20 s).
## What a user gets
Proof-source monitoring recursively watched the workspace parent, including unrelated checkouts and build trees. It now recurses at the configured missions root and uses filtered shallow watches for other policy and evidence inputs. Related to #1813.
Replaced roots and input parents get rebound. Failed or unsettled coverage reports unavailable, including a missions alias resolving outside its project. Canonical readers, default behavior and judgment publication checks are retained.
## How you verified it
At 424337a7, implementation and independent QA each passed all 52 tests across proof-source-boundary, proof-source-root, proof-policy-reuse and proof-judgments. Daemon typecheck passed. Added regressions failed on their preceding implementations, including both outside-root cases before the final correction.
The checks exercise error latching, named/null replacement events, new missions after rebind, bounded reconciliation, state-change notifications, containment and publication/recovery controls. Replacement and alias callbacks use mocked delivery over real temporary files. Full repository build, test and lint were not run.
## Anything you were unsure about
Unavailable means uncertified live coverage, not filesystem isolation: a watch requested at a configured symlink can still follow its real target. Large missions trees remain recursive. Native large-tree behavior, performance and the reported freezes have not been reproduced by these checks. Startup-lock behavior remains a separate investigation.
- [x] One concern per PR; no version bump; no CHANGELOG.md edit
- [x] Tests added or updated where the change is testable
- [x] Checks run, results and omitted checks listed
## What a user gets
`rig seat restart --keep-conversation` no longer reports that the resume wasn't proven, and that nothing restarted, for a Codex seat that
did restart and resume. This happened whenever the seat's Codex ran on a `CODEX_HOME` the restart's proof didn't look in.
## Why it happened
The in-place restart reads the running Codex's `CODEX_HOME` from the process itself, and refuses to relaunch into any other home. But its
resume proof (`verifyResumeInPane`, `sendResumeCommand`) passed the adapter only the seat's node. The adapter then read the home the seat
declares in `env:` (#1937), and otherwise the daemon's. A Codex whose home came from anywhere else wrote its records where the proof never
looked:
- a home from a one-off `--env`;
- a home set on the tmux session or in the shell;
- on a build without #1937, any `env:` home.
So the proof found no record, and the report said "not proven ... nothing was restarted", although the pane had restarted and resumed.
## The fix
The restart passes the home it already read to the proof. `verifyResumeInPane` and `sendResumeCommand` take it as an optional last argument,
and when it's given it wins over both the declared home and the daemon's. Callers that don't pass it behave exactly as before. Source: +14/-11
in two files.
## Tests
- **`seat-restart-in-place.test.ts`:** in both pane shapes, shell-backed and direct, the restart passes the running Codex's home to the
proof, though the seat declares none.
- **`codex-seat-home.test.ts`:** an explicit home wins over the seat's declared home and over the daemon's, for both methods.
RED, the tests alone on main (`b15a00ad`, run 40140393992): exactly the two new tests fail. GREEN at `a66263fb` (run 40140395642): all 8
jobs pass.
## What a user gets
Upgrading OpenRig no longer stops a working Codex seat at "Hooks need review" for OpenRig's own unchanged plugin. Codex 0.164 fingerprints the whole plugin, and this release changed openrig-core's scripts and skills while its six hook declarations stayed the same, so every upgraded Codex seat stopped. OpenRig now re-approves its own plugin on upgrade, without asking, when three things hold:
- the earlier approval exactly matches the previously shipped plugin;
- nothing is disabled;
- the installed files exactly match what shipped.
## The change
- **The renewal:** a new `codex-owned-plugin-trust.ts` plans it, and only when all three conditions hold.
- "Previous" is OpenRig's recorded approval, else the pinned published 0.1.17.
- Disables and choices in any config layer or profile keep native review.
- It writes only `trusted_content_hash` under the six OpenRig-owned hook headers, plus one small receipt (mode 0600) per Codex home.
- **Checked before writing:** the proposed config is parsed and must equal the original plus exactly the planned fields. Otherwise nothing is written, no receipt is recorded and native review stays. This covers quoted keys and table text inside multiline strings. The final re-read before the write is kept.
- **Install versus approval:**
- Install eligibility keeps the previous check: the shipped hook files and the Codex manifest. So a home with extra non-hook files still gets the upgraded plugin.
- The first-install declaration grant and the renewal both require the exact shipped tree, so an unmatched tree is never approved automatically.
- **Main only:** renewal stays in the selected Codex home (#1937).
**Unchanged:** explicit disables, refusals, custom config layers, other people's hooks, and Codex's own baseline. Codex records no "continue without trusting" choice, so a deliberate skip of this exact owned update is overridden. That was the accepted choice.
## Behaviour by case
| Case | What happens |
|---|---|
| Clean shipped tree | A fresh install gets the six exact declarations plus content approval. An owned upgrade renews. |
| An extra non-hook file in the plugin folder, fresh home | The plugin installs. Nothing is approved automatically, so Codex's own review applies. |
| An extra non-hook file, approved upgrade | The new plugin installs. The existing approval stays as it was, with no renewal. |
| A changed shipped hook file or Codex manifest | The Codex plugin isn't installed or upgraded. |
## Proof
- Three review rounds, each read by an independent Claude and Codex pair:
- a config edit that could make a valid file unloadable;
- the install check, which had widened to skip upgrades for any extra file;
- the first-install grant on an unmatched tree.
- The focused suites pass, 179 of 179 on main, with each round's failing control red first. Daemon typecheck is clean, and required CI passes at this head.
- Native upgrade validation on real Codex homes is the release quality lead's, outside this PR.
## Cost
+353/-19:
- source +189/-14 (the adapter +48/-14, the new module +141);
- tests +158/-1;
- docs +6/-4.
No new setting. It adds whole-tree reads on Codex install checks and one receipt per Codex home.
Adds `.github/FUNDING.yml` with one line, `github: mvschwarz`, so GitHub shows its standard Sponsor button on the repository page, linked to github.com/sponsors/mvschwarz.
Nothing else changes: no README, docs or site edits. The repository's Sponsorships setting is switched on separately.
## What a user sees
`rig provider --help` and `rig provider switch --help` said the command switches a seat to an account, with "interruption-safe account switching". It doesn't do that yet. On main, the daemon's `switchAccount` (`provider-service-impl.ts:158-168`) runs the precheck and always answers `failed_safely`:
- **Without `--force-unsafe`:** the answer carries the precheck's reasons.
- A manual precheck assumes a live conversation, because live state isn't read yet. So the reasons always include `would_strand_live_conversation`.
- `target_auth_unknown` is added for an unknown target, and `rebind_unsupported_for_runtime` for a Claude target.
- **With `--force-unsafe`:** the precheck's refusal is skipped, and the answer is `switch_execution_not_yet_wired`.
No account changes either way. The help now says so, including that the plain output prints only the outcome and the reasons are in `--json`.
## The change
Three help strings in `packages/cli/src/commands/provider.ts`, +3/-3:
- the `rig provider` description;
- the `switch` description;
- the `--force-unsafe` description. It used to say the switch "still refuses to strand a live conversation". When forced, though, the service skips the precheck entirely, so that was true only because nothing executes.
There are no behaviour changes. No doc or skill repeats the claim: the only other mention, `docs/as-built/cli-reference.md:764`, lists the flags without their descriptions. No test pins the old text.
## Cost
Help text only. No tests change.
## What a user gets
A seat waiting at a prompt that only its pane shows (for example, a Codex seat at an approval prompt that no hook reported) now reads as
needing attention, with its reason, on every surface: the seat API, the rig and TUI count, the `rig ps` table and the compact JSON. Before
this, the row served `needs_input` (`selection_prompt`, from the pane reading) while `needsAttention` was false, so the table said
"working, —".
## Why it happened
Since `rig ps` renders the served attention flag (#1876), that flag has to agree with the activity the row serves. It didn't:
- `attachTerminalActivityAndWork` derived `needsAttention` from a fresh hook-store read, not from the served `agentActivity`, which also
reads the cached pane observation when the hook is absent or stale;
- the rig count read only the hook store.
## The fix
- **One step, two readers.** The hook-or-pane step of the activity ladder moves, unchanged, into `hookOrPaneActivity`:
1. a positive hook keeps its meaning;
2. a current usage limit stays;
3. otherwise, the cached pane reading answers.
`attachAgentActivity` calls it and applies motion as before.
- **The per-seat flag** reads the served `agentActivity`, and falls back to the hook store where activity wasn't attached.
- **The rig count** reads the same step, with the pane-reading service wired into it, so it can't disagree with the row.
**Unchanged:**
- The arbitrated signal still comes first, so an observed clear from an authoritative rung wins.
- Stale hooks still read `unknown`.
- The pane cache drops stale readings, so nothing stale is revived.
- A confirmed-missing session serves neither hook nor pane, on the row and in the count.
- Everything stays capture-free.
## Tests
`node-attention-consumers.test.ts` drives the real seat route, the rig count, the CLI (JSON and the table) and the TUI reader from one
fixture. It now adds:
- **The native case:** a prompt only the pane reading sees gives ATTN with `selection_prompt` in the table and the compact JSON.
- **The same case after a stale hook,** and **after a daemon restart** with no arbitrated state yet.
- **Controls:** an observed clear still wins, and a current running hook still outranks the pane reading.
CI: RED (the tests alone on main, run 40140037040) fails in `package-tests (daemon)`, as intended. Required CI (8/8) passes at this head. The same change is the 0.7.1 successor candidate `2f6f1f49` (patch-ids checked), and its own RED/GREEN ran the same way (40140033718 / 40140035418).
Follows #1937 and closes two of the gaps it listed as still daemon-scoped.
## What a user gets
- **A one-off `rig up --env CLAUDE_CONFIG_DIR=…` or `CODEX_HOME=…` isn't applied, and the CLI says so.** That value used to put the first
launch on a home that a restore, a handover and `rig seat status` didn't know about: the seat ran on one login while status reported
another, and the next restore moved it back. The note says to declare the home in `env:` in the rig spec. Other `--env` values work as
before.
- **For a Claude seat with its own config dir, activity and continuity read that dir.**
- Activity: the self-report rung finds the seat's `pid.json`.
- Continuity: a policy that watches the seat's transcript, such as a size threshold, finds the file.
Before, both looked only in the daemon's dir and found nothing for such a seat.
## Changes
- **CLI** `up.ts`: leaves `CLAUDE_CONFIG_DIR` and `CODEX_HOME` out of `--env`, with a note.
- **Daemon** `node-launcher.ts`: drops both from any one-off env it receives (`withoutRuntimeHomes`), so an API caller gets the same result.
- **Daemon** `startup.ts`: the Claude self-report reader and the continuity transcript lookup resolve through `claudeConfigRootFor`, in this
order:
1. the seat's declared home;
2. the daemon's `CLAUDE_CONFIG_DIR`;
3. `~/.claude`.
A seat that declares no home reads exactly what it read before.
- **Docs:**
- `rig-spec.md`: the `--env` exception, and "name the home in `env:`";
- the `openrig-user` recipe step 2 says the same, with its edge digest updated.
## Still daemon-scoped, on purpose
Live usage refresh (`rig provider status --refresh`) still reads only the daemon's own logins. Its readers are built once with the daemon's
homes, and reading each seat's home would need a native reader per home. `rig-spec.md` now says so.
## Tests
- `seat-runtime-home.test.ts`:
- `withoutRuntimeHomes` drops both names and keeps the rest;
- `claudeConfigRootFor` returns the seat's home, else the daemon's, else `~/.claude`.
- `seat-env-journey.test.ts`: a one-off home reaches neither the seat's terminal nor its forwarded names; other one-off values still do.
- CLI `up.test.ts`: `--env` with both homes and `DEBUG=1` sends only `DEBUG`, and prints the note for each home.
GREEN at `cceedfb1` (run 40131620044): all 8 jobs pass. RED, the tests alone on main (`e9eb005d`, run 40131618183): still queued; I'll add
its result here when it lands.
## What a user gets
`rig up --existing`, and any other resume of a Codex seat, recognizes the resumed conversation when the Codex status footer shows a model name with a reasoning label, for example:
```
GPT-6.1 Sol medium · /data/workspaces/proof-a · …
```
Before this change, once Codex's "OpenAI Codex (v…" header had scrolled off, that footer wasn't recognized. The resume then exited 1 with "Codex resume has not yet reached an interactive conversation" while Codex was running normally. Footers such as `GPT-6-Astra high` already worked: one word after the version was allowed, but a display name plus a reasoning label is two.
## The change
- The model field in a footer may now hold up to three words after the versioned id. That covers a display name and a reasoning label. It applies to both the `gpt-*` field check and the versioned non-`gpt` field, which is still used only when a Codex process is verified.
- Everything else that makes a line a footer is unchanged:
- an indented, ` · `-delimited status row whose whole field is the model;
- a composer line above it;
- trust, update and model-selection gates stay authoritative.
- A longer run of words that starts with a model name is still prose, not a footer, so a status or conversation line can't pass as a ready footer.
## Tests
- **New cases:**
- the reported footer;
- the model field in a later position (`Context 81% left · GPT-6.1 Luna xhigh · /project`);
- a verified non-`gpt` model with two words;
- two prose negatives: a sentence that starts with `GPT-6.1 Sol`, and a field with four words. Both still read as returned to the shell.
- **Before the fix:** the three positive cases fail, and the negatives pass.
- **After the fix:**
- `native-resume-probe`, its evidence tests, `codex-runtime-adapter` and `codex-resume` pass (333 tests), and daemon `tsc --noEmit` is clean;
- the other test files that import the probe pass, as does `session-transport` (270).
## Cost
- Source: 2 regular expressions changed, `{0,3}` in place of `?` for the trailing words, plus the comment (+5/−3).
- Tests: +17.
- There's no new refusal or code, and no runtime cost.
Reported by @george661 on #1764. Thank you.
**Review note:** the longer field follows the shape Codex renders (an optional capitalized display word, one effort label from Codex's closed set, an optional tier word). It's a shape check, not proof against every prose line: a line like `GPT-6.1 default settings · /project` would still match.
For #1932.
## What a user gets
A Pi or OMP seat whose startup sends more than one block no longer raises `runtime_error` ("Agent is already processing") for the second
one. The second block reaches the running turn as a steer.
## Why it happened
`RunnerCore.handleUserBlock` chose between `prompt` and `steer` from its own `streaming` flag, which turns on only at `agent_start`. A block
that arrived after a `prompt` had gone out, but before `agent_start` came back, went out as a second `prompt`. A busy agent refuses that,
and OMP reports the refused input as `runtime_error`.
## The fix
The runner no longer decides. It sends every ordinary block as `prompt` with `streamingBehavior: "steer"`, and the runtime does the rest:
- **When the agent is idle,** the prompt runs.
- **When it's busy,** the prompt is queued as a steer: delivered after the current turn's tool calls, before the next model call.
The window the runner couldn't see is covered too:
- **Pi** counts itself busy from the moment the first prompt's preflight succeeds.
- **OMP** counts itself busy from when a prompt starts.
So a block sent before `agent_start` is queued behind that turn instead of refused. Pi's RPC `prompt` has accepted `streamingBehavior`
since 0.32.2, and OMP's RPC `prompt` accepts it too.
**Why no runner state:** a prompt can succeed with no turn. An extension command or an input handler can consume it in Pi, and OMP reports
`agentInvoked: false` for a consumed builtin. A runner-side "busy" mark would then send later work as `steer` to an idle agent, where it
only queues and never runs. With no runner state there's nothing to get out of step. The runner's `streaming` flag now only labels the
pane's mirror line.
**A side effect:** a `/command` typed mid-turn now goes through `prompt`, so Pi runs an extension command immediately instead of refusing it
as a steer. `pi-runner.ts` is +7/-10 against main.
## Tests
- **Pi and OMP:** the reported order (prompt sent, success response, a second block before `agent_start`) sends two prompts with
`streamingBehavior: "steer"`, and OMP raises no `runtime_error`.
- **After a local-only command succeeds with no turn,** real work still goes as `prompt` and never as `steer`:
- Pi's success with no turn;
- OMP's `agentInvoked: false`, in its response and in a later `prompt_result`.
- **The existing routing tests** (idle, mid-turn, after `agent_end`, rapid submissions) now expect the new `prompt` shape. The mirror line
still says "you (steer)" mid-turn.
GREEN at `c744bac4` (run 40132196534): all 8 jobs pass. RED, the round-1 tests alone on the previous head (`dca2c44e` on `e205a6e4`, run
40132193843): still queued; I'll add its result here when it lands. The first round's RED, the tests alone on main (`d6e2d92c`, run
40127969014), failed the two reported-order tests.
Thanks to astral-fleet-sessions for the report, which traced the order exactly.
**Compatibility:** a Pi before 0.32.2 ignores `streamingBehavior`, so a mid-turn block would be refused there as on main's second prompt. OpenRig can't launch such a Pi, because its Pi launch needs `--name` (added in 0.78.0).
## What a user sees
A Claude Code seat configured with the model alias `haiku` and the saved `plan` permission answers its plan-mode turns with Sonnet. That's Claude Code's own plan-mode behaviour: it upgrades the literal alias `haiku` to Sonnet in plan mode, and a full model id keeps its model. Until now nothing in OpenRig said so; the seat showed `haiku` and answered on Sonnet.
With this change, for that one pairing:
- **The launch result** (`rig up`, `rig seat launch`, a fork or a resume) and **the restore result** carry one line:
`<seat>: Claude Code answers plan-mode turns with Sonnet when the model is the alias "haiku". To keep Haiku, set a full Haiku model id: rig seat set-model <seat> --model <full Haiku id> --reason "<why>".`
- **`rig seat status`** prints the same line under "Permissions, planned for the next fresh managed launch", right after the summary. `--json` has it at `permissions.account.advisories`.
- **`docs/reference/getting-started.md`** ("Per-seat permission mode") gets one sentence saying the same.
**This is disclosure, not an automatic model-selection fix.** OpenRig still passes the configured `--model` and `--permission-mode` unchanged. It doesn't pin an alias to a dated id, add a refusal, or change any launch flag. Choosing the full id is the user's call, and the message names the command for it.
## The change
- `planModelAliasNotice(runtime, { model, permissionMode }, seat)` in `adapters/yolo-mode.ts`, beside `claudePostureFlag`. It returns a note only for `claude-code` with mode `plan` and a model that is exactly `haiku` after trimming, which mirrors Claude Code's own exact check.
- It's called beside the existing non-interruptive notice in `StartupOrchestrator` (fresh, resume and fork) and in `RestoreOrchestrator`'s Claude resume, and from `planPermissionAccount`, which reads `nodes.model`, the same value the launch binds.
- The CLI's `SeatStatusResponse.account.advisories` is optional, so an older daemon that doesn't send it prints as before.
- **Shipped config:** OpenRig ships no spec, built-in team, skill or doc that pairs `haiku` with plan mode, so nothing changes there. The one bare `haiku` that ships is the Claude usage probe (`claude-token-usage.ts`). It runs in print mode with no permission mode, so it's never in plan mode, and the alias keeps it on the latest Haiku.
## Cost
- Source +30/-3 across 5 files, docs +4, tests +129.
- One SQLite read of `nodes.model` per `rig seat status` permission account. Nothing on the launch path except a string check.
## Tests
- **Seat status** (`permission-account.test.ts`): the advisory appears for `haiku` and ` haiku ` with plan. There's none for `claude-haiku-4-5`, `opusplan` or `sonnet` with plan, and none for `haiku` with `acceptEdits` or no saved mode. The native argument is unchanged in every case.
- **Launch** (`startup-orchestrator.test.ts`): the warning is on the result for claude-code `haiku` + plan. There's none for a full id, no mode, or a codex seat, and the binding passed to the adapter is unchanged.
- **Restore** (`plan-model-alias-notice.test.ts`): the restore result carries the warning for `haiku` + plan, and none for a full id or `acceptEdits`. The resume still receives the configured model and mode.
- **CLI** (`seat.test.ts`): the advisory prints on the line after the summary.
**Results on Build:**
- **Before the fix,** against unchanged source with these tests, 10 cases fail: 9 daemon cases and 1 CLI case. The no-note cases pass.
- **With the fix:** daemon 170 passed (1 existing skip), CLI 53 of 53, `tsc` exit 0 for both the daemon and the CLI, and `check-first-run-references` reports 0 failures.
**Still to check live:** a native plan-mode turn on a seat set to a full Haiku id, to confirm it answers on Haiku. This PR doesn't run a model.
**Review notes:**
- `rig seat status --json` now always carries `permissions.account.advisories`, which is empty for every other pairing. The human output and launch arguments are what stay unchanged.
- Claude Code normally answers plan-mode turns for `haiku` with Sonnet. Its source keeps Haiku when every Sonnet is excluded by a model restriction.
A Claude seat with limited Read permissions can finish compaction and then stop at approval for OpenRig's restore marker outside its working directory. Launch and resume now merge narrow Read allowances into the existing session settings: the seat's marker and generated map, the two restore/refocus skill files, its extra-instruction file, and five packet files under the native conversation UUID passed at launch. Fresh, fork and both resume paths use the same composer; forks use the child's UUID. Runtime-switch successors use the canonical seat name rather than their temporary tmux staging name.
Permission mode, existing settings/hooks and native deny/ask rules are preserved. No shared settings or restore writers change. Cost: the next launch/resume adds up to eleven Read patterns, including when managed compaction is disabled; existing running sessions do not acquire them. Operator-selected preparation roots, arbitrary referenced sources and a packet root overridden only inside the seat keep their ordinary permission checks. A legacy name without a native UUID gets no packet-directory allowance. Known limit: packet rules stay bound to the launch token. If an accepted resume rotates T1 to T2, or the native conversation changes later, a packet fallback read may still ask; the seat-keyed marker, map, extra and skill allowances are unchanged. This does not grant every conversation's packets.
Validation: four command-builder regressions failed before the fix; 270 focused tests pass after it, including shell-executed argv capture, default/explicit-mode launch and resume, fork identity, runtime-switch staging, exact generated Read-rule scope, settings preservation and idempotence. Daemon TypeScript passes. The existing 36-cell interactive launch stub also passes. Stubs cannot establish Claude's native Read matching or a completed compact/restore journey; that independent native check is still pending.
When a fresh seat replacement detaches an open terminal tile, the launch result now names the seat and gives commands to reopen its rig view in Herdr/tmux or cmux. The existing warnings appear in human and JSON output, including a failed startup after the old session was stopped. Clean first launches get no replacement warning.
This is recovery guidance: the person rebuilds the view manually. Every confirmed fresh replacement gets the guidance, even if no view was open; it does not count open workspaces or automatically reattach tiles. Other replacement verbs keep their current reporting. Provider code, detach safety and lifecycle decisions are unchanged.
Validation: the missing-warning cases failed before the fix; all 68 fresh-launch tests pass after it, including terminal/Claude replacements, failed startup and a clean-launch control. Daemon build/TypeScript passes. All 52 CLI lifecycle tests pass, including human/JSON warnings on both success and error responses. Desktop providers were traced in source; no native desktop run or live seat changes.
Refs #1939. Thanks @vanducng for the terminal-seat reproduction.
A seat can now run on its own Claude or Codex account. Each runtime keeps its login in its home: Claude Code in `CLAUDE_CONFIG_DIR`, Codex in `CODEX_HOME`. A seat whose member or rig `env:` declares an absolute one runs on that home for the launch and lifecycle paths below, instead of the daemon's:
```yaml
pods:
- id: dev
members:
- id: impl
runtime: codex
env:
CODEX_HOME: /Users/me/.codex-second-account
```
The home is prepared once, natively (`CODEX_HOME=<home> codex login`, or `CLAUDE_CONFIG_DIR=<home> claude` then `/login`). OpenRig copies no credentials or history between homes.
## How
`packages/daemon/src/domain/seat-runtime-home.ts` resolves a seat's home from its stored `env:` (member over rig). A value that isn't an absolute path is reported and ignored. It doesn't reach the runtime: `getEffectiveSeatEnv`, the one source for launch, restore, handover and runtime switch, leaves it out. So the seat resolves as it did before, and nothing is refused.
| Runtime | What follows the seat's home |
|---|---|
| Claude | the managed launch's exported `CLAUDE_CONFIG_DIR`; the first-run bootstrap (`.claude.json`, onboarding and trust); resume capture (`<home>/sessions/<pid>.json`); the fallback resume probe, which runs with the seat's config dir only when one is declared |
| Codex | the launch, resume and fork commands; OpenRig's managed `config.toml`, hooks, feature flag and core plugin; the profile, daemon-support and network-default probes; thread capture, including on adoption and discovered handover (by node); the resume proof, including `rig seat restart --keep-conversation`'s |
| Codex, legacy paths | the legacy resume and restore pass the home only when one is declared, so other seats' calls are unchanged |
| Readers | context usage and the model reader also search declared homes (thread ids are unique across homes) |
| Usage limits | Claude seats with their own home pool apart (`claude:home:<dir>`) from `claude:local`, and the reactive tap skips a Codex seat with its own home, so one account's exhaustion isn't charged to another |
| Status | `rig seat status` shows the runtime home and where it comes from (member, rig, daemon or native default), and any ignored value |
| Provider | `rig provider status` lists the seat's own home as its configured account (`homeFrom`, `ignoredHome`); the daemon home's auth registry no longer binds a seat that has its own home |
Codex homes are passed as a parameter, not adapter state, so concurrent launches for different seats can't cross.
**Still daemon-scoped (not every reader follows the seat yet):** startup's Claude self-report evidence and its continuity transcript lookup still read the daemon's root, and native usage refresh stays daemon-scoped. A one-off `rig up --env CODEX_HOME=…` value still reaches the panes without this resolution.
**A correction to how this worked before:** `CLAUDE_CONFIG_DIR` is one of the managed Claude launch's own keys, so a seat's declared value was never forwarded to Claude, even when the daemon set none. `rig-spec.md` is updated, along with the Codex line.
**Compatibility:** the provider record's new fields are optional, so an older daemon still accepts this one's seat accounts across hosts.
**What doesn't change:** seats that declare no home; shared homes (several seats may name one); a running seat, which keeps its home until its next launch.
**A known limit:** a conversation saved under a seat's earlier home isn't in its new one, so it can't be resumed there. OpenRig doesn't copy it between homes.
## Tests
- **First round:** RED on main `7e69abc1` fails the 21 new tests ([run 40118004305](https://github.com/mvschwarz/openrig/actions/runs/40118004305)). GREEN at `2524764f` passes all 8 jobs ([run 40118018519](https://github.com/mvschwarz/openrig/actions/runs/40118018519)).
- **Review fixes:** RED, with the tests alone on `7b2065f3`, fails exactly the 9 round-1 tests ([run 40125339648](https://github.com/mvschwarz/openrig/actions/runs/40125339648)). GREEN at `77f70a2e` passes all 8 jobs, with 21,151 daemon tests ([run 40127630330](https://github.com/mvschwarz/openrig/actions/runs/40127630330)).
- **Covered:**
- the resolver: member over rig, ignored relative values, nothing declared;
- the Claude launch, bootstrap, resume capture and fallback probe;
- the Codex fresh, resume and fork launches with managed config in the seat's home;
- thread capture on adoption and handover;
- the resume proof and in-place restart;
- legacy resume;
- context usage;
- usage pools by home;
- status and provider accounts;
- unchanged seats.
These tests use fixture executables only and never sign in. Real logins in distinct homes, and the same conversation across resume, restore and handover, still need a native run.
Rex as a terminal provider, by @vanducng. Thank you. The scope is in #1934.
## What a user gets
From a [Rex](https://www.superlogical.com/rex/docs) pane, `rig terminal open <view> --window` and the TUI open the team's view as a new Rex session, one window per page with the same 16-tile grid as Herdr, and switch the Rex app to it. `--provider rex` selects it explicitly. Outside Rex nothing changes: the default order stays Herdr, then cmux.
## The change
- **The provider:** `rex-adapter.ts`, `rex-transport.ts` and `rex-layout.ts` implement the existing `TerminalProvider` seam over Rex's JSON CLI, passing `-S` because this Rex build ignores `REX_SERVER`. Herdr's grid builder moves into a shared `tile-layout.ts`, with Herdr's layout output unchanged.
- **Selection:** the CLI (`terminal-window.ts`, `terminal-window-rex.ts`) and the TUI (`open-window.ts`) pick Rex when called from inside Rex. Inside a Herdr pane, Herdr keeps the view even when `TERM_PROGRAM=rex`, and the CLI and TUI now agree on that. A window opened from inside Rex is refused unless this terminal and the daemon use the same Rex server.
- **Status stays fast:** discovery gives each of Rex's version and status calls 1 s (the pair races a 1.25 s deadline), shares one probe per status report, and the service probes Herdr, cmux and Rex side by side. A stalled Rex reads "did not answer within 1000 ms" while the other providers report normally. Mutations keep their 30 s budget.
- **Uncertain outcomes stay uncertain:** a Rex call that times out, is killed, or returns an unreadable reply is `unknown`, not `failed`. A create whose reply is lost, or names no session, returns `rex_outcome_unknown` and says to check Rex before retrying. A lost window reply keeps the session, names the unconfirmed pages, and never calls `session.destroy`. The session is closed, as before, only when every window definitely failed.
- **Docs and skills:** `terminal-sessions.md`, `getting-started.md`, the as-built adapters page, and the `rigs` and `openrig-herdr` skills.
## Proof
- **CI at this head:** all jobs pass, tested merged with current main. The daemon's terminal-service, rex-adapter and rex-transport suites include a never-settling Rex beside a healthy Herdr (the report returns in under 5 s, using one probe's two 1 s calls), lost create, lost first-page and lost later-page replies (no destroy), and the Herdr-inside-Rex precedence on both the CLI and TUI paths.
- **The author's native runs** (Rex `0.0.1792787366`, API revision 7, two Macs): status, a 4-seat open on each Mac, `--window` switching the app, the TUI preview and open over HTTP, a 17-seat two-page view, and a stalled-Rex measurement at an earlier revision. These are the author's evidence. Our review read the source and CI only.
## Limits
- Not run on Linux.
- Rex counts a block's login-shell startup toward its quick-exit window, so tiles set a 10 s threshold and the adapter checks for exited tiles once, about 2 s after opening. A tile that fails between 2 s and 10 s keeps its error on screen, but the result lists that seat as opened.
- `rig terminal status` with no provider also probes Rex, bounded as above.
## Cost
Source +721/-111, tests +993/-13, docs and skills +82/-20. One new result code (`rex_outcome_unknown`), no new setting.
Found by the lab's onboarding self-scout. Thank you.
## Problem
`rig proof add <absolute slice path>` refused with "resolved to … but no parent mission was found" for a slice in a catalogued project other than the configured one, until `OPENRIG_WORK_ROOT` named that project. `proof add` resolves its missions root once, from `--workspace`, then `OPENRIG_WORK_ROOT`, then the configured `workspace.slices_root`. `findSlice` then looks for the owning mission only inside that root. The read side already selects a catalogued project: `proof show`/`judge --project`, and queue work since #1526.
## Fix
`proof add` calls `findSlice` as before. Only when that refuses an **absolute** path, and no tree was named with `--workspace` or `OPENRIG_WORK_ROOT`, it:
- picks the catalogued project whose root holds the path, with the existing `inferCatalogProject` (the rule `context work-install` uses for a working folder: the deepest containing root);
- reads that project's missions root with the existing `readProjectMissionsRoot`;
- tries `findSlice` there.
If that also fails, the original refusal is reported unchanged. There's no second resolver and no new refusal or setting.
## Proof
- **RED** (`41a784e0`, tests only, on main `dc9feb34`): the slice in the second catalogued project is refused with "no parent mission", the reported error. The two controls pass on main too, as they should.
- **GREEN** (`024978de`):
- `proof`, `proof-project-flag` and `scope-fs` pass 111 of 111;
- the CLI `tsc` is clean.
- **The three cases:**
1. the drop lands in the other project's slice, and nothing is written to the configured project;
2. an explicit `--workspace` still decides, so a slice outside it is still refused;
3. a slice in no catalogued project is still refused.
## Cost
Source +33/-3, tests +67.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What a user gets
The two documents that describe the CI scenario job now agree with the job's own script. The job has grown from the two seeded cases it shipped with: its arrays select eight scenarios across fourteen container runs, the library holds twenty scenarios beside its seven stub topologies, and seven of those library scenarios run in CI. A reader preparing a change can now use either document to predict what the CI job will run, which matters because picking a case is how you prove a change before pushing it. The page's own out-of-date list also drops the entry that flagged the README, since the flagged section is the one this change corrects.
## How you verified it
Tested on `e4d7f15a` with the change on top. The counts come from `scripts/run-pr-scenarios.sh` itself rather than from a reading of the docs: `CASES=(fixture library)` with `MODES=(healthy lost-baton healthy)` is six runs, `EFFECT_CASES=(refocus-parked)` with `EFFECT_MODES=(healthy seeded healthy)` is three, and the five `PASSING_CASES` (transcript, capture, daemon-restart, refocus-active, refocus-parked-off) run healthy once each, which is fourteen containers across eight scenarios. The container runner's own case table (`packages/test-system/ci/result.mjs`) is what maps each case name to its scenario file, so the rewritten sentence names the seven library scenarios and the fixture case by their scenario names rather than by case keys. The scenario count is the twenty non-stub YAML files in `packages/test-system/scenarios/` beside the seven `*stub*` topology files. `node scripts/check-docs-guard.mjs` passes, so the tracked-paths rules under `docs/` are satisfied, and `npm run mirror-skills --check` passes. What I could not run: the container job itself, which refuses to run outside GitHub Actions without an explicit `--remote` executor, so the counts are verified against the script's arrays and the case table rather than against a live container run.
## Anything you were unsure about
The page's `last-verified-against-source` marker is deliberately untouched. This change verified the scenario counts and the CI job description against the script, not the whole page, and the marker rules say to move it only when the page has been checked as a whole. The rewritten sentence names the refocus scenarios by their scenario file names (`refocus-parked-baton`, `refocus-active-baton`, `refocus-parked-baton-packet-off`) while the script's case keys drop the suffix; I chose the scenario names because the surrounding text names scenarios, and a reader following along from the case table can match them through the mapping in `result.mjs`. The seeded wording also changes slightly: the fixture and library pairs run healthy / lost-baton / healthy, while the hook case's pair is healthy / seeded / healthy, and the sentence says so rather than flattening the three modes into one shape.
## If this is security-related
Not security-related. The change is documentation only: it corrects the counts and the case names that two docs state about the CI scenario job, and moves no code, configuration or boundary.
- [x] One concern per PR; no version bump; no `CHANGELOG.md` edit
- [x] Tests added or updated where the change is testable
- [x] I listed the checks I ran, their results, and any checks I could not run
Found by the lab's onboarding self-scout. Thank you.
## Problem
`rig scope mission create` writes `mission.yaml` with `metadata: { status: planned }` and no `name`. The project lifecycle compiler requires `metadata.name` (`project-lifecycle-compiler.ts:76`), so a freshly scaffolded mission refuses to compile with `lifecycle_field_missing` until someone adds the name by hand.
## Fix
The scaffold writes `name: "<mission folder>"` beside `status: planned`.
- **Why the scaffold rather than a compiler default:** the compiler names the mission's workflow from this field (`lifecycle-<project>-<mission>`). An explicit name keeps that identity if the folder is renamed, and it matches hand-authored missions and the shipped worked example, which both write `name: <folder>`.
- **Why it's quoted:** a mission name only excludes whitespace and path separators. Written bare, YAML would read `#2` as a comment and `1.10` as the number 1.1.
- **Docs:** `docs/reference/sdlc-conventions.md` now says the scaffold writes the name, and that an older mission without one needs the line added.
- **An existing test updated:** the exact-shape scaffold test (`scope-convention-scaffold.test.ts`) now expects the name.
## Proof
- **RED** (`f25a6c2c`, test only, on main `dc9feb34`): the new case fails.
- A probe compiling main's own scaffold output beside `docs/reference/project-release-profile.yaml` refuses with `lifecycle_field_missing`, the reported error.
- **GREEN** (`5ffd1e8e`):
- `scope-commands` and `scope-convention-scaffold` pass 164 of 164, with the CLI built;
- CLI `tsc` is clean;
- `check-docs-guard` exits 0.
## Cost
Source +5/-2, tests +16/-1, docs +3/-1. No new setting, refusal or error code.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What a user gets
Compare labelled Claude token credentials with `rig provider status --refresh --provider claude --claude-token-file /absolute/private/personal.token --credential-label Personal`. Each explicit refresh spends one model turn; status/TUI reads only cached evidence. Windows, resets, age, provider refusal and overage stay distinct. Labels are operator-attested; the older seat/account join stays unknown.
Reuse the refresh coalescer, provider views and reading history. Migration 134 preserves Codex rows and adds credential-labelled Claude readings, never token values. Probe flags use the [official CLI reference](https://code.claude.com/docs/en/cli-reference); real CLI/model execution was not run.
## How you verified it
222 provider tests and 7 migration checks pass; daemon compilation, CLI/TUI typechecks and docs guard pass. Tests use the sanitized event, migrated SQLite, real routes/CLI and fake executable children, including credential isolation, timeout, passive reads, restart and distinct credentials. Full repository/package suites and native provider qualification were not run locally.
## Cost and limits
+454/−40 lines (net +414); 180 test lines/254 added source lines = 0.71. No registry, poller or rotation policy. One credential per explicit refresh; no token-probe fan-out. A timeout does not prove no allowance was consumed.
New opted-in refusal: `invalid_claude_token_selection` (400); a token file must be a regular file of at most 8 KiB; group/other permission bits or a different owner produce a warning, not a refusal. Reader failures: `credential_file_unavailable`, `credential_or_probe_failed`, `probe_failed`, `probe_timeout`, `no_usage_event` (with existing `binary_not_found`). Missing percentages remain unknown; a rejected status is never converted into a percentage.
(Squash body corrected by the merge desk: this merged as migration 134, renumbered for the post-pin order, and round 1 made the token-file owner and mode checks warnings.)
Reported in #1926. Thanks to @george661 for the clear report.
## Problem
A Claude Code seat on Amazon Bedrock is pinned to a cross-Region inference-profile id, such as `global.anthropic.claude-opus-5-5`. Bedrock won't resolve the bare id for these models, so the pin has to keep that form. Claude Code reports the bare model id, `claude-opus-5-5`, and the model-divergence monitor compared the two exactly. So after a daemon restart every such seat was proclaimed divergent: "on a model nobody chose".
## Fix
`modelsMatch` (`model-divergence-monitor.ts`), for `claude-code` only:
- After the exact comparison fails, it drops a recognised Bedrock prefix from whichever side carries it, then compares again.
- The prefix is `anthropic.`, alone or after a cross-Region geography: `global`, `us`, `eu`, `apac`, `jp`, `au` or `us-gov`. Those are the geographies AWS lists for cross-Region inference profiles.
- The existing one-side `-YYYYMMDD` snapshot rule then applies as before, so `global.anthropic.claude-haiku-4-5` also matches `claude-haiku-4-5-20251001`.
- A different model after the prefix still diverges. Nothing matches by containment, and there's no second alias map.
- Codex, Pi and other runtimes keep the literal comparison.
## Proof
- **RED** (`8b12b44b`, tests only, on main `20f77d65`):
- the 13 match cases fail, each proclaiming, including both pins from the report;
- the 8 controls pass.
- **GREEN** (`d223faf2`):
- `model-divergence-monitor`, `pi-effective-model-occupant` and `control-plane-census` pass 135 of 135;
- the daemon typecheck is clean.
- **Controls that still diverge:**
- another model after the prefix (`global.anthropic.claude-opus-5-5` against `claude-sonnet-5-5`);
- a partial id (`…claude-opus-5`);
- a prefix without `anthropic.` (`global.claude-opus-5-5`);
- an unrecognised geography (`ca.anthropic.`);
- two different snapshot dates;
- `codex`, `pi` and no runtime.
## Not covered
- A pin that carries Bedrock's model version suffix, such as `…-v1:0`. What Claude Code reports for such a pin hasn't been measured here.
- An application inference-profile ARN, which doesn't name the model.
Both still proclaim, as before.
## Cost
Source +10/-2, tests +48. No new setting, refusal or error code.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Problem
`rig acp run --help` ends with "Guide: rig context get reference/acp-agents.md". But the `reference` context pack ships only `getting-started`, `instance-layout`, `rig-spec` and `whats-new`, so an agent that follows the help gets a 404. The guide itself exists at `docs/reference/acp-agents.md`.
## Fix
- A symlink `packages/daemon/context-packs-src/reference/acp-agents.md` → `docs/reference/acp-agents.md`, linked the same way as the pack's other files, plus its manifest entry. The pack's purpose now says command help links to it too.
- The help-address test (`scripts/generate-context-packs.test.mjs`) expects `acp-agents.md` in the pack. It reads the `rig context get reference/…` address from `acp.ts`'s help and resolves it through the real address route, so the command help and the pack can't drift apart again.
## Proof
- **RED** (`a3bcb189`, test only, on main `6711432c`): the help-address test fails, and the address check alone shows `reference/acp-agents.md` returning **404** through the address route.
- **GREEN** (`b5863b64`):
- the help-address tests pass 2 of 2;
- all of `generate-context-packs.test.mjs` passes 20 of 20;
- `generate-context-packs --check` validates 57 packs;
- `check-docs-guard` exits 0.
## Cost
One symlink, manifest +7/-2, test +7/-2. No code change.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What
Slice 22, outcome 9, second increment: what a reader does about a stream item, and the poster seeing it.
- **`rig stream act <id>`** records exactly one action: `--work <qitem>`, `--decline "<reason>"` or `--duplicate <qitem|stream id>`. It runs as the transport identity; `--reader` applies only without one.
- **`act`** links work the reader opened or joined through the queue. It doesn't create work, and the row must exist.
- **`decline`** carries that reader's reason, and is theirs alone: it doesn't become a global no-action or touch anyone else's work.
- **`duplicate`** links the queue row or stream item it repeats.
- **Actions are append-only** (`stream_reader_actions`, migration 133). A reader's newest row is its current action, so a correction stays inspectable. `GET /api/stream/:id/actions` returns the current actions and the history.
- **One accountable action, by context rather than refusal.** When other work is already linked to the item, by another reader or by the automatic path's accepted create or join, `act` still records the link. Its response names that work and the actor, and suggests joining it (a note on that row) instead of keeping a second one.
- **The poster's view (`rig stream show`)** lists each reader's current action, with the actor, the time, and the reason or link.
- **When no automatic work is live** (nothing linked, or the automatic effect ended with intake), the newest reader-linked work decides the stage, followed through handoffs: `work_open`, `work_closed` or `work_unknown`.
- **A second work row** is flagged as `parallelWork`.
- **A daemon without reader actions** shows `readers: "unavailable"` rather than implying there are none.
- **Stream retention** keeps any item a reader acted on.
- **The expired-cursor 410's text** (from #1891) now says `--since <prune mark>` resumes after the pruned region, and suggests the caller's own last seen time or an earlier `--since` for all retained history, since referenced items can be older than the mark.
- **The kernel queue worker's guidance** names `rig stream act` beside `subscribe` and `read`.
## Why this shape
- **The reader links the work it opened.** Work creation stays with the queue verbs the reader already uses, and the action records the accountable link.
- **Telling, not refusing.** A second reader with different work is told about the first. A refusal would make OpenRig track the attempt's state, and the reader can judge whether to join.
- **Corrections stay inspectable:** append-only rows mean a changed mind is a newer row, not an overwrite.
## Cost
- **Net lines:** source +193/−4 (the action module 85, the outcome view 32, the CLI verb 23, routes 23 including the 410 wording, the migration 26, retention 2, registration 2); tests +154/−1; docs +1; kernel guidance +3/−2.
- **New error codes:** `action_invalid`, `work_required`, `reason_required` and `duplicate_required` (400); `stream_item_not_found`, `work_not_found` and `duplicate_target_not_found` (404). These are input checks on the new verb.
- **New refusals beyond input validation:** none.
## Tests
- **`packages/daemon/test/stream-reader-actions.test.ts` (5):**
- act, decline and duplicate record the actor and the link or reason, and each malformed input gets its code;
- two readers keep one accountable action: the second reader is shown the first's work and the automatic path's;
- a decline is that reader's alone, and a correction keeps the earlier action in the history;
- retention keeps an acted-on item;
- routes act as the transport identity.
- **CLI `stream-outcome.test.ts`:** readers are shown; a decline alone changes nothing; reader-linked work decides the stage (open, closed with its resolution, through `with_intake`); `parallelWork` when automatic work differs; `readers: "unavailable"` on an older daemon.
- **CLI `stream.test.ts`:** `act` sends exactly one action, and refuses zero or two.
- **`stream-subscriptions.test.ts`:** the 410 message carries the new wording.
- **Mutation checks:** each broken rule made its targeted test fail, and the source was restored and compared:
- dropping the other-work notice;
- dropping the reader-decides stage.
- **Other checks:**
- daemon `stream-subscriptions` 10, `stream-routes` 26, `stream-store` 11, `stream-dispositions` 12, `queue-retention` 14, `migration-fixture-parity` 5, `s02-p1-classification-persistence` 29, `startup-migrations-mirror` 2;
- CLI `stream-consumer` 22, `stream-outcome` 11, `stream` 15;
- daemon and CLI `tsc` clean;
- `npm run test:repo`: 309 pass, 0 fail.
## Round 1
- **Retention keeps a stream item a duplicate action names,** for corrected (historical) actions too.
- **One handed-on chain isn't competing work.** The `act` notice and `parallelWork` compare work by its current row, handoffs followed.
- A link whose current row is unknown keeps its own id.
- The notice gives each named link's `current` row and, for automatic work, how its application ended (`applied`).
- **Same-millisecond actions** are ordered by their monotonic action id, which is record order.
- **Cost of this round:** source +48/−11, tests +32/−2.
- **REDs first:** review-r2's three fixture cases fail on `d7c737e2`'s source and pass after:
- a duplicate-named item pruned;
- a handed-on chain named as other work and flagged `parallelWork`;
- a tie choosing the older closed work.
- **Checks:** daemon `stream-reader-actions` 7 and the stream set (75), CLI `stream-outcome` 11, `stream` 15, `stream-consumer` 22; daemon and CLI `tsc` clean; `test:repo` 309/0.
## Note
- **Migration 133:** #1897 takes 131 and #1895 takes 132. Whichever merges second may need a rebase of the migration list here.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What a user gets
Two of the scenarios in the library can now run as checks instead of sitting in the not-yet-runnable table. The scenario format declares five emit behaviors, and the runner bound one of them: `refocus` fired the real refocus hook, while `compaction`, `restore`, `slow_output` and `mid_turn_death` threw an unbound-action error by name. The `compaction-restore-resumes-role` scenario uses exactly the two behaviors whose shipped seams already exist, so it read as a scenario waiting on its runner. That runner gap is now closed for those two: `emit compaction` fires the packaged precompact hook the same way the stub runner's own script step does, so the seat gets its keyed restore-pending marker, and `emit restore` fires the restore bridge, which reads that marker and injects its one-shot directive, which the runner then mirrors to the seat's pane. `slow_output` and `mid_turn_death` stay unbound and still refuse by name, because their stub behaviors are pane mechanics rather than shipped seams, and binding them for real is a different piece of work.
## How you verified it
Tested on `e4d7f15a` with the change on top, on Windows with Node 24.21.0. The new `packages/daemon` `scenario-emit-behaviors.test.ts` passes 5 of 5. It covers the refusal of a behavior with no binding, the compaction seam receiving the seat's own identity (session name, the transcript path the stub runner derives from the seat cwd, the scenario daemon's `OPENRIG_HOME`, the seat's managed cwd) and reporting the marker it wrote, the restore seam receiving the same identity and its directive mirrored to the pane verbatim through the product's send path, a restore that delivers nothing failing loud instead of passing silently, and a seam error surfacing with its own message. The two behaviors are injectable on the runner options, which is what lets those tests assert the identity without running tmux. `packages/daemon` `scenario-normalizer.test.ts`, `stub-script.test.ts` and `run-scenarios-flag-refusal.test.ts` all pass (34 cases together), so the format, the stub script model and the CLI flag guard are unchanged. `npx tsc --noEmit` passes for the daemon project and `npm run lint` passes for all four packages. What I could not run: the `compaction-restore-resumes-role` scenario itself needs a scenario runner with tmux, and this machine has none, so the end-to-end run is the one proof still outstanding; the dispatch, the identity and the mirror text are covered by the unit tests. I also did not run the full `npm test` or the UI suite.
## Anything you were unsure about
The mirror of the restore directive goes through the product's send path, which the scenario file's own header describes as the runner mirroring the delivered directive to the pane verbatim. An alternative would have been a new control channel into the running stub, so the pane mirror comes from inside the seat the way the script steps do, but that is a change to the stub runner's contract rather than a binding, and the send path already delivers a terminal seat the exact text. If you would rather the mirror come from inside the seat, that is a follow-up I am happy to take. The `slow_output` and `mid_turn_death` behaviors are deliberately left unbound: firing them for real means pacing pane output and killing a seat mid-turn from the runner, which is a separate design decision. The compaction seam is given the stub seat's own transcript path rather than letting the hook discover one, because the restore bridge's premise gate delivers only when the event's transcript matches the one the marker recorded, and the stub's own authored transcript is the deterministic choice.
## If this is security-related
Not security-related. The change is inside the test harness: no route, credential, boundary or product behavior moves, and the seams it fires are the same shipped hook scripts the stub runner already executes for its own script steps.
- [x] One concern per PR; no version bump; no `CHANGELOG.md` edit
- [x] Tests added or updated where the change is testable
- [x] I listed the checks I ran, their results, and any checks I could not run
## Why
The packaged capability map (`onboarding-width/public-what-you-can-do.md`) still teaches through `capability-delta-v0.7.0`. So a fresh agent on 0.7.1 can't discover what 0.7.1 delivered unless it already knows which `--help` to ask. This refreshes the map on main, so the next package carries it. It's docs only.
## What changed (one file, +130/-24)
Everything comes from the 0.7.1 cut: its CLI and daemon source, and its packaged `reference/whats-new.md`.
- **The header** names `capability-delta-v0.7.1` and ninety top-level verbs (88 in 0.7.0, plus `acp` and `edge`). It points to `rig context get reference/whats-new.md` for what changed in the installed version.
- **Finding out what's true:**
- `rig ps --nodes`'s `ATTN` column, and reading it through `--json`/`--fields` rather than by column position.
- `rig seat status` showing a seat's planned next launch and its terminal policy.
- The `needs-input` pickup state.
- **Reaching another agent:**
- `rig send --urgent`.
- The override's stop-and-show on an input box that already holds text, plus `--type-without-checking`, with the combinations not yet checked on a live seat.
- The wider `target_needs_input` rule.
- `rig stream subscribe`, `read`, `subscriptions` and `unsubscribe`, `rig stream show`, and stream retention.
- `rig acp run`.
- Herdr tiles reattaching after a Herdr restart.
- **Work, wakes and teams:**
- `rig queue update --evidence-ref` on a close.
- `rig watchdog update` and the token/percent context thresholds.
- `rig up --name`, `rig edge add|remove`, and per-member Claude setup (`agent_file`, `append_system_prompt_file`, `plugin_dirs`, `advisor`).
- The community-harness conversation fields (`launch_result`, `resume`, `names_conversation`).
- **Recovery and settings:**
- `daemon.db_conflict` and `--allow-db-conflict`.
- `policies.claude_compaction.preparation_root`, and managed compaction resuming after a daemon restart.
- The typing-guard levels.
- `rig seat set-terminal-policy`.
- `provider.selected` and `rig setup --router-line`.
- Remote `--host` on `rig auth` and `rig seat restart`.
- The long-lived-token usage limit.
- **Tracking work:** `rig project wake --decide` and `rig project decisions status`, marked opt-in and off by default.
- **People:** every ask lands on the Feed, the person's `slack-subscription` decides what reaches Slack, and `--alert` is for what only they can do.
- **MCP:** the delegation-loop tools, `rig mcp serve --http` and `rig mcp token add`.
Opt-in and off-by-default features, and the known limits, are marked where they apply. Nothing merged after the 0.7.1 pin is described.
## Checks
- `node scripts/check-docs-guard.mjs` passes.
- There's no other copy of the map in the repo to keep in step.
- `generate-context-packs --check` needs a built daemon, so CI's repo checks cover it.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What
The release substance gate (`npm run gate:substance`) refuses `docs/reference/agent-startup-guide.md` because one accurate
sentence names the default compaction preparation root, `<cwd>/.openrig/compaction/preparation/`, and that path prefix is
on the deny list.
This adds that one sentence to `allowed_context_lines` in `scripts/internal-tokens.generated.json`, the existing exact-line
allowance (the file is the policy source despite its name; `gen-control-plane-json.mjs` copies it and never rewrites it).
The whole line must match, so appended text or a concrete path in place of `<cwd>` is still refused.
Unchanged: the deny tokens, the path prefixes, the guide, the gate and every runtime source.
## Tests
`scripts/internal-leak-scanner.test.mjs` gains one test against the product rules:
- the shipped guide scans clean, at its repo path and its packaged path;
- the sentence with appended text, or with a concrete directory in place of `<cwd>`, is still refused for `.openrig/compaction/`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What this gives a person
When a provider reaches its usage limit, or a seat would do better on the other runtime, a person or their operator agent can move that one live seat between Codex and Claude Code without rebuilding the team:
```bash
rig seat set-runtime dev-impl@my-rig --runtime claude-code --reason "Codex limit" --dry-run
rig seat set-runtime dev-impl@my-rig --runtime claude-code --reason "Codex limit"
```
The seat keeps its address, connections, open queue rows and in-progress claims, and its successor gets a handover of what it was doing. The new runtime takes over before the old one stops. If anything goes wrong before the cutover, the current occupant keeps the seat, and `rig seat status` says so.
This builds on the design in #1214 by @Aschenbath (a staging session with a pane swap, a durable switch record, one commit transaction, recovery that rolls back before commit and finishes forward after, and re-resolving the seat's materials for the target), rebuilt on today's main with the changes below.
## How it works
1. **Preview (`--dry-run`).** It lists the target's settings and where each comes from (an explicit option, the seat's agent spec for the target runtime, or the runtime's default), what is cleared, startup slash commands a switch doesn't run, and the costs. A seat that can't switch (another runtime, more than one pane, no current occupant, a target that isn't installed, materials that don't resolve, a switch already open) is reported here, before anything stops.
2. **Successor first, under the seat's lifecycle lease.** The switch is journaled (`seat_runtime_switches`), then the successor starts in a staging session with the seat's name, a reserved occupant generation and the target's own materials (its seat skill storage, projections and startup files, with the identity's `runtime:` line rewritten).
3. **Handover and confirmation.** The successor receives the predecessor's screen, the seat recap and its open rows, and confirms with `rig seat set-runtime <seat> --confirm <switch-id> --note "<what I'll do first>"`. The daemon accepts that only from the successor's own session and reserved generation. This is the evidence that the successor can carry on: its model read the handover, its tools run, and it reaches OpenRig as the seat. With no confirmation within 180 s (`--confirm-timeout`), nothing commits, the staged successor is retired, and the predecessor keeps the seat.
4. **Cutover.** The panes are swapped, then one transaction commits the seat's runtime, cleared settings, permission selection, startup context, session, binding and tenure. It moves in-progress claims from the predecessor's generation to the successor's, takes a snapshot for the switch (restore tier, so the newest default restore matches the new runtime), and records a `seat.runtime_changed` event. The predecessor is then retired and the successor is told it now holds the seat.
5. **Recovery.** At daemon start, and with `rig seat set-runtime <seat> --recover`, an interrupted switch is finished from its record: before commit it is rolled back (panes swapped back, staged successor retired); after commit it is finished forward and never handed back. Where the panes match neither side, nothing is touched and status says why.
**Who holds the seat** is decided by one fact, the switch's `committed_at`, which is set in the same transaction as the configuration. Its `phase` records physical progress, and `attention` records why recovery stopped.
## The checks stay narrow
During a switch, the predecessor and successor share the seat's session name. To tell them apart, the CLI now sends the caller's own occupant generation (`X-OpenRig-Occupant-Generation`, from the seat's `OPENRIG_OCCUPANT_GENERATION`). The daemon refuses only the two generations a switch record names, on the seat it names, on queue create, claim, unclaim, update, handoff and handoff-and-complete, send and broadcast, and every mutating seat route (`set-model`, `set-effort`, `set-permissions`, `set-cwd`, `handover`, `stop`, and the rest):
- `occupant_retired_by_switch`: the predecessor after commit;
- `switch_not_committed`: the staged successor before commit, except its own `--confirm` and `--recover`. A successor whose switch was abandoned stays fenced while its retirement is unconfirmed (the switch keeps attention), and recovery at the next daemon start retires it; a failed retirement isn't a release of custody.
No header, an unknown generation, re-adopted seats and every other seat behave exactly as before. The activity hook ignores a retired predecessor and a staged successor, and keeps the staged successor's native identity on the switch record rather than the seat.
## Refusals and error codes
The operation itself: `invalid_runtime_settings`, `runtime_unchanged` (it names `set-model`, `set-effort` and `set-permissions`), `runtime_switch_unsupported`, `runtime_target_unavailable`, `runtime_switch_pending`, `runtime_switch_failed` (`committed: false`), and `runtime_switch_confirmation_refused` on the confirm route. The CLI adds `runtime_switch_outcome_unknown` when it stops waiting (it points to `rig seat status`). On existing paths, there are two: `occupant_retired_by_switch` and `switch_not_committed`. The existing lease refusal `draft_aware_lifecycle` is unchanged.
A `rig send` to a seat that is switching isn't refused or kept waiting. The daemon holds it at once on the existing held path (`outcome: retained`, `reason: runtime_switch_in_progress`) and says the seat is switching and until when; a send that had already been waiting when the seat moved says nothing was typed and to send again. Both are on the send's own answer, so the CLI makes no extra request.
## Costs (also in the preview and `docs/reference/getting-started.md`)
- A new conversation: native history isn't converted; only the handover carries over.
- The same address, a different pane and scrollback.
- The team file isn't rewritten. The database and `rig export` show the new runtime, while an imported YAML keeps the old one, so a later converge reports a deferred `change_runtime`.
- Source settings are cleared, not mapped: model, effort, Codex profile and an explicit native permission choice. A model or effort the agent spec declares for the source runtime doesn't apply either. Member and rig permission policy are kept.
- Two processes until cutover.
- Messages sent to the seat during the switch are held, not typed, and need sending again afterwards.
- A failed switch can leave the target's prepared files.
- Codex and Claude Code, single-pane seats only.
## Known limits
- Claude launch additions such as an agent file aren't applied to a switched seat.
- Startup slash commands aren't run; the preview lists them.
- On a seat with the draft-aware typing guard, a person typing into the old pane during the switch stops it (the guard protects their draft), and the predecessor keeps the seat.
- A successor's context-usage sidecar may be cleared at commit by the name-keyed invalidator; it is rewritten on the next reading.
## Tests
All with fakes (no real agent seats). Each test states what the person or calling agent sees.
- **New:**
- `seat-runtime-switch-service`: preview, both directions, confirmation, no confirmation leaving the predecessor, exact claims, recovery at each point, and the fence on a switch's two processes. An abandoned successor that couldn't be retired stays fenced until recovery retires it, and a retired predecessor is refused on `set-model` and 11 other mutating seat routes while reads and other callers are unchanged. These cases failed first against the code without the fence.
- `runtime-switch-custody`: the two refusals and the unchanged cases. A send to a switching seat is held at once without being typed; a send after commit goes as usual; a send that waited while the seat moved says so; a seat with no switch is unchanged.
- `runtime-switch-materials`: settings from the seat's agent spec per runtime, cleared settings, target storage and startup files.
- `seat-runtime-switch-route`.
- CLI `seat-set-runtime` and `send-runtime-switch` (one request, the daemon's answer shown), plus a block in `client-headers`.
- **Daemon:** 38 files, the new ones plus the neighbouring suites (handover, launcher, queue, transport, activity, snapshots, restore, startup, tmux, migrations, stream subscriptions): 1,385 passed, 5 todo.
- **CLI:** `seat-set-runtime`, `send-runtime-switch`, `client-headers`, `local-owner-routing`, `send`, `send-header`, `seat` and `seat-lifecycle-verbs`: 8 files, 256 passed.
- **Build and docs:** the daemon build and CLI `tsc --noEmit` are clean, the first-run reference check reports 0 failures, and the docs guard passes.
Not run here: switches between real Claude Code and Codex seats in both directions, a real confirmation and a successor stuck at an approval prompt, a seat switching itself, real interruptions with a daemon restart, and a real restore after a switch. These need real accounts.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Problem
A Claude seat pinned to an undated model id, such as `claude-haiku-4-5`, answers with that model's dated snapshot id, `claude-haiku-4-5-20251001`. The model-divergence monitor compared the two strings exactly, so it proclaimed a divergence for a seat running exactly the model it was pinned to. Every Haiku seat pinned this way gets the false alert, and false alerts teach people to ignore the real ones.
## Fix
`modelsMatch` (`model-divergence-monitor.ts`), for `claude-code` only: after the existing exact comparison (pin through `CANONICAL_MODEL_PINS`, `[1m]` dropped), when exactly one side ends in a `-YYYYMMDD` snapshot date, the comparison drops that date.
- `claude-haiku-4-5` matches `claude-haiku-4-5-20251001`, and a pinned snapshot matches its undated id.
- Two different snapshot dates still diverge: someone who pins a dated snapshot means that one.
- `CANONICAL_MODEL_PINS` stays the single alias home, and nothing matches by containment. An unmapped alias such as `haiku` still diverges, as before.
- Codex, Pi and other runtimes keep the literal comparison. The Pi path's runtime-less call is unchanged.
## Proof
- **RED** (`ac8bf31f`, tests only, on main `a65262da`): the five match cases fail, because each proclaims; the eight divergence controls pass.
- **GREEN** (`a8ab416e`): `model-divergence-monitor`, `pi-effective-model-occupant` and `control-plane-census` pass 114 of 114, and the daemon typecheck is clean.
- **Controls that still diverge:** another family with a date (`claude-haiku-4-5` against `claude-sonnet-4-5-20250929`), two different dates, a prefix pin (`claude-haiku-4`), a trailing extra after the date, an unmapped alias (`haiku`), and `codex`, `pi` and no runtime.
## Cost
Source +9/-1, tests +40. No new setting, refusal or error code.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What a person gets
A seat stuck at a choice prompt while it holds open work now reaches someone. Before, a Claude seat at its usage-limit dialog could sit for many hours: every wake was correctly refused as `selection_prompt`, and nothing escalated. Addresses #81.
## Why it stayed silent
The prompt-refusal pass escalated only when the seat's own evidence read "blocked". For Claude, that evidence comes from a permission request a hook announced, or a hook that means "waiting on a person". A choice dialog such as the usage-limit one announces neither, so the read stayed "unknown" and the pass skipped the seat on every tick.
## The change
- **The refusal counts as evidence.** The transport's refusal names the prompt it read. While a seat's latest refusal is at a choice prompt (`selection_prompt`), the oldest open choice refusal that nothing newer has cleared reads "blocked" once it has held for one retry interval (`queue.wake_retry_interval_seconds`, 300 s by default). A prompt answered within seconds never escalates, a cleared choice prompt lends no age to a later refusal, and a choice prompt that stays up keeps its age when new work's refusal arrives. An episode closes when the seat resumes, and a clear or move-on hook retires the alert as before.
- **Choice-prompt alerts follow `queue.wake_human_rung`.** An alert whose every refusal was at a choice prompt is tagged `prompt-kind:choice`. Under `explicit-only` it stays with the operator seat as a visible row and posts to no person, unless that seat is a person. A permission prompt, which only a person can approve, keeps posting as before, including one that later joins an alert the setting kept from a person; delivery already accepted is never repeated. The default (`always`) is unchanged.
- **One choice-prompt alert to a person at a time on a machine.** While one choice-prompt alert has gone to the delivery engine and stays open, each other choice alert names it ("operator waiting on …") and waits, then posts after that one retires. A prompt many seats hit together, such as a shared usage limit, posts once instead of once per seat. Permission-prompt alerts never wait behind it. The waiting alerts stay visible rows.
- **Unchanged:** nothing is typed into the blocked seat; other refusal reasons with no evidence wait for evidence as before; the orchestrator rung still comes first.
## Who it reaches
- **The orchestrator rung:** the seat's orchestrator (the source of its `delegates_to` edge) is woken on one aggregate row. If that wake lands, the ladder stops there.
- **The operator rung,** when the seat has no orchestrator or its wake fails: the aggregate row goes to `workspace.operator_seat_name`, and the delivery engine posts an ALERT to the first entry in the human registry. With no registered human, the rung stays unresolved and the row is the only signal.
- A permission-prompt alert reaches that person whatever `queue.wake_human_rung` says. A choice-prompt alert does so under `always` (the default); under `explicit-only` it reaches a person only when the operator seat itself is one.
## Tests
- **End to end** (`held-wake-escalation.test.ts`): a Claude seat whose pane shows a choice dialog, with no hook. The real transport refuses the wake and records `(selection_prompt)`, the production prompt reader reads unknown, and after one retry interval the seat's orchestrator is woken. The seat gets no input.
- **The pass** (`prompt-blocked-alert.test.ts`):
- a choice-prompt refusal with unknown evidence: no alert inside the interval, then one post to the registry's first human after it, and never a second;
- two seats blocked together: one post, the other alert names it and waits, then posts after the first seat's prompt clears;
- a permission-prompt seat beside a choice-prompt seat: both post, and neither waits;
- under `explicit-only` with an agent operator seat: the choice alert stays with that seat, tagged, and posts nothing, while a permission alert beside it posts; a reminder refused twice at a choice prompt follows the setting too;
- a choice prompt cleared before a new choice or permission refusal lends it no age (both quiet), and one that never cleared keeps its age when new work's refusal arrives;
- under `explicit-only`, a permission refusal that joins a choice alert kept from a person posts once, as a new episode or as a reminder whose latest refusal changes kind;
- guards: another refusal reason with unknown evidence still waits; a choice prompt with newer clearing evidence stays quiet.
- **RED on main** (the first cases only): the end-to-end case wakes nobody, the single seat gets no post, and two seats get two posts. The guards pass there too.
- **RED on the first version of this change** (the later cases): the permission alert is held behind the choice alert; a cleared choice prompt's age raises an alert; under `explicit-only` the choice alert still posts; the reminder alert carries no choice tag. The continuity case passes there too.
- **RED on the second version** (the last two cases): the joined permission alert posts nothing.
- **GREEN here:** every CI job; `prompt-blocked-alert.test.ts` 80 tests.
## Limits
- With the default setting, a usage-limit dialog reaches the same person as any other prompt alert, at most one choice alert at a time per machine. Sending it to an ops seat instead takes `queue.wake_human_rung: explicit-only` and an operator seat that isn't a person; this change doesn't set either.
- Every choice prompt follows the setting, not only usage limits: under `explicit-only`, a choice only a person should answer (a resume picker, say) also stays with the operator seat, whose agent escalates it through the usual paths.
- While the first posted alert's seat stays blocked, later alerts on that machine wait unposted; they're visible as rows.
- Only `selection_prompt` refusals use the new rule. A watchdog reminder refused twice at a prompt keeps its existing path.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What a user gets
When a terminal client disconnects while an earlier input write is still in flight, later input that was already queued is no longer sent to the seat after the broker tears down. The write already in progress is allowed to finish; only queued writes that have not started are dropped.
## How you verified it
- On base `ccdce88e`, the deterministic regression test fails: the broker records and sends both `first` and queued `second` after teardown.
- On HEAD `091f28a3`, `npm run test -w packages/daemon -- test/terminal-session-broker.test.ts test/terminal-ws-route.test.ts` — 59 passed.
- On HEAD `091f28a3`, `npm run lint` — passed (daemon build plus TypeScript checks for daemon, UI, CLI, and TUI).
- `npm test` and the root `npm run build` were not run; the focused daemon tests and repository lint/typecheck cover the changed module and its route neighbor.
## Anything you were unsure about
The guard is inside the serialized input callback so it covers writes queued before teardown without changing the ordering or delivery of inputs while the broker is live.
- [x] One concern per PR; no version bump; no `CHANGELOG.md` edit
- [x] Tests added or updated where the change is testable
- [x] I listed the checks I ran, their results, and any checks I could not run
## What a user gets
Refs #1520.
`rig queue whoami --json` now resolves a project-tagged in-progress row against its catalogued project's missions root only when the row has exactly one distinct `project:` tag and that catalog entry is healthy. `--candidates` uses the same per-item resolution while keeping its host mission inventory and default `missionsRoot` on the configured `workspace.slices_root`.
Rows without a project tag retain the existing configured-root behavior. Missing, invalid, unreadable or duplicate catalogs, unknown or broken project entries, and multiple distinct project tags fall back to the configured root and explain the real reason in the basis instead of guessing or claiming that no root is configured.
## How you verified it
- Base-fail probe on the pre-fix `origin/main`: with catalogued `alpha` and `beta` projects sharing `release/slices/01-work`, `workspace.slices_root` pointed at beta, and an in-progress `project:alpha` baton, `whoami` returned beta's work-node path.
- Fix-pass: the same focused regression returns alpha's path for both `currentWork` and the opt-in `workCandidates` projection.
- `npm run build -w packages/daemon` — passed.
- `npm run lint` — passed.
- `npm run test -w packages/daemon -- test/current-work.test.ts` — 14 passed.
- `npm run test -w packages/daemon -- test/queue-routes.test.ts` — 209 passed, including route-level fallback coverage for missing, invalid, duplicate, unknown, broken and multiple-tag cases, plus candidate metadata.
- `test/refocus-work-packet.test.ts` was attempted separately; its 15 failures are in the native-Windows trace/resolver fixture path (CRLF/Unicode rendering and unavailable resolver command), not in the changed current-work unit or queue-route suite.
## Anything you were unsure about
- The route reads the existing project catalogue only when available. If the catalogue cannot be read, it preserves the configured-root behavior and records that fallback.
- The maintainer's separate decision about whether a selected project's root may fall back to the configured root for a missing mission/slice remains intentionally unchanged.
## If this is security-related
Not security-related. The bug affects queue context/refocus correctness inside a trusted OpenRig workspace.
- [x] One concern per PR; no version bump; no `CHANGELOG.md` edit
- [x] Tests added or updated where the change is testable
- [x] I listed the checks I ran, their results, and any checks I could not run
## What this does
Two changes for a Slack workspace with more than one registered person, so a reply that comes through the gateway keeps its sender's identity.
1. **A Slack reply from someone else doesn't resume another person's question.**
- When a different registered person replies in Slack to a question parked on someone else, their reply still reaches the agent as their own message.
- The question stays parked on its person, and nothing is written to it.
- Unchanged: a typed reply to a direct ask was already checked against its recipient, and a different person's button click is still ignored.
2. **Slack rows name who actually wrote.** A Slack message, answer or reaction lands on its row with a summary naming the registered person who wrote it (`<address> via Slack: …`), not one fixed title. Tags are unchanged.
## What doesn't change
- An action at the terminal (the TUI, the Feed, Mission Control's verbs) is the primary user's. It keeps its existing authority and is recorded as it is today.
- Agents are unaffected.
## Tests
- **New:** `slack-reply-from-another-person.test.ts`. A different person's Slack reply leaves the parked question untouched, while a terminal resolve of the same question works as before.
- **Updated:** the Slack inbound summary tests.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What and why
**The harm:** after an operator declined a Claude seat's permission prompt ("No"), the seat stayed unreachable. Every `rig send` was
refused with `(PermissionPromptConfirmed; latest hook, pane unrecognized)`, and `rig seat clear-attention` answered `not_in_attention`.
**How it happens:**
- **Where the state comes from:** `PermissionPromptConfirmed` is OpenRig's own record. The activity poller writes it when it sees a permission prompt on screen
(`startup.ts`, `permissionPromptChanged`), and it writes `PermissionPromptCleared` only once its screen read says definitely no prompt.
After the decline, the screen read as unrecognized, so nothing ever recorded the prompt cleared.
- **The send gate:** past the 15-second send window it reads the pane. When the pane is unrecognized, it keeps a latest hook that says the
seat waits on a person (`classifySendReadiness`). That rule is deliberate: it stops a send from pressing Enter on a picker the pane can't
show. So the decline left a refusal that nothing could clear.
- **`clear-attention`:** it knew only the startup, restore and pane-identity classes.
**What changes:**
- **A new class for `clear-attention`:** a latest hook that still says the seat waits on a person, or a Codex pending permission.
- Without `--reason`, it says what to do instead of `not_in_attention`.
- With `--reason "<what you saw>"`, it records `PermissionPromptCleared`, the event the poller writes when it sees a prompt go, and an
`attention_cleared` event carrying the reason.
- Sends and wakes then go through. The send gate still reads the pane on every send, so a prompt it recognizes still refuses.
- **The refusal names the way out:** when a refusal rests on a retained hook alone (a Claude waiting hook, or a Codex permission request the
pane can't confirm), it adds "Look first: `rig capture <seat>`. If that prompt is gone (declined or answered), clear it:
`rig seat clear-attention <seat> --reason "<what you saw>"`." The CLI help mentions the class.
**Why not automatic:** recognising the post-decline screen would let the poller clear on its own, but no capture of that screen exists.
Treating every unrecognized pane as clear would drop the picker protection. The operator who declined the prompt can say it's gone.
**The activity service too (round 1):** the clear also settles the activity service's pending prompt
(`SeatActivityService.settlePermissionPrompt`, wired in `startup.ts`). So the wake ladder, which asks that oracle first, and `rig ps` agree with
the clear instead of reading the seat blocked. A new permission hook starts a new request.
U3 (#1892) is merged, and this builds on it.
## Cost (net vs main, after round 1)
| | Lines |
|---|---|
| Source: `seat-attention-reconciler.ts` | +38/-5 |
| Source: `session-transport.ts` | +16/-4 |
| Source: `seat-activity-service.ts` | +16 |
| Source: `startup.ts` | +1 |
| Source: CLI help in `seat.ts` | +6/-2 |
| Tests | +107/-2 |
- **New refusals:** none of anything that works today. The new class only adds a way to clear; without `--reason` it explains instead of
clearing.
- **New codes or settings:** none.
## Proof
**Round 1** (`440482bd`):
- **RED** (round 0's four source files, the round's tests): 6 fail. The activity service still counts the prompt after the clear (1, not 0).
The four Codex hook-only refusals lack the hint, and the Claude hint lacks "look first".
- **GREEN:** 15 files, 744 tests, adding the Claude and Codex permission-pending and held-wake escalation files. The new case runs through
a real `SeatActivityService` and `makePromptStateReader`: blocked before the clear, clear after, and no re-confirmation on the next poll.
- **Typecheck:** daemon `tsc` is clean.
**Round 0:**
- **RED** (main's two source files, the new tests): 3 fail.
- `clear-attention` answers `not_in_attention` with and without a reason.
- The refusal carries no hint.
- **GREEN, the touched files:** 133 tests across `seat-attention-reconciler` and `send-prompt-guard`.
- **GREEN, adjacent files:** attention, needs-input provenance, claim-hint prompt guard, parked-owner consumer, prompt answer delivery,
prompt-blocked alert, prompt-clear continuation, wake ladder, sessions routes, session-transport. 694 in total.
- **Typecheck:** daemon `tsc` is clean.
- **The CLI change** is help text only; no CLI test pins it.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
`rig <verb> --help` lists each subcommand with its description. These 14 had none, so their parent's help showed a blank summary:
- `rig chatroom send`, `history`, `watch`, `topic`, `wait`, `clear`
- `rig project experimental enable`, `disable`, `status`
- `rig context profile`
- `rig health diagnosis record`
- `rig env status`, `logs`, `down`
Each new summary is taken from what that command's action does.
`lazy-program.test.ts` gains one case. It walks `createProgram()` and requires every command to have a description, so a new command can't land with a blank summary unnoticed. The same traversal finds the 14 blanks at `7923e13e` and none on this branch.
Text only, apart from that test. No behaviour, option or output changes. `docs/as-built/cli-reference.md` doesn't list descriptions, so it is unchanged.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What a user gets
Codex resume detection recognizes a resumed Codex TUI whose status footer uses a versioned non-`gpt-*` model identifier, including the warning layout reported in the issue.
The process-corroboration proof now reaches every relevant path:
- Runtime adapter readiness and resume checks.
- Strict full-restore reconciliation of an already-flagged agent.
- Startup route pane observation.
The strict reconciler reuses its existing exact Codex resume-token process proof instead of performing a second identity check. The startup route uses the shared process census for the same verify-and-reprobe behavior.
Non-`gpt-*` footer evidence is accepted only when its status row appears below the last composer line. This prevents a stale shell capture such as `project2 · main` followed by `› codex resume ...` from being promoted when Codex has only just become the foreground process.
Trust, update, hook, and model-selection gates remain intact.
## How you verified it
- Probe and startup route tests — 176 passed.
- Focused runtime stale-shell and warning-footer tests — 2 passed.
- Focused strict restore reconciliation test — 1 passed.
- `npm run build` — passed.
- `npm run lint` — passed.
- `git diff --check` — passed.
The full daemon/repository suites were attempted on Windows but include unrelated existing environment-dependent failures, including Unix shell-path assumptions, temporary repository path handling, missing native `better-sqlite3` build prerequisites, and fixture/package guard failures.
## Anything you were unsure about
Upstream GitHub Actions still needs its normal maintainer approval for this fork's workflow run; local verification is green for the changed paths.
`docs/as-built/cli-reference.md` said it was verified against `92a2b8f7`. This regenerates its command tables and counts from the Commander tree returned by `createProgram()` at `7923e13e`, the file's own method.
**Counts:** 90 top-level registrations, 399 registered command objects and 1,255 option objects (previously 87, 356 and 1,084).
**What changed in the tables:**
- New rows: `rig seat set-terminal-policy`, `rig seat set-effort`, `rig seat effort`, `rig seat restart`.
- New options: `rig daemon start --allow-db-conflict`, `rig send --type-without-checking`, `rig queue transitions --full`, and `rig seat launch --plan`. `rig seat launch --reason` is no longer required.
- `rig gateway human show` and `set` now appear in registration order.
The hand-written notes under the tables and inside option cells are kept. Each was checked against the current source.
**How it was checked:** every table row was parsed back and compared with the walked tree, and all 399 rows and their options match. The same walk at `92a2b8f7` reproduces that version's 87 top-level registrations and 356 command objects.
Docs only. No source, test or other doc changes.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What this changes
A cross-host `rig queue create`, `handoff` or `handoff-and-complete` goes to the selected daemon, which forwards it to the remote daemon with a 10 s deadline (`QUEUE_FORWARD_TIMEOUT_MS`). When the remote is slow, two things made the write read as failed even though the row could still land.
1. **The daemon's forward timeout is now an unknown outcome** (`routes/queue.ts`).
- **Before:** it answered 502 `remote_queue_write_failed` with `failureClass: "unreachable"` and no outcome. But the write had been sent, so the remote may still commit it.
- **Now:** it also carries `outcome: "indeterminate"`, and the detail says "the remote may still commit it". `failureClass` is unchanged.
- **What the CLI does with it:** it already renders that outcome as "The write outcome is INDETERMINATE … reconcile by ID before any retry", with the request ID and recovery steps.
2. **The CLI waits for the daemon's answer** (`commands/queue.ts`).
- **Before:** it waited only its 5 s client default, so a remote that answered in 5–10 s became a local timeout, though the daemon would have returned the remote's answer.
- **Now:** cross-host queue writes wait 15 s, longer than the forward deadline. Writes to the local daemon keep the default. Cross-host `rig send` already waits longer for the same reason.
3. **The CLI's timeout headline** now reads "queue request got no answer in time (routing to host '…')" instead of "queue transport failure". The INDETERMINATE line and the recovery ID still follow.
## Why
A caller told "failed" (or "unreachable") retries, and a retry without the original ID creates a second row once the first one lands. A timed-out cross-host write should read as unknown, with the ID to reconcile by, which is what the CLI already does for its own lost connections.
## Tests
- **Fail-first:** with these tests on the unchanged source, the new daemon case and four CLI cases fail. The local-default cases pass before and after.
- **New daemon case** (`queue-cross-host-create.test.ts`): the origin hasn't answered when the 10 s deadline passes (fake timers). It returns 502 `unreachable` with `outcome: "indeterminate"`, and nothing is written locally.
- **New CLI file** (`queue-cross-host-write-wait.test.ts`):
- cross-host create, handoff and handoff-and-complete pass `timeoutMs: 15000`, and local ones pass no override;
- a CLI timeout reads "no answer in time" and INDETERMINATE, with the `--id` to reconcile by.
- **Runs:**
- daemon `queue-cross-host-create` and `queue-cross-host-handoff`: 70 passed;
- CLI `queue-cross-host-write-wait`, `queue-host-refusal-hint`, `d14-loud-queue-transport-failure` and `queue-write-receipt`: 120 passed;
- the daemon build and CLI `tsc --noEmit` are clean.
- **Not run:** `queue-host-qualifier-route` (it spawns the built CLI), the full suite, and a real slow remote.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What and why
`rig up` could report a seat **launched** (status `completed`, exit 0) when tmux had made no session at all. The only signs were follow-on
warnings such as `error connecting to <socket> (No such file or directory)`.
- **The cause:** tmux can exit 0 having made nothing. When the server can't create its socket, it prints
`error creating <socket> (Permission denied)` and quits, and the client still exits 0. That happens, for example, when the socket's parent
directory exists but this user can't write to it. `createSession` treated exit 0 as created.
- **The change:** `new-session -P -F '#{pane_id}'` prints the pane it made. When it prints none, `createSession` reads the session back
with `has-session`, and only a found session keeps the launch.
- **A positive "can't find session"** fails the launch as `session_not_created`.
- **A read-back that can't reach or read tmux** (no server, a socket error, an unexpected probe failure) fails it as
`session_unconfirmed`: "tmux returned exit status 0 without a usable pane id; creation of session … could not be confirmed (…)". The
message carries tmux's own read-back error and says what to check: the `TMUX_TMPDIR` directory, or the directory of an explicit `-S`
socket path, must be writable by this user. `probeSession` itself documents a no-server answer as "not determined", so it isn't
reported as absence.
- **What's preserved:** normal pane output takes the unchanged path, and a launch that prints no pane but whose session is found still goes
ahead.
## Measured (tmux 3.6a; private sockets, sentinel names)
| Command, with the socket's parent present and mode 0500 | Exit | Output |
|---|---|---|
| direct `new-session -P -F '#{pane_id}'` | 0 | `error creating … (Permission denied)` on stderr, no pane id |
| `has-session` | 1 | `error connecting to … (No such file or directory)` |
| the same `new-session` with an unwritable `TMUX_TMPDIR` | 1 | (the client can't create the directory, so main already reports failed) |
Another platform showed the same with tmux 3.2a.
## Notes
- **The shared classifier is unchanged.** `probeSession`'s transport classifier doesn't recognise an explicit `-S` path's error (the message
starts with `Command failed:` and names no `tmux-<uid>` path). So the read-back uses tmux's own stderr directly rather than widening a
classifier every caller shares.
- **On top of #1907:** main (`e3ee9e0c`, #1907) is merged in. The read-back follows #1907's `runEnvironmentCommand`, so it covers its
`start-server ; source-file` chain too, which exits 0 the same way.
## Cost (net vs main `e3ee9e0c`)
| | Lines |
|---|---|
| Source | +28 in `tmux.ts` |
| Tests | a new file, `tmux-create-readback.test.ts`, +78 |
| Adapted stand-ins | 6 one-line changes, so `new-session` prints a pane id as real tmux does; their pinned command lists are unchanged |
- **New codes:** `session_not_created` and `session_unconfirmed`, only where no session was confirmed.
- **New refusals or settings:** none.
## Proof
**After the main merge and review50-r2's N1** (head `e8e5805a`; merge `89a20fc7`, then the N1 commit):
- **RED:** the pre-N1 read-back with the N1 tests fails 3: unconfirmed versus not-created, and the real tmux case.
- **GREEN:**
- 31 tmux and launch files (599 tests), including #1907's credential and argv files.
- 33 more files that create sessions through a real adapter: 659 pass. 5 Pi native "runner ready" timeouts fail identically on main
`e3ee9e0c`.
- Daemon `tsc` is clean.
- **Not separately run:** the intermediate merge commit; only the head was tested.
**Before the merge:**
- **RED** (`tmux.ts` at main, the new test file): the no-pane, no-server case and the real tmux case both read `ok: true`. Main's file was
restored afterwards and confirmed with `cmp`.
- **GREEN:**
- The new file: 4 tests, including the real tmux case, which is skipped on Windows, without tmux, and as root.
- The adapted `tmux-adapter` and `tmux-argv-exec` files: 158 in total with the new file.
- The other 27 tmux and launch test files pass.
- 33 more files that create sessions through a real adapter: 659 pass. 5 Pi native "runner ready" timeouts fail identically on main
(environment).
- Daemon `tsc` is clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What this changes
The openrig-user skill's "After a queue write" section, and the regenerated skill digest. No code changes.
- **The request ID.** `rig queue create` prints `Queue create request ID: <id> (not proof of persistence)` on stderr *before* it sends the write, so an interrupted create can be reconciled. The section now says:
- that ID names a request, not a row;
- the row is the `qitemId` in the answer on stdout, and a non-zero exit means no row was confirmed;
- don't merge stderr into stdout and keep the first `qitem-…`.
- **Proven refusals.** The section listed every 502 `remote_queue_write_failed` as indeterminate. A 502 whose `failureClass` is `unknown-host`, `unsupported-transport` or `registry` is refused before any host is contacted and writes nothing, which is what the CLI already reports ("No row was created"). `unsupported-transport` means the host entry is SSH-declared; `rig host list` shows its http entry.
## Why
Queue writes to another host go through the selected daemon, which forwards them only to an http-transport registry entry. For an SSH-declared entry it answers 502 `unsupported-transport` before contacting the host, and nothing is written anywhere (`queue-cross-host-create.test.ts`, "ssh host: unsupported-transport (502), NOTHING written locally").
The CLI reports that honestly: the refusal, exit 2 and "No row was created". But a caller that runs `… 2>&1 | grep -oE 'qitem-[0-9a-z-]+' | head -1` keeps the request ID, which is printed first. It drops the refusal, and the pipeline's exit status hides exit 2. The caller then holds an ID for a row that doesn't exist. The skill is where agents learn how to read a queue write, so this is the place to say it.
## Checks
- `node scripts/mirror-skills.mjs --check`, `node scripts/generate-context-packs.mjs --check`, `node scripts/check-docs-guard.mjs` and `node --import tsx scripts/check-first-run-references.mjs`: pass.
- `node --test scripts/mirror-skills.test.mjs`: 34 passed.
- Vitest, `--maxWorkers=2`:
- daemon `openrig-core-plugin`, `queue-cross-host-create` and `queue-cross-host-handoff`: 117 passed;
- CLI `queue-host-refusal-hint`: 26 passed.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What and why
An outside audit raised two questions about labels (credited in #1918, from Heretek-AI/heretek-rigs#81 part b).
**1. The stuck sweep's recovery rows look like they came from a person or seat that never sent them.**
- **The cause:** a recovery row's source is the stuck row's creator (`queue-stuck-sweep.ts`, "the obligation's own creator is the finding's source"). `create()` staged the wake with that source as the envelope sender, so the seat saw "From: <creator>" and "↩ Reply: rig send <creator>". That creator never sent it.
- **The change:** a row OpenRig creates itself (`wakeTrigger: "openrig"`) now wakes from `daemon@kernel`, the scheduler's existing sender name. The envelope offers no reply for OpenRig's own senders; it says "↩ Sent by OpenRig itself, not by a seat. Act on the row it names."
- **Unchanged:** the row's `source_session`, its admission, and its urgency marking. A source that is already OpenRig's (`daemon@kernel`, `system:health`) keeps its own name.
**2. `identityProvenance: transport:v1` reads as stronger than it is.**
- **What it records:** the label is accurate. It means the name came from the `X-OpenRig-Session` header, which the CLI sets from the seat's `OPENRIG_SESSION_NAME`, rather than from a body claim. The reference docs already say so.
- **What overclaimed:** two user-visible `actor_required` messages said "no authenticated transport identity", and several comments said the header "proved" or "certified" the actor.
- **The change:** those are reworded, and `coordination-primitive.md` gains one sentence saying it isn't authentication.
- **Unchanged:** the label, the stored values, and every refusal.
## Rows that change wake sender
| Creator (`wakeTrigger: "openrig"`) | Row source | Wake sender before | After |
|---|---|---|---|
| stuck sweep finding | stuck row's creator | that creator | `daemon@kernel` |
| workflow exception escalation | instance creator | that creator | `daemon@kernel` |
| health diagnosis, periodic | `system:health` | `system:health` (with a reply line) | `system:health`, no reply line |
| health diagnosis via `rig health diagnosis evaluate --apply` | the seat that ran it | that seat | `daemon@kernel` |
| continuity cutover baton (watchdog) | the registrant | the registrant | `daemon@kernel` |
| mode scheduled end | `daemon@kernel` | `daemon@kernel` (with a reply line) | `daemon@kernel`, no reply line |
**Why the relabel sits in `create()`:** at wake time, trigger `openrig` also covers boot recovery and ladder retries of rows that agents created. Relabeling there would hide real senders; only `create()` knows that OpenRig itself made the row.
**What counts as OpenRig's own sender:** `daemon@kernel` and `system:` actors. Neither can be a seat's name (`{pod}-{member}@{rig}`). `…@system` isn't matched, because a rig may be named `system`.
## Cost
| | Lines |
|---|---|
| Source, net vs main | +42/-29 |
| of which behaviour: `queue-repository.ts` | +6/-3 |
| of which behaviour: `pane-envelope.ts` | +9/-1 |
| of which wording only (7 files) | the rest |
| Tests | +42/-1 |
| Docs | +3/-1 |
- About 1 test line per source line.
- **New refusals:** none. **New error codes:** none. **New settings:** none.
## Proof
- **RED:** the new test files were run against main's three source files (`pane-envelope.ts`, `queue-repository.ts`, `require-sender-identity.ts`), with everything else at this head. 5 cases fail. The recovery-row case received `From: peer@test`; the envelope case received `↩ Reply: rig send daemon@kernel "..."`; both message cases received "no authenticated transport identity"; the held copy was `senderSession: peer@test`. The fixed files were restored and confirmed byte-identical with `cmp`.
- **GREEN, daemon:** 23 files, 911 tests at `--maxWorkers=2`. In the first run, 910 passed and one new case failed on the test's own mistake: a peer's routine wake is held, not typed, at that level. I fixed the test, and its file then passed alone, 21 of 21. The set:
- the four changed test files;
- stuck sweep (both), workflow exception (four), health diagnosis, continuity materializer, mode scheduled end;
- wake ladder, held-wake escalation, parked-owner consumer;
- local-bare-identity, self-host envelope (triple and sweep), session-transport, queue nudge summary, transactional closure, s02-p3-sender.
- **Typecheck:** daemon `tsc` is clean.
- **CLI:** send, send-header, client-headers, self-host-triple: 129 tests.
- **Repo:** `npm run test:repo` 309 pass, 0 fail.
## Base
Built on `26d629e3`. Main has since gained only #1903, which touches `queue-stuck-sweep.ts` and its test; there's no overlap with this PR.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
2026-10-24 07:45:45 -07:00
868 changed files with 55354 additions and 5536 deletions
Then type `/rigs` in Claude Code, or `$rigs` in Codex, and say what you want built. The skill has your agent tell
@@ -68,11 +68,11 @@ Requires Node.js 22 or 24 and tmux, on macOS or Linux, and one working Claude Co
### Install it yourself
This runs OpenRig's install script from the `v0.7.0` release. It checks Node.js and npm, installs the latest published `@openrig/cli` with `npm install -g`, runs the Node.js and SQLite check, then runs `rig setup --dry-run` and `rig setup`. The first line prints that plan and changes nothing:
This runs OpenRig's install script from the `v0.7.4` release. It checks Node.js and npm, installs the latest published `@openrig/cli` with `npm install -g`, runs the Node.js and SQLite check, then runs `rig setup --dry-run` and `rig setup`. The first line prints that plan and changes nothing:
```bash
curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.7.0/scripts/install.sh | sh -s -- --dry-run
curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.7.0/scripts/install.sh | sh
curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.7.4/scripts/install.sh | sh -s -- --dry-run
curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.7.4/scripts/install.sh | sh
```
If a provider isn't signed in yet, the last step reports `FAILED [4/4]`, and `rig setup` lists the sign-in under "Some steps need attention". If the only remaining failures are provider sign-ins, the install steps finished; sign in to each selected provider as below and continue.
# --- layer 2: pinned node (an in-range engines version — see scripts/check-engines) ---
ARGNODE_VERSION=22.22.1
ARGNODE_VERSION=22.23.4
ARG TARGETARCH
RUNset -eux;\
case"${TARGETARCH}" in \
@@ -33,10 +33,14 @@ RUN set -eux; \
"")echo"TARGETARCH is empty — the legacy (non-BuildKit) builder does not populate it. Pass --build-arg TARGETARCH explicitly (build-testbed-image.sh does) or enable BuildKit. REFUSING to default to amd64, which would install wrong-arch Node." >&2;exit1;;\
cross-runtime v0 standard — Claude Code and Codex transcripts both supported
via runtime parsers + redaction (`packages/cli/src/restore-packet/`).
### Shared history inspection
`GET /api/startup/:rigId/nodes/:nodeId/history` lists captured histories for one durable node in the current, policy-ranked restore snapshot. `POST` to the same path plus `/validate` with exactly `{ "snapshotId": "…", "historySessionId": "…" }` rechecks one listed choice. Both routes use startup's terminal bearer authentication. The CLI exposes the same server decisions with `rig seat history --rig <rig-id> --node-id <node-id> --json`; pass both `--snapshot-id` and `--history-session-id` to validate. These calls perform no snapshot capture, token refresh, launch, or database write.
The list includes captured Claude and Codex rows that the current restore policy and native resume adapter can structurally attempt. Codex requires an explicit `codex_id` and token; implicit `codex_last` cannot name a particular history. Claude accepts `claude_id` and `claude_name` with tokens. The server checks exact rig and node membership, the snapshot's intended roster and runtime, and the node's current occupant compatibility. A change to a sibling node does not retarget or invalidate this node's list. A changed or pruned snapshot, removed history row, same-name replacement node, ambiguous current occupant, or incompatible source is refused; validation never substitutes another history.
`tokenState` (`present`, `stale`, or `unverified` for listed rows) describes the saved verification record and its age. Eligibility means a future launch may **attempt** native resume. A stored row can share a native token with another row, and neither listing nor validation proves that a native conversation still exists.
### Selected history startup
`GET /api/startup/:rigId/nodes/:nodeId?snapshotId=<listed-id>&historySessionId=<listed-id>` returns a read-only review for one listed choice: the selected row's forecast, current terminal observation, consumed launch setting sources (including a member permission envelope or Claude rules), and an opaque revision. The permission view uses restore's pure policy resolution: a readable custom policy's current launch posture can supersede its persisted cache, and a changed resolved decision requires re-review. It refuses a captured row whose native type/token, provenance, restore policy, or harness no longer agrees with the live registry row. The response contains no native token. `POST /api/startup/:rigId/nodes/:nodeId` accepts exactly `{ "action": "resume", "snapshotId": "…", "historySessionId": "…", "revision": "…" }`. Both routes require startup's terminal bearer token. The selected route accepts no fresh, continue, arbitrary token, or alternate target. Review does not capture a snapshot or prepare a provider. `rig seat history` also uses a strictly read-only daemon status check, so inspection does not remove stale daemon state.
Apply revalidates the same current compatible source, durable node and saved launch settings after prerequisite and presence checks. The existing narrow restore engine carries that exact historical row through legacy and pod-aware native resume, with a second identity check at native dispatch after preparation. Before the new registry row is committed, selected startup also checks that no other attachment or running occupant claimed the node during terminal creation or pane observation; a collision leaves that claimant intact and reports the terminal outcome for inspection. An occupied or uncertain terminal blocks the attempt. No alternate history or fresh conversation is selected. The response projects exact typed references and outcome fields; only diagnostic text is redacted, so even a short native name cannot corrupt an ID. It names the selected source row and the newly registered result row when one exists; only the engine's joined native continuity proof produces success. If a change occurs after shell creation, the result reports a partial or uncertain attempt for inspection. The existing engine handles native prerequisites, compensation and proof. This surface adds no separate per-agent prelaunch probe; native checks remain at execution. Physical tmux cleanup still addresses sessions by name, so it cannot prove ownership against an external same-name replacement outside the selected registry guard.
## See also
- `agent-spec-and-startup.md` — StartupOrchestrator persists the replay
| `handoff` | same closure and new destination item as `route`; the 4-step shape (see below) |
| `resolve` | only for a `blocked` item parked on a human seat: moves it to `in-progress` with the required decision text as the transition note; no closure and no new item (`:369`, `:386`, `:410–411`). After commit it sends a best-effort nudge with the decision text to the item's owner unless `notify: false` (`:450–467`); the CLI wrapper is `rig queue resolve <qitemId> --decision <text>` (`packages/cli/src/commands/queue.ts:828`) |
| `resolve` | for a `blocked` item parked on a human seat or a well-formed typed gate (`external:`, `fold:`, `auth:`): moves it to `in-progress` with required decision/satisfaction evidence in the transition note; typed waits are recorded as blocker resolutions, not human decisions. Qitem dependencies, malformed gates and non-blocked items are refused; no closure and no new item (`:369`, `:386`, `:410–411`). After commit it sends a best-effort nudge with the decision text to the item's owner unless `notify: false` (`:450–467`); the CLI wrapper is `rig queue resolve <qitemId> --decision <text>` (`packages/cli/src/commands/queue.ts:828`) |
| `answer` | only for a `pending` ask addressed to the acting person: a choice (`questionId` + `optionId`) through `QueueRepository.recordHumanAnswer`, or their words (`decision`) through `resolveDirectHumanReply`, each with its existing meaning (a partial choice set stays pending; words fill the first unanswered question). Once answered, one reply row goes to the asking seat (`human-answer` tag, `replyTo` the ask, an id derived from the ask) and then the ask closes once with `human-decision-resolved`, the order Slack's answer continuation uses. With neither a choice nor words, a complete question set whose return didn't finish is sent again with exactly its recorded answers. A closed ask answers 409 `qitem_already_terminal` and records nothing; a refused answer is 400 `answer_not_recorded`; 409 `answer_not_closed` means the ask stayed open: its return failed, it changed before its close, or a retry came in other words than the reply already returned (that retry isn't sent). The TUI's Feed sends it |
`annotate` requires `annotation`, `hold` and `drop` require `reason`, `route`
@@ -114,8 +114,8 @@ the audit record instead; the wrapped `reason_required` error has no status
mapping, so it returns 500 (`mission-control-action-log.ts:128–133`,
`mission-control-write-contract.ts:245–248`). Items already `done` or
`handed-off` are refused with 409 `qitem_already_terminal`, except under
`resolve`, which answers 409 `qitem_not_leg1_parked` for any item not parked on
a human seat. An unknown item returns 404 `qitem_not_found`
`resolve`, which answers 409 `qitem_not_leg1_parked` for any item that is not
blocked on a human seat or a well-formed typed gate (`external:`, `fold:`, `auth:`). An unknown item returns 404 `qitem_not_found`
Each verb except `answer` is one atomic daemon transaction (`answer`'s queue writes are the repository's own, in the order above, then its audit row and event): the queue mutation via
@@ -112,3 +112,7 @@ When a regression reaches a release, add one line: date, issue, artery, and whic
- 2026-10-19, #1483, managed compaction: a helper-only command-composition check did not bind the submitted command to the precompact effect. `managed-compaction-effect.test.ts` now drives the real enforcer command into a version-bound stub input model and checks the shipped precompact marker; its 851-character pasted-command control lacks that effect despite a successful submit receipt. `rig compact` rejects stub runtimes, so this is an adapter/helper check, not an installed CLI or native compaction proof. The model uses the recorded Claude Code 2.1.282 distinction; other versions and actual context compaction remain unverified here.
- 2026-10-19, #484, refocus orientation: script tests supplied basis strings without composing parked typed queue state through `queue whoami` and the hook. `refocus-parked-baton.yaml` plus the active-baton contrast now assert the shipped hook's own emitted context; installed-scenario runs healthy/seeded/healthy; its scratch trace-child fault moves the parked row from held work into the work candidates as current work, and the hook's emitted context must then fail with that row's slice shown as `WORK FROM QUEUE EVIDENCE`. This proves the composed diagnostic effect, not native hook scheduling or an agent reading and acting on it. With the work packet's bounds and per-runtime default, the parked scenario runs with the packet on and asserts the row as held work. `refocus-parked-baton-packet-off.yaml` keeps the labelled fallback as the packet-off control.
- 2026-10-23, F1 (0.7.0 candidate `2fec7382`), launch (a fresh Codex kernel): a fresh Codex kernel stopped at Codex's hook review. Caught at the cut, before publication, by native first-user and daily runs. Missed by the stub layer, which has no real Codex binary. Fixed in #1824.
- 2026-10-24, B6 (0.7.1 candidate `7badb557`), launch and resume (Codex hook trust): after an upgrade from 0.7.0, a Codex seat stopped at "Hooks need review: 6", because Codex 0.164 asks to approve a plugin's whole content again. Caught at the cut, before publication, by a native upgrade run with a real Codex. Missed by source tests and stub scenarios (a stub can't see the real Codex binary) and by the installed-upgrade check (no real Codex). Fixed in #1948. Scenario owed: a cheap real-agent Codex upgrade with approval renewal.
- 2026-10-24, pane-only attention (#1876 on the 0.7.1 candidate), native observation: a Codex seat waiting at a prompt that only its pane showed read as working, with no attention signal. Caught at the cut, before publication, by real work on a test machine. Missed by fixtures that all carried hook signals. Fixed in #1946. Scenario owed: a stub pane showing a selector with no hook event must read as needing attention.
- 2026-10-25, #1955, delivery (send readiness): approval-prompt text that a working Claude seat quoted in its own output read as a waiting prompt, so sends and queue wakes to that seat were refused. This one was present since 0.7.0, so it did reach a release; it was found during the 0.7.1 cut by real work on a test machine. Missed by classifier fixtures that had no working pane quoting prompt text. Fixed in #1955 for 0.7.2.
- Several people may be registered. Organizations, groups, readable policy, shared channels and the default person are
kept in `$OPENRIG_HOME/gateway/participants.yaml`, never in a person's fragment, so an older daemon still loads every
person after a rollback. `human set <entityId> organization|groups|policy <value>` writes there (`unset` clears;
`@<path>` reads a policy file). `participants --json` carries each participant's `kind`, `address`, `organization`,
`groups`, `default` and `policy` (a list of `{ source, text }`, organization first), plus `default`, `organizations`,
`groups`, `warnings` and `participantFile`. `default` with no argument prints the current default and its source
(`chosen` or `only-person`), or `null` with the reason. See `docs/reference/gateway-participants.md`.
-`human set <entityId> slack-subscription <value>` — sets the person's Slack subscription: `every-ask` (the default) posts every ask to them to Slack; `urgent-only` posts only asks created with `--alert`, and other asks wait on Steering and the TUI; `unset` removes the authored subscription so the default applies. `human show` prints the value with its origin, `authored` or `default` (`slack-subscription: every-ask (default)`); `--json` carries it as `record.slackSubscription``{ value, source }`.
### parked
@@ -339,6 +354,23 @@ the sections that were not read are `null`.
credentials, and outbound network blocked except to localhost (see below). A test that reads
your real home directory, a running daemon, the network or a credential can pass on your
machine and fail in CI.
- **Mixed fixture clocks.**`compaction-command-submission.test.ts` uses one clock for the
enforcer, the transport's injected `now` and sleeps, and its `Date.now` idle deadline. Previously,
real-time transport waits could exhaust the fixture's 20 ms budget during a scheduler pause
even though the modeled seat was idle. Restore the `Date.now` spy after each test; keep real
deadline behavior covered by the transport tests. This changes the fixture, not production timeouts.
- **Docs location.**`check-docs-guard` fails if a tracked file under `docs/` sits outside
`docs/as-built/`, `docs/reference/` or `docs/releases/`. `docs/DESIGN.md` is the one allowed
exception.
@@ -104,7 +109,17 @@ credentials are supplied.
| `typecheck` | ubuntu | `npm run lint` |
| `repo-checks` | ubuntu | `npm run test:repo` |
| `package-tests` | macOS, matrix `daemon`, `cli`, `tui`, `ui` (fail-fast off) | Installs tmux, runs `npm ci` and `npm run build`. Then runs `npm run test -w packages/<pkg>` under `env -i` with a scratch `HOME`/`TMPDIR`/`TMUX_TMPDIR` and a `sandbox-exec` profile that blocks outbound network except localhost and the job's own socket directory. `scripts/ci-macos-process-probe.mjs` runs first. |
| `installed-scenario` | ubuntu | `bash scripts/run-pr-scenarios.sh` (eight container runs, described below). Uploads `dist/pr-scenarios/` as `installed-scenario-evidence`, including on failure. |
| `linux-seat-environment` | ubuntu | Builds all packages, then runs `seat-env-parent-session.integration.test.ts` with real CLI, daemon, tmux and stub seats. A network namespace has loopback only; tests run as the unprivileged runner user under `env -i` with scratch `HOME`/`TMPDIR`/`TMUX_TMPDIR`. Runs on pull requests and manual dispatch, like `package-tests`. |
| `installed-scenario` | ubuntu | `bash scripts/run-pr-scenarios.sh` (fifteen container runs, described below). Uploads `dist/pr-scenarios/` as `installed-scenario-evidence`, including on failure. |
The Linux seat-environment job covers a gap in the macOS matrix: the integration test
reads `/proc/<pid>/environ`, so macOS skips it. It checks both a new tmux server and an
existing server carrying a parent's session identity. It verifies the scoped environment,
the runtime directory and disabled session-bus default, and tmux's terminal identity in
the launched panes; the existing owner session stays unchanged. This adds one focused
Linux job to the existing suite. Stub seats prove the environment passed to the pane;
native Claude image paste and Shift+Enter handling still need separate verification
(see [#2041](https://github.com/mvschwarz/openrig/issues/2041)).
A second workflow, `.github/workflows/portability-report.yml` (job `portability-report`),
lists lines your PR adds that contain machine-specific values: credentials, home or temp
@@ -143,8 +158,8 @@ Exit codes: 0 pass, 1 a leg failed, 2 lane busy, 3 the runner itself errored.
| Piece | Where |
|---|---|
| `runtime: stub` adapter | `packages/daemon/src/adapters/stub-runtime-adapter.ts`, with `stub-runner.ts` (the process that runs in the pane), `stub-script.ts` (the launch-script format) and `stub-compaction.ts` / `stub-restore.ts` |
| Scenario format and runner | `packages/daemon/test/helpers/scenario-*.ts`. Step verbs: `up`, `down`, `send`, `restart`, `daemon`, `seed_regression` are bound. `restore`,`emit`,`mutate`, `policy`parse but are unbound. Assertion surfaces: `ps`, `queue`, `stream`, `scope`, `pane`, `transcript`, `tui_socket`, `policy_provenance`. |
| Scenario format and runner | `packages/daemon/test/helpers/scenario-*.ts`. Step verbs: `up`, `down`, `send`, `restart`, `daemon`, `seed_regression` are bound. `restore`, `mutate`, `policy` are rejected at load time (`UNBOUND_STEP_VERB`) because the runner has no shipped binding for them; `emit` parses but only `refocus` is bound. Assertion surfaces: `ps`, `queue`, `stream`, `scope`, `pane`, `transcript`, `tui_socket`, `policy_provenance`. |
refocus-active|refocus-parked-off|prompt-state` (default: all nine), `--mode
healthy|lost-baton|seeded` (default: healthy, lost-baton, healthy) and `--out <dir>` (default
`dist/pr-scenarios`). `--mode` applies to the baton cases (`fixture` and `library`) and to
the `refocus-parked` effect case; the six passing-only cases (`transcript`, `capture`,
`daemon-restart`, `refocus-active`, `refocus-parked-off`, `prompt-state`) always run once
each, healthy. `--mode lost-baton` leaves them out of a full run, and
`--case transcript|capture --mode lost-baton` is refused with exit 2. Use a fresh `--out`
directory for each run you want to keep.
- `--remote` accepts only `ssh://` values for `DOCKER_HOST`, and it refuses if
@@ -258,7 +278,7 @@ means:
| Queue pickup and wake | No stub worker reacts to a nudge by claiming an item, working on it and handing it back. | The baton scenarios prove the claim *survives a restart*. They don't prove delivery, pickup or wake. |
| Reboot / tmux reset | `daemon: {op: restart}` restarts only the scenario daemon, and the tmux server keeps running. No step resets tmux. | Recycled pane IDs and stale bindings after a real reboot (the class behind #141) are not covered by a daemon restart. |
| Multi-rig and same-name identities | The `up` step always uses the scenario's top-level `topology` and ignores a per-step override. No step archives or removes a rig. | Cross-rig scope, same-name generations and archive/remove routing (the class behind #174) need runner work before they can be tested. |
| Step-time restore, compaction, mutation, policy | `restore`,`emit`,`mutate` and `policy`parse, but the runner throws `UnboundActionError` when it reaches them. Behaviours run only from a per-seat launch script (`env.stub_scripts`). A seat `restart` step maps to `rig launch`, which is not native resume or fork. | Step-time compaction and restore, and native resume and fork, are not covered. |
| Step-time restore, compaction, mutation, policy | `restore`, `mutate` and `policy`steps are refused at load time (`UNBOUND_STEP_VERB`); `emit` parses but a non-`refocus` behavior throws `UnboundActionError` when the runner reaches it. Behaviours run only from a per-seat launch script (`env.stub_scripts`). A seat `restart` step maps to `rig launch`, which is not native resume or fork. | Step-time compaction and restore, and native resume and fork, are not covered. |
| Skill projection | The stub projects skills into `<cwd>/.openrig/stub/skills/`. Claude Code projects a team seat's skills into the seat's generated plugin in OpenRig's state, and into `<cwd>/.claude/skills/` only for a seat without one. | A stub green says nothing about provider-specific projection (the class behind #159). |
| Model and provider | No model, no tokens. Stub scripts refuse `usage_limit` because it only exists on real runtimes. | Model behaviour, provider usage limits and real context usage need live evals or a real runtime. |
| Platform | CI's scenario job runs in a Linux container. | macOS process behaviour is covered by the macOS `package-tests` jobs, not by scenarios. |
@@ -279,13 +299,17 @@ The most useful next pieces of harness work, roughly in dependency order:
### Library status
Four scenarios run in CI: `queue-baton-survives-restart` (since #243) with its seeded pair,
and `transcript-reads-addressed-seat`, `capture-returns-addressed-seat` and
`daemon-restart-preserves-team-identity` in passing form only. Three more,
`down-stops-every-seat`, `send-renders-in-addressed-pane` and
`up-relaunch-restores-a-two-seat-team`, run with the local runner but not in CI. Those six later scenarios are not in this table; see "Status
today" under [Help wanted](#help-wanted-command-families-without-a-behavioural-scenario). The
other ten scenarios are authored but not yet runnable as meaningful checks:
Seven library scenarios run in CI: `queue-baton-survives-restart` (since #243) and
`refocus-parked-baton` with their seeded pairs, and `transcript-reads-addressed-seat`,
of them. The other nine scenarios are authored but not yet runnable as meaningful checks:
| Scenario | Why it doesn't run as a check yet | Smallest useful next step |
|---|---|---|
@@ -294,11 +318,10 @@ other ten scenarios are authored but not yet runnable as meaningful checks:
| `ps-scope-honesty` | The second `up` reuses the first topology, and the expected match tolerates the other rig | Make `up` honour the per-step topology, then assert the exclusion |
| `send-verify-means-rendered` | The `send` step drops `verify`, and the stub has no input loop | Build the input-consuming stub and assert a response derived from the nonce |
| `home-divergence-preseed-visible` | The pipeline ignores `env.pre_existing_tmux`, and the default script never prints the expected `trust reached` | Recreate the real HOME split and whatever consumes it |
| `compaction-restore-resumes-role` | Step-time `emit` is unbound | Input-triggered hooks plus evidence specific to one seat |
| `stream-emit-durable-replay-live` | Step-time `emit` is unbound | Assert the actual stream contract |
| `policy-posture-survives-structural-edit` | `policy` and `mutate` are unbound | Rewrite around current per-seat permission selection and an observed launch |
| `locked-restore-never-permissive` | `policy` and `restore`are unbound | Keep the invariant (the selection survives a restore) and use current modes |
| `one-view-state-after-mutation-storm` | The validator rejects its bare-list `equals` (`EQUALS_NOT_DECLARATIVE`), and `mutate` is unbound | Declare the comparable fields and real mutations |
| `policy-posture-survives-structural-edit` | The validator refuses its `policy` and `mutate` steps at load time (`UNBOUND_STEP_VERB` — no shipped runner binding) | Rewrite around current per-seat permission selection and an observed launch |
| `locked-restore-never-permissive` | The validator refuses its`policy` and `restore`steps at load time (`UNBOUND_STEP_VERB` — no shipped runner binding) | Keep the invariant (the selection survives a restore) and use current modes |
| `one-view-state-after-mutation-storm` | The validator rejects its bare-list `equals` (`EQUALS_NOT_DECLARATIVE`) and refuses its `mutate` steps at load time (`UNBOUND_STEP_VERB`) | Declare the comparable fields and real mutations |
| `kill-daemon-mid-handoff` | A pane `send` doesn't create the queue item the next assertion expects, and later assertions use a shape the queue reader doesn't return | Rebuild the setup before treating a red result as meaningful |
In most of these files, `seed_regression` steps that come *after* the assertions are
@@ -441,8 +464,12 @@ that loses the team's row, or changes its seat counts or status, fails on the po
`rig down` then records it stopped, so the restart left a governable team. It does not prove
that queue items survive the restart (that is `queue-baton-survives-restart.yaml`), that a
kill inside a handoff window is reconciled (that is `kill-daemon-mid-handoff.yaml`), the
port-and-process half of the row, or that the panes are gone after `down`. Everything else
has none.
port-and-process half of the row, or that the panes are gone after `down`.
`compaction-restore-resumes-role` covers the compaction round-trip's success path: the
seat's launch script (delivered through `env.stub_scripts`) fires the real precompact and
restore seams in order, and impl's own pane carries the injected directive. It runs with
the local runner, not in CI (container mode refuses `env.stub_scripts` loud and named), and
its seeded wrong-seat-restore negative case is not armed yet.
Before you start, two honest constraints:
@@ -565,9 +592,6 @@ How to make a case useful:
Read these with care. This page notes them and proposes no changes.
- `packages/test-system/ci/README.md` describes the CI scenario job, except its
"Run one case" section, which still says both cases and six runs; the script runs four cases
and eight containers by default.
- The headers of `transcript-reads-addressed-seat.yaml` and `capture-returns-addressed-seat.yaml`
say "host mode only". Both run in the CI container job, which executes the host-mode pipeline
@@ -244,6 +244,15 @@ interactive"), and the post-launch files aren't sent. A Codex fork that the rig
`session_source.mode: fork`, or an agent image's fork) is the exception: its timeout ends as `attention_required`,
with its startup context kept for `rig seat continue` (see below). A seat handover's fork has its own readiness check.
**Fresh Claude handovers.** `rig handover --source fresh` keeps the previous agent's scrollback. Before sending the
handover context, OpenRig waits for the latest prompt inside Claude's complete input frame, and confirms that the
process in the pane belongs to the new launch. A shell's `❯` prompt or echoed launch command is not enough, even
with an old Claude header or input frame above it and Claude already running. A header alone or a partially drawn
input frame also keeps the check pending. If the current screen or process cannot be read, or the process identity is unconfirmed, the handover keeps
waiting within the readiness window and fails if that window expires. Old screen text or the `claude` process label
alone cannot complete this check. A healthy agent can therefore remain unconfirmed while those observations are
unavailable; inspect its pane before deciding how to recover.
**Claude submission check.** For each startup message to a Claude seat, OpenRig makes a bounded check that the prompt
was submitted. When the capture can't tell, it records the submission as unverified and carries on. When it sees the
same prompt still sitting in the input, it presses Enter once more; if it's still there, it warns "Startup prompt still
@@ -355,10 +364,37 @@ declaration isn't changed either; update it separately if a future recreation sh
Each startup file and action specifies when it applies:
- `fresh_start` — delivered when a new conversation starts: the first launch, `rig seat launch --fresh`,
`rig seat continue`, and seats restored with `--fresh`
- `restore` — delivered when a seat is restored, including a restore whose resume falls back to a fresh conversation
- `restore` — delivered when a seat is restored without its earlier conversation: a restore whose resume falls back to a fresh conversation, or a retried start
- Default: `[fresh_start, restore]` (both)
Use this to avoid re-sending context that the agent already has from its resumed conversation. For example, a one-time project briefing might only apply on `fresh_start`, while identity grounding should apply on both.
**An exact resume delivers neither.** When a restore reopens the seat's saved conversation (`rig up <rig> --existing` with a resume token), OpenRig types no startup actions and delivers no startup files, `restore` ones included: the conversation already has them, and typing them again would add turns to it. The one exception: a managed guidance block missing from the guidance file is put back before the harness starts.
Use this to avoid re-sending context that a fresh conversation doesn't need twice. For example, a one-time project briefing might only apply on `fresh_start`, while identity grounding should apply on both, so a seat that comes back fresh gets it again.
---
## What a seat is set to, and what it's running
A seat's settings can disagree with its running agent: what's saved for the next launch, what the running process
actually uses, and what its conversation has already read are three separate things. OpenRig reports each one
separately. Without live evidence it says unknown (or not verified), never the saved value. A saved change reaches the
running seat only through the action in the last column.
| What | Saved for the next launch | What the running seat has | How the running seat gets it |
|---|---|---|---|
| Model | `rig seat set-model` | `rig ps --nodes` shows the configured model beside the last observed one, or `UNKNOWN (<reason>)` | The next managed resume or successor launch |
| Reasoning effort | `rig seat set-effort` | `rig seat effort <seat>`: requested, saved, sent at launch, and what the session recorded, which is not verified until it takes a turn | Its next managed continuation; nothing restarts |
| Permissions | `rig seat set-permissions` (`--mode`, `--rules`, or for Codex `--codex-permissions` or `--codex-profile`), shown by `rig seat status` | What it launched with; a status read doesn't prove the running process enforces the selection | Its next managed launch or resume ([per-seat permission mode](getting-started.md#per-seat-permission-mode)) |
| Working directory | `rig seat set-cwd`, shown by `rig seat status` as **Working directory for future launches** | The directory it started in | `rig seat launch --fresh --stop` (a blank conversation) or `rig handover --source rebuild` (durable context); [details](#change-an-existing-seats-working-directory) |
| Startup files and skills | The spec's startup files, skills and actions | What its conversation read when it started; editing a file afterwards doesn't reach it | A fresh launch or a handover delivers them again; for the running seat, send or walk the change (`rig walk <seat> --through <files>`) |
| Tools (MCP servers, plugins) | Selected fragments, merged into the harness's own config (`.mcp.json` for Claude, `config.toml` for Codex) | Unknown to OpenRig: registered isn't active, Claude asks before it uses a new server, and no OpenRig command reports which tools a running harness loaded | Check in the harness itself (Claude Code's `/mcp`); a running session may need a restart to pick up newly written config ([runtime config disclosure](#runtime-config-disclosure)) |
Per harness: Claude Code's and Codex's permission choices are in the setup reference
- resume not declared until reopening a named session, and a missing one, have been checked with a real OpenClaw
- runs locally in the pane (openclaw chat), with no Gateway; Gateway-attached use isn't covered
- runs locally in the pane (openclaw tui --local), using only agent main, with no Gateway; Gateway-attached use isn't covered
- Finish the current local turn before stopping; an interrupted local turn may retain native recovery work and refuse the next request. This launcher does not repair or retry it.
- local resume may run a native database integrity check; check that the TUI has finished startup before sending work
- automatic session resets (session.reset) must stay off, or a key can start a new conversation
- typing /new in the pane moves the chat to a fresh session key; the seat still holds the name OpenRig gave it
- noguidance, skills or startup files are placed
- needs-input and approval prompts are read from the screen only
# Install as $OPENRIG_HOME/community-harnesses/pi-tui.yaml, with openrig-pi-tui-launch on the seat's PATH.
# "pi" itself is the built-in managed Pi runtime, so this preset for Pi's own terminal UI takes another name.
format:1
name:pi-tui
command:openrig-pi-tui-launch # no model or provider here: they go in the seat's Pi settings or environment
maintainer:Your name or team
limits:
- checked once with Pi 1.4.0 and OpenRig 0.7.4 (one run, one model); other Pi versions aren't checked
- resume not declared until reopening a named session, and a missing one, have been checked with a real Pi
- with the default typing guard, a wake submits a person's half-typed draft in Pi's editor together with the wake; run the seat unattended, not where a person also types
- a send while a Pi dialog OpenRig doesn't recognize is open, such as /settings, types into the dialog
- how Pi takes a wake that arrives while it's busy isn't shown
- only the listed openrig-core skills are copied into the seat's Pi agent folder; no guidance or startup files are placed
@@ -4,6 +4,33 @@ A community harness is a coding harness an outside contributor maintains. You in
rig member runs it by naming it as its `runtime`. OpenRig doesn't test these harnesses. It shows them as community
harnesses, and it reads their activity only from what the screen shows.
## What a community harness gets
What OpenRig does for a community-harness seat, capability by capability. **Partly** and **no** mean OpenRig shows that it doesn't know;
it never reads an unsupported capability as idle, working, ready or verified.
| Capability | Supported | How it works, or what you see instead |
|---|---|---|
| Launch | yes | OpenRig types the preset's `command` into the seat's pane, with its variables passed through `/usr/bin/env`. The seat reads as ready once something other than a shell runs in the pane; that's a process check, not proof of which conversation it runs. With `startup_assisted`, the seat reports attention required until a person checks it. |
| Delivery | yes | `rig send` and queue wakes paste the text into the pane and press Enter, as for any seat. A pane that's back at a shell is refused (`target_runtime_unverified`) and nothing is typed. OpenRig doesn't confirm the harness took the message; `rig send --verify` checks the pane afterwards. |
| Identity | when declared | With `launch_result`, the conversation is shown as reported by its launcher; with `names_conversation`, as named by OpenRig. Neither is observed by OpenRig. Without either, the identity is unavailable. |
| Resume | when declared | `resume: true` with one of the two above (see [Reopening a conversation](#reopening-a-conversation-resume-true)). Without it, a resume says `Resume is unsupported: community harness "<name>" is launch-only`, and a restore stops and asks. |
| Activity | partly | Read from the screen only; there are no activity hooks. Work and attention the screen shows are kept, but a screen that looks idle reads `unknown`, never idle, because a quiet prompt can be an approval or a pause. |
| Attention | partly | Read from the screen: a permission question or numbered choice that OpenRig recognizes reads as needing attention, and `rig send` won't type into it. A prompt it doesn't recognize reads `unknown`. |
| Approval | no | Approvals stay in the harness's own pane. OpenRig relays none, so a person answers them there. |
| Cancel | no | OpenRig has no verb that cancels a running turn. `rig seat stop` and `rig down` end the seat's tmux session; anything the harness runs outside its pane, such as a gateway, is its own, and the preset's `limits` should say what keeps running. Restarting in place and switching harness are refused. |
| Transport | yes | The seat is a tmux pane like any other, so `rig capture`, `rig send` and `--host` work as they do for any seat. |
**Not placed:** guidance, skills and startup files (a launch warns that they weren't delivered), and the model: set it in the harness's own
configuration.
**Check that the harness answers on its own first.** Before writing a preset, start the harness in a terminal outside OpenRig, with the
same configuration and credentials your launcher will give it, and send it one prompt. Use the folder your launcher gives the seat, not
the harness's default one: the example launchers keep one per seat under `$OPENRIG_HOME/state/<harness>/` (`HERMES_HOME`,
`OPENCLAW_STATE_DIR` or `CURSOR_CONFIG_DIR`), so a check with your own defaults can pass while the seat's setup fails. If no answer comes
back, the problem is in the harness's own setup, such as its model, provider or login, and relaunching an OpenRig seat won't fix it. Fix
it in the harness, then connect it.
## The preset
One YAML file per harness: `$OPENRIG_HOME/community-harnesses/<name>.yaml`. `rig community-harness list` shows what's
@@ -20,6 +47,7 @@ launch_result: true # optional: the launcher reports the conversatio
# names_conversation: true # optional, instead of launch_result: OpenRig names the conversation (below)
resume: true # optional, needs one of those two; declare it only once your harness's resume is checked
Set `startup_assisted: true` when the harness doesn't reliably submit OpenRig's startup text. OpenRig still pastes the
text and presses Enter once. If it sends startup text, the running seat then shows **attention required**, rather than
ready: check its pane and submit any text still in the composer. Don't resend the identity prompt. After the seat responds,
use the reported `rig seat clear-attention <session> --reason "Startup submission checked; seat responded"` command to
acknowledge the check. A launch with no startup text needs no such check. Other presets keep their existing behavior.
Set `startup_assisted: true` when startup submission needs a person's check. The seat may start its first turn
automatically, including from input passed at launch with `first_input: true`. This declaration requires a check after
the submission attempt; it does not hold the agent back. Without `first_input`, OpenRig pastes the startup text and
presses Enter once.
After attempting startup input, OpenRig reports **attention required**: check the pane and submit any text still in the
composer. OpenRig does not resend the identity prompt. Once the seat responds, use the reported
`rig seat clear-attention <session> --reason "Startup submission checked; seat responded"` command to acknowledge the
check. A launch with no startup text needs no such check. Other presets keep their existing behavior.
## Reporting the conversation a launch created (`launch_result: true`)
@@ -123,7 +155,9 @@ Agent's CLI.
flags and then reopens it, refusing any creation flag (model, provider, `--max-turns`) that differs. So the preset's
command carries none, and each seat's `config.yaml`, in its Hermes home, sets them before the seat's first start:
the model and provider, and `agent.max_turns` if you want a cap (nothing else sets it once the flag is gone).
- **Let Hermes run `rig` as the seat:** Hermes runs every tool command in one gateway per machine, with that gateway's
- **Let Hermes run `rig` as the seat:** Hermes runs every tool command in its gateway, one per Hermes home, so with
this launcher one per seat (a two-seat run showed separate gateways, homes and sockets, and stopping one seat left
the other's running). It runs them with that gateway's
environment, and swaps in a session's own values only for its toolchain names and the names its profile lists in
`terminal.client_env_passthrough`. So put the seat's OpenRig variables in that list, in each seat's `config.yaml`
([`config.yaml.example`](community-harness-examples/hermes/config.yaml.example)). Without it, `rig` inside Hermes
@@ -134,7 +168,8 @@ Agent's CLI.
- **The preset:** it declares `names_conversation` but not `resume`, until reopening a named session, and a missing one,
have been checked with a real Hermes.
- **Stopping:** Hermes's CLI is a client of a gateway, so closing a seat's pane detaches it. Hermes finishes any turn it
accepted, and the seat's gateway exits once idle. The preset says so in its limits.
accepted. Whether the seat's gateway then exits once idle hasn't been checked: check with `ps` that a stopped seat's
gateway has gone before relying on it. The preset says so in its limits.
Copy them and maintain them as your own.
@@ -142,17 +177,21 @@ Copy them and maintain them as your own.
[`community-harness-examples/openclaw/`](community-harness-examples/openclaw/) has a preset and a small launcher for
OpenClaw's CLI.
- **The launcher:** it runs `openclaw chat` (the TUI with `--local`) on the session key OpenRig named, with its own
OpenClaw state folder per seat, so the agent runs in the seat's pane with no Gateway.
- **Its resume check:**before reopening a key, the launcher checks that the seat's `openclaw sessions --json` lists it,
and stops if not, so a gone conversation isn't recreated under its old key. That check is the launcher's code, not
OpenRig's.
- **Resets must stay off:** OpenClaw can start a new conversation under the same key on a reset rule
(`session.reset`). That's off by default; with it on, a key no longer names one conversation. Likewise, typing `/new`
in the pane moves the chat to a fresh session key, while the seat still holds the name OpenRig gave it.
- **The preset:**it declares`names_conversation` but not`resume`, until both have been checked with a real OpenClaw.
- **Choose the mode:**`openclaw.yaml` runs an embedded agent with `tui --local`. `openclaw-gateway.yaml` runs a TUI client of an existing Gateway. Configure that client's Gateway route and authentication through `OPENCLAW_CONFIG_PATH`; the launcher never starts or stops the Gateway.
- **The conversation:** both examples use only agent `main`, mapping OpenRig's name to the full native key `agent:main:<OpenRig name>`. Each seat has its own client state folder.
- **Its resume check:**local mode checks `sessions --agent main --json --limit all`; Gateway mode calls the selected Gateway's `sessions.describe`. Both require the exact canonical key. An unavailable lookup stops the launch; a confirmed missing key is never recreated. A client's local cache cannot authorize Gateway resume.
- **Stopping:** a Gateway client's pane closing detaches it. The Gateway and an accepted turn can keep running; stopping that service is separate. Local mode runs its embedded agent in the pane.
- **Unattended seats:** prefer Gateway mode within the capabilities qualified for your installed version. Local interrupted-turn recovery is not supported by these launchers.
- **Local interruption:** Finish the current local turn before stopping; an interrupted local turn may retain native recovery work and refuse the next request. This launcher does not repair or retry it. OpenRig recognizes the recorded local “changed while starting work” error frame as needing attention: “OpenClaw turn not recovered; inspect the pane before retrying”. Use `rig capture <session>` to inspect the native conversation. An ordinary send still submits a new turn, with an advisory that the last local turn was not recovered; it is not an automatic replay of that turn. It does not clear native recovery records, repeat the request or start a fresh conversation; a successful process launch is not proof that the turn recovered.
- **Local startup after resume:** OpenClaw may run its database integrity check during startup. A reported resumed process does not confirm readiness for the next request; check that the TUI has finished starting before sending work.
- **Resets must stay off:** automatic session resets can create a new conversation under the same key. Typing `/new` also moves to a fresh key while the seat keeps the name OpenRig gave it.
- **The presets:**both declare `names_conversation`,`resume` and `first_input`. The launcher passes the generated first startup text through OpenClaw's `--message` option. OpenRig labels the saved name as passed, not observed by its adapter.
Copy both and maintain them as your own.
Copy the launcher and the preset for your mode, and maintain them as your own.
**Stopping a community seat stops its pane.** `rig down` names those seats ("Pane stopped: …"), since a harness's own
processes, a gateway say, may keep running after it. OpenRig doesn't stop them, and whether they survive isn't exercised
by OpenRig's tests, so check the harness's own processes after `rig down`. Each preset's limits say what to expect.
**Not supported for community harnesses:** restarting a seat in place (`rig seat restart` is for Codex seats) and
switching harness on a running seat. Each says so before anything changes.
@@ -167,13 +206,146 @@ CLI.
- **The preset:** it declares `launch_result` and `resume`. Cursor's `--resume` with an id it doesn't hold starts a new,
empty chat without saying so, so on a resume the launcher first checks that the chat's store exists. When it doesn't, the
launcher reports `error: "missing"` and starts nothing.
- **Startup is assisted:** identity text has remained in Cursor's composer after the initial Enter. The preset declares
`startup_assisted: true`; check and submit it in the pane as above. Unattended startup submission is not confirmed.
- **First input at launch:** the preset declares `first_input: true` and `startup_assisted: false`. The launcher passes
the generated startup text as Cursor's positional first prompt. This route and same-chat resume were checked with
Cursor Agent 2026.10.22-27dcf5f. Later tool approvals use Cursor's native prompts; startup submission does not answer them.
- **Sender names come from the sending session.** A command run from an unattached operator shell can arrive as
`<unknown sender>`; that doesn't mean the receiving Cursor seat lost its identity.
Copy both and maintain them as your own.
## An example: Pi's terminal UI
[`community-harness-examples/pi-tui/`](community-harness-examples/pi-tui/) has a preset and a small launcher that run Pi's
own terminal UI as a community harness. `pi` is the built-in managed Pi runtime, so the preset is named `pi-tui`. OpenRig
delivers to this seat as to any community seat (the Delivery row above), not as to a plain `runtime: terminal` seat, which
queue wakes don't reach. Checked once, on Pi 1.4.0 with OpenRig 0.7.4 and one model: a parked row's wake reached Pi in
the same session (the same session file) and Pi resumed the work, and a handoff reached a second `pi-tui` seat, which
picked it up unattended. The first seat's task named the commands to use, so this shows a wake reaching Pi and Pi acting
on it, not Pi choosing by itself to park or hand work on.
- **The launcher:** each seat gets its own Pi agent folder (`$OPENRIG_HOME/state/pi-tui/<node>/agent`, unless
`PI_CODING_AGENT_DIR` is set) and its own session folder. At each launch it copies the installed `openrig-core` skills
it's given (`queue-handoff` by default) into that agent folder. A new launch starts `pi --session-id <the name OpenRig
gave>` and passes the first input as Pi's first prompt, byte for byte.
- **Resume isn't declared.** The launcher can reopen a named session: it opens the one session file whose header has that
id, and starts nothing when there isn't exactly one, because Pi's own `--session-id` creates a session for an id it
doesn't find. Declare `resume: true` only after a real Pi has reopened a named session and refused a missing one.
- **Its limits:** run a `pi-tui` seat unattended, not where a person also types into it.
- With the seat's [typing guard](seat-delivery.md) at its default, a wake submits a person's half-typed draft in Pi's
editor together with the wake. The guard's draft-aware mode isn't a known fix for this.
- A send while a Pi dialog OpenRig doesn't recognize is open, such as `/settings`, types into the dialog.
- Not shown: how Pi takes a wake that arrives while it's busy (a message sent during a busy turn was answered after
it), and other Pi versions.
- **Give the seat a model** before its first start: its provider key in its environment, or its login and settings in its
agent folder.
Copy both and maintain them as your own.
The launcher is the contributor's code, in the contributor's package. OpenRig runs no code from a preset and loads no
module into its daemon. A preset that sets `launch_result`, `names_conversation` or`startup_assisted` is refused by an older
module into its daemon. A preset that sets `launch_result`, `names_conversation`,`startup_assisted` or `first_input` is refused by an older
OpenRig that doesn't know the field.
## Pass the first startup input at launch
A format-1 preset may set `first_input: true` (a boolean, default false). OpenRig composes the same initial identity turn it would otherwise paste, including the first merged text file, durable-obligation guidance and any selected orientation challenge. Before launch it writes that text to a per-attempt 0600 file under its own `state/first-input/` folder and passes the path as `OPENRIG_FIRST_INPUT`. The typed launch command carries the path, not the text; an argument-based launcher still puts the text in the native harness’s argv.
The contributor-owned launcher reads the file and uses its harness’s supported initial-prompt route: the Cursor example passes one positional prompt; OpenClaw uses `--message`. Core knows neither flag. If no initial identity turn is due (an ordinary resume, for example), the variable is absent and the launcher starts without a first message. Later startup files and actions use their existing delivery paths; they are not folded into the launch file.
OpenRig records `node.startup_first_input_passed` with the path and `submission: unconfirmed`. This says the input was passed at launch, not that the native harness submitted or read it. An uncertain launch is not permission to replay it. Readiness remains process-only. `startup_assisted` is independent: when declared, startup still requires a person’s acknowledgement, including when the first input was passed at launch.
Presets without `first_input` and built-in runtimes keep their existing behavior. Older OpenRig versions reject this new field as unknown. The private input file remains for diagnostics; it can contain private startup context. A launcher that turns its contents into one argument is subject to the platform’s argument-size limit; the launcher must report a launch error rather than silently truncate the turn. The examples’ argument transport is covered with stand-ins; native unattended startup still requires qualification with the installed harness.
## Interactive Pi in a terminal seat: the coordination skills
This is for a seat that runs interactive `pi` from a `runtime: terminal` member's startup, or from a community preset's
launcher. It isn't for a managed `runtime: pi` seat, which already copies its selected skill directories into the seat's own
Pi agent directory (`$OPENRIG_HOME/state/pi/<session>/agent/skills/`), or for Workshop, whose Pi profiles carry pinned skill
copies (openrig-world's `PI-SKILLS.md`). The [`pi-tui` example](#an-example-pis-terminal-ui) above does step 1 for its
seats in its launcher.
OpenRig installs no skills for a terminal or community seat: it skips their resources and startup files, and `rig skill
loadout` covers Claude Code and Codex only. Without the coordination skills, the agent there doesn't know the queue's habits,
such as parking a row that waits on CI instead of leaving it in progress, or handing work on so the next row names its
source. The seat's setup does two things.
1. **Make the released skills readable.** The installed OpenRig's own plugin carries them, matching the installed release:
`rig plugin list` shows `openrig-core` and its path (usually `$OPENRIG_HOME/plugins/openrig-core`), and the skills are in
its `skills/` folder. Copy whole skill directories, keeping their helper files and modes, into the `skills/` folder of the
Pi agent directory that seat uses (`PI_CODING_AGENT_DIR`, or `~/.pi/agent` by default). At least `queue-handoff`:
```bash
CORE="$(rig plugin list | awk '$1 == "openrig-core" {print $NF}')"
Last validated against code: 2026-10-07, at the 0.6.6 cut `2620dea8` (whole document at `fcaf1f8e`; its sources unchanged in edge behaviour since then)
Source of truth: `packages/daemon/src/domain/rigspec-schema.ts`, `packages/daemon/src/domain/rigspec-instantiator.ts`, `packages/daemon/src/domain/queue-owner.ts`
Historical whole-document validation: 2026-10-07, at the 0.6.6 cut `2620dea8` (whole document at `fcaf1f8e`).
The fallback escalation section and deferred-target exceptions below describe #605.
Source of truth: `packages/daemon/src/domain/rigspec-schema.ts`, `packages/daemon/src/domain/rigspec-instantiator.ts`, `packages/daemon/src/domain/queue-owner.ts`, `packages/daemon/src/domain/escalation-owner.ts`
---
@@ -16,8 +17,7 @@ See `docs/reference/rig-spec.md` for the YAML syntax.
## Edge Kinds
Five edge kinds are accepted by the pod-aware validator (the legacy flat-node format accepts only `delegates_to`,
`spawned_by` and `can_observe`):
Five edge kinds are accepted by both the pod-aware and legacy flat-node validators:
Only `delegates_to` and `spawned_by` affect runtime behavior. They constrain the order in which nodes are launched:
Only `delegates_to` and `spawned_by` constrain the order in which nodes are launched:
- **`delegates_to`**: source launches BEFORE target. The delegator must be up before the delegate.
- **`spawned_by`**: target (parent) launches BEFORE source (child). The parent must be up before the child it spawned.
@@ -46,13 +46,42 @@ All other edge kinds (`can_observe`, `collaborates_with`, `escalates_to`) do NOT
wake ladder escalates an unacknowledged row to that orchestrator, and stuck-row findings and recovery go to it. A seat
with no incoming `delegates_to` edge has no default orchestrator. `spawned_by` plays no part here.
### Fallback escalation across rigs
A seat with **no declared `delegates_to` parent** may declare one `escalates_to` destination. The wake ladder and
stuck sweep use it for new recovery rows; they do not move the original obligation or reassign an already-open recovery. A stopped or unbound declared
parent still takes precedence, preserving the existing parent route and its fallback.
```yaml
edges:
- kind: escalates_to
from: work.lead
to: review-advisor@coord
```
The target is a canonical same-daemon seat address (`pod-member@rig`), or an existing local member using the usual
edge syntax. Named targets are stored without requiring the other rig to exist and resolved when needed. A matching
physical session name takes precedence over a derived canonical address. Deferred declarations survive export and
snapshots; they don't constrain launch order or make the rigs depend on each other's lifecycle.
Delivery is one hop. Recovery rows carry `escalation-route:one-hop`, so a destination's own `escalates_to` declaration
does not forward the recovery again. A missing or stopped destination, multiple matches or declarations, self route,
or declared cycle preserves the existing fallback: the wake ladder proceeds to its operator rung; the sweep retains
its existing owner fallback. The recovery body/transition explains the result. Cycle inspection includes stopped
seats and delegation parents; an unresolved downstream endpoint is reported as unknown, never as proof of no cycle.
Queue address admission is unchanged. Cross-host and synthetic destinations are not supported.
On an existing rig, use `rig edge add <rig> work.lead review-advisor@coord --kind escalates_to`; `--plan` writes nothing.
The receipt's target node ID is null for a deferred address. Remove it with the exact edge ID returned by add.
A rig-local graph omits deferred targets, since those seats are outside that graph; the raw topology and export retain them.
### Graph visualization
All edges are rendered in the UI topology graph. They create visual connections between nodes, helping the operator understand the team structure. Pod-local edges appear within the pod group; cross-pod edges connect across groups.
Local-node edges are rendered in the UI topology graph; deferred cross-rig targets are omitted. They create visual connections between nodes, helping the operator understand the team structure. Pod-local edges appear within the pod group; cross-pod edges connect across groups.
### Identity projection
All edges appear in `rig whoami --json` output under `edges.outgoing` and `edges.incoming`, with their kind and the connected peer's identity. This lets an agent know its relationship to other members — but the agent interprets this information, it's not enforced by the runtime.
Local-node edges appear in `rig whoami --json` output under `edges.outgoing` and `edges.incoming`, with their kind and the connected peer's identity. This lets an agent know its relationship to other members — but the agent interprets this information, it's not enforced by the runtime.
### Attach hint heuristic
@@ -64,7 +93,7 @@ node, in creation order, whose session is running, or else the first node with a
Edges do NOT currently:
- **Route messages** — `rig send` can target any session, regardless of edges (queue escalation, above, is the one
daemon path that follows `delegates_to`)
daemon path that follows `delegates_to` or fallback `escalates_to`)
- **Enforce delegation** — an agent can communicate with any peer, not just its edge targets
- **Control permissions** — there's no edge-based access control
- **Affect transport** — `rig capture`, `rig broadcast`, etc. work based on session identity, not edge topology
@@ -128,7 +157,7 @@ If none fit, `can_observe` is the safest default — it documents the relationsh
## Validation Rules
1. Edge kinds must be one of: `delegates_to`, `spawned_by`, `can_observe`, `collaborates_with`, `escalates_to`
2. Pod-local edges use unqualified member IDs — both `from` and `to` must exist in the same pod
3. Cross-pod edges use `pod.member` format — both endpoints must resolve to actual members
2. Pod-local edges use unqualified member IDs — both endpoints must exist in the same pod, except a named `escalates_to` target as above.
3. Cross-pod edges use `pod.member` format — both endpoints must resolve to actual members, except a named `escalates_to` target as above.
4. Cross-pod edges must reference different pods (same-pod edges should use the pod-local syntax)
5. Self-edges are not validated at the schema level but are not meaningful
The dry run shows the target's settings and where each comes from (an explicit
option, the seat's agent spec for the target runtime, or the runtime's own
default), what is cleared, and the costs below. Nothing changes until you run it
without `--dry-run`.
The new runtime takes over before the old one stops. Its successor starts beside
the current occupant, reads a handover (the seat's recap, its open rows and the
predecessor's screen), and confirms it with `rig seat set-runtime <seat>
--confirm <switch-id> --note "<what it will do first>"`. Only then does the seat
move: same address, connections and queue rows, with in-progress claims moved
to the successor. If the successor doesn't confirm within 180 seconds
(`--confirm-timeout`), nothing changes and the current occupant keeps the seat.
A seat can switch itself. `rig seat status <seat>` shows an open or interrupted
switch, and `rig seat set-runtime <seat> --recover` finishes one from its record.
What it costs:
- **A new conversation.** Native history isn't converted; only the handover
carries over.
- **The same address, a different terminal.** The seat's pane and scrollback
change.
- **The team file isn't rewritten.** The database and `rig export` show the new
runtime; the YAML you imported keeps the old one, so a later converge against
it reports a deferred `change_runtime`. Export the rig, or edit the member's
`runtime:`, to keep them in step.
- **Source settings are cleared, not mapped.** The model, effort, Codex profile
and an explicit native permission choice don't carry over, and neither does a
model or effort the agent spec declares for the source runtime. Member and rig
permission policy are kept.
- **Two processes until cutover.** The successor runs on the target's account
while the switch is open.
- **Messages are held during the switch.** A `rig send` to the seat while it
switches isn't typed; it says the seat is switching and until when. Send it
again afterwards to reach whoever holds the seat.
- **Leftover files after a failed switch.** The target runtime's prepared seat
storage and projections can remain.
- **Codex and Claude Code, single-pane seats.** Startup slash commands aren't
run by a switch; the dry run lists them.
## Stop your teams
`rig down <rig-name>` ends that rig's agent sessions and work in progress.
@@ -774,14 +851,16 @@ the lifecycle API without booting a new kernel, then stop the remaining rigs.
| Shared terminal is absent | Inspect the existing kernel binding and recovery state; use standalone `rig tui` while resolving it. |
| Viewing terminal was closed | Open the conversations again with `rig terminal open saved:kernel --window`; `rig tui --shared` is only the dashboard fallback if that window cannot open. Do not relaunch the team. |
| Daemon restarted but tmux survived | Re-read `rig status` and the existing queue; a daemon restart is not a fresh project. |
| Host reboot lost tmux sessions | Starting the daemon restores the kernel by itself when all of its seats were lost; check `rig status`, and if it reports the restore failed, run `rig up kernel --existing`. For other rigs, open `rig`, start the daemon if needed (press **S** if it opens on the work views), and select the existing rig and seats. Resume is the default; a fresh conversation needs a separate decision. |
| Host reboot lost tmux sessions | Starting the daemon restores the kernel by itself when that start finds all of its seats lost; a kernel that was already down before the reboot stays down, and `rig start` names `rig up kernel --existing`. Check `rig status`, and if it reports the restore failed, run `rig up kernel --existing`. For other rigs, open `rig`, start the daemon if needed (press **S** if it opens on the work views), and select the existing rig and seats. Resume is the default; a fresh conversation needs a separate decision. |
| Launch reports no usable snapshot | Inspect the existing rig and retained project files, then follow the same-seat recovery below. |
| Work is waiting on a prompt or decision | Read the row, transition and named prompt; preserve the obligation until the missing decision arrives. |
**When the kernel's seats all fail at the first start.** A report on Oracle Linux 10
([#980](https://github.com/mvschwarz/openrig/issues/980)) traced this to the distribution's packaged tmux, whose
`tmux -V` prints `next-3.4`: its server exited on every `capture-pane -p`, also outside OpenRig. To check your tmux on
a throwaway socket, without touching your own sessions:
`tmux -V` prints `next-3.4`: its server exited on every `capture-pane -p`, also outside OpenRig. `rig setup` (its tmux
step) and `rig doctor` (`tmux_capture` in `rig doctor --json`) run this check for you on a throwaway server and name the
fix when capture fails; they test what tmux does, not its version. To run it by hand, without touching your own
# Hosted members: a tool outside the terminal on your team
A hosted member is a tool that lives outside a terminal, such as an assistant, a chat bot or a cloud routine, and works as a member of a rig. You
address work to it like any seat. It reaches the team through OpenRig's MCP server under a grant you issue and can revoke. It never gets a pane.
Assistants that run on your machine can reach OpenRig's MCP server locally. Many assistants live in a vendor's cloud, and those can only reach a server on the internet.
> **Experimental and unsupported. Off by default.** Nothing in OpenRig listens on the internet unless you set it up yourself. You serve `rig mcp serve --http`, put it behind your own TLS tunnel or proxy, and issue a token. Doing that is like opening a port in your firewall. Anyone with the URL and a valid token can act as that member within its grant. Treat the token like a password, give the member the narrowest grant, and revoke it when you're done (`rig mcp token revoke <name>`). We don't support, and take no responsibility for, an OpenRig reachable from the internet, just as with running OpenRig itself on the open internet. Use at your own risk.
## Set one up
1. **Pick its address** on an existing rig: `<member>@<rig>`, for example `grok@research`. No node is added; the queue takes rows for it.
2. **Say what it's good at, and its limits,** in a roster: an entry in `<workspace.root>/rosters/<file>.json` with its seat, this machine's host id
(`hostSelfId` from `rig ps --nodes -A --json`), `capabilities`, `use_when`, `why`, a `caveat` for its limits, and `"hosted": true` (see
[Rosters](rosters.md)).
3. **Issue its grant:**
```sh
rig mcp token add grok --seat grok@research --rig research
```
It prints the token once. The member acts as `grok@research`: every row it creates or changes is attributed to that seat, and it reaches only
that rig's seats and work.
4. **Serve the MCP server over HTTP** behind a tunnel or proxy that adds TLS: `rig mcp serve --http`. See `rig mcp serve --help` for binding and
for how authentication works. If the proxy runs browser checks (such as Cloudflare's Browser Integrity Check), skip them for `/mcp`:
MCP clients aren't browsers.
5. **Add the server in the tool:** its `https://…/mcp` URL and the token as a bearer credential.
## How it works its rows
- **Hand it work** as you would any seat: `rig queue create --destination grok@research …`.
- **The member works it** through the MCP tools:
- `rig_queue_list` with `owned` lists its rows;
- `rig_queue_claim` takes one;
- `rig_queue_update` closes it done with the answer in `resolution`, or `rig_queue_handoff` hands it on to a seat in its rig.
- **It can send work too:**`rig_queue_create` to its rig's seats.
- **Its rows outlive the conversation.** A new conversation with the same grant reaches the same work.
- **`rig_whoami`** answers the seat its grant names, though the member has no session.
## Asking a person while keeping the work
When a row needs a person's approval before the member can finish it, the member keeps the row and asks:
- **The row came from a person:** the member sets it `blocked` with `blockedOn` that person, and puts the question, with a short form of
what it will do, in the row's `summary`. The person is asked with the summary and the row; a transition note stays in the row's history
and isn't part of the ask. A longer draft goes at an https link in `evidenceRef`, which the ask carries. The person's answer returns the
row to the member in progress.
- **The row came from a seat, or from a shared channel:** the member asks as a new row, to that seat, or for a channel's row to its rig's
lead (a shared channel takes correspondence and can't answer an ask). Then it sets its own row `blocked` on the new row's id. When the
question closes, the member's row returns to pending.
- **Keep the question and action summary short.** A long row body continues as numbered thread replies, within the existing delivery
limits. Use an https `evidenceRef` for a longer approval draft. The summary and framing can still be too large, so nothing promises
unlimited delivery.
Either way the row reads blocked, not done, while it waits, and the member finishes that same row. Nothing promises to wake the
member, so it checks its rows again.
The server tells the member this in its MCP instructions. The text is versioned, so you can check which version a tool received:
> Member workflow (member-workflow/v2). Your inbox is the items addressed to your seat: rig_queue_list with owned set. It's yours, not the team's queue. A wake, a ring or a message only points at it: list your inbox, then act. For each item: claim it (rig_queue_claim), do it, then close it done with closure reason no-follow-on and the answer in resolution (rig_queue_update), or hand it on (rig_queue_handoff). Listing or reading an item doesn't take it. Say what you can reach from your grant, not from the tool list: a listed tool isn't access. rig_artifact_read's answer for an item names the shared roots you may read, and none means no shared files. If the person connected you, that's basically authorized: claim the items in your inbox and do them without asking whether you may. When an item needs a person's approval before you can finish it, don't close it and don't take the action: keep the item and ask. If it came from a person (an address ending in @external that isn't a shared channel; the item's 'Shared channel:' line names one), set it blocked with blockedOn that person and, as its summary, the question with a short form of what you'll do: the person sees the summary and the item, not your note, which keeps the record. Link a longer draft as an https evidenceRef. Their answer returns the item to you in progress. Otherwise ask as a new item, to the seat it came from or, for a shared channel's item, to your rig's lead (rig_team shows it), with your question and draft. Then set yours blocked with blockedOn that new qitemId: when that item closes, yours returns to pending, to claim again. Nothing promises to wake you, so check your inbox again. Then finish the same item; don't open a new one.
## Ring it when work lands
If the tool has a trigger that starts it from outside, such as a webhook on a scheduled routine, add it to the member's roster
entry. The entry holds secret names, never values:
- It's a pointer, not the row's body: the member reads the row under its grant.
- A receiver should tolerate a repeated `qitem_id`. A ring accepted just before the daemon stops, before it's recorded,
is rung again on recovery, the same at-least-once window a terminal wake has.
- It waits up to 10 seconds and doesn't follow redirects.
- **What the trigger should do:** start a run that lists the member's rows (`rig_queue_list` with `owned`) and claims its work.
## What the record says, and doesn't
These facts stay separate on the row:
- **Wake:** with a trigger, the row's wake result is `wake-accepted:webhook (<url_ref>) answered <status>` when the trigger took the
ring, or `failed:webhook …`. Accepted means the tool's trigger answered, not that the member read the row.
- With no trigger, the result is `unroutable`, and OpenRig tells the person: the operator seat when it's a person, else whoever
created the row.
- It tells the person too when the member was rung but hasn't claimed the work by the stuck sweep's unclaimed age
(`queue.stuck_sweep_unclaimed_age_minutes`, 60 by default).
- The member sees new work when it checks: when it's rung, when its person asks it to, or on a schedule the tool runs.
- **Pickup:** its claim, a transition by its seat. Listing or reading a row isn't pickup.
- **Result:** the closing transition and its resolution, or the handoff.
- **Notification:** where a person asked, Slack's posted receipt. A posted notice isn't the person's acknowledgment.
**On the team:** `rig_team` lists the rig's hosted members (roster entries marked hosted that aren't one of its nodes), with their capabilities and caveat, no pane, and activity `unknown`.
OpenRig doesn't observe a hosted member between its calls, so it never reads idle. `rig roster find` shows it the same way.
- **Presence:** each entry carries `presence`, which says what OpenRig last saw of the member. It isn't pickup, and `null` means unknown:
- `lastCallAt`: its last authenticated call to this host's `rig mcp serve --http`, recorded at most once a minute in
`<OPENRIG_HOME>/mcp-http-presence.json`, beside the token file;
- `lastWake`: its latest ring and the result, among its 50 most recent rows.
- `rig roster show` and `find` show the last call; the last ring is in `rig_team`.
## Revoke
`rig mcp token revoke grok` refuses its next request. The rows it worked, and their answers, stay.
## Limits today
- **Webhook triggers only:** OpenRig rings a webhook. Email and other triggers aren't supported yet. A member without a trigger
isn't rung, and its person is told instead.
- **It can't act as a person:** it works rows addressed to its seat, a person's request to it included. It can't settle an ask addressed to a person, or hand work to one.
@@ -165,6 +165,27 @@ says so. Use it rather than the single-machine `rig provider status --json`: one
machines appears once, with each machine's own observation beside it, so you can't count it twice. If it answers that
usage windows are off, tell the person that before setting the watch, as you would an unreachable channel.
For a Claude login supplied by `CLAUDE_CODE_OAUTH_TOKEN`, an explicit one-credential read is available:
```sh
rig provider status --refresh --provider claude --claude-token-file /absolute/private/personal.token --credential-label Personal
```
The file must be readable by the daemon, regular, at most 8 KiB, and contain only the token. Ownership by the daemon user and mode 0600 or
0400 are recommended; different ownership, broader permissions and symlinks produce warnings, not refusals. Provision it through your existing credential
custody; never put token values in arguments, seat environment settings, evidence or a queue item. The path is on the selected daemon's
machine. Repeat the command for another labelled file when you want to compare subscriptions. This option does not fan out with
`--all-hosts` or `--hosts`.
**Each token refresh spends one model turn.** Status and TUI reads show the cached result and never probe. A timeout or refusal does not
prove no allowance was spent. The probe uses a temporary home/config/work directory and a single Haiku turn, with CLI flags requesting no tools, hooks or MCP. Unsupported CLI flags or missing events are reported as failures/unknown, not as free capacity. The event format is evidenced on
Claude Code 2.1.310; other versions may report different fields. These are credential labels you supplied, not provider-verified account
names, and do not prove a running seat uses that credential. The ordinary status-line sample/account join remains unproven.
Only actually reported window percentages and resets are measurements. A rejected window can have an unknown percentage; overage rejection
is separate from subscription rejection. Readings and their times survive daemon restart, marked historical until refreshed. Files with
different references/labels stay separate; equal resets or matching labels on another host never establish one allowance or extra room.
**Never put `--refresh` in the timer's check.** `rig provider status --all-hosts --refresh` starts a native read of the
accounts on every machine. Run it only when the person asks for a fresh reading now.
@@ -37,10 +37,12 @@ launched before this change, a manual run) the hooks do what they always did. Th
the seat's own `settings.local.json` copy only when that entry is exactly OpenRig's and the script it names is the same
script; an entry from an older install doesn't match, so both report until the seat's next launch refreshes it.
OpenRig automatically installs its Codex plugin for seats that select it. On its first installation, the six exact shipped
hook definitions are trusted before launch, after checking the installed hook files against this daemon's shipped copy.
Existing plugin disables and hook choices are retained. An existing untrusted installation stays under native review:
Codex's "continue without trusting" leaves no record, so OpenRig does not assume an absent trust record is permission.
The file check happens only when trust is granted: a later edit to the cached hook scripts keeps that trust, as with any hook trusted in Codex.
hook definitions and bundle content are trusted before launch, after checking the entire installed plugin against this daemon's shipped copy.
On upgrade, OpenRig renews content approval only for a previously approved OpenRig-owned bundle with unchanged approved hook definitions.
It keeps explicit disables, refusals, unknown config layers and other plugins' state. An installation without a proven prior approval stays under native review.
Codex's "continue without trusting" leaves no record: a skip of an otherwise eligible OpenRig-owned update may therefore be superseded on retry.
OpenRig records its approved bundle in `CODEX_HOME/.openrig-core-hook-trust.json` and leaves Codex's immutable `.hook-trust` baseline untouched.
Codex 0.164 checks bundle contents when hooks run; a later edit requires native approval again. Older Codex versions enforce their own trust rules.
The Codex
column above then applies only to a Codex seat whose plugin selection includes openrig-core: every Codex hook command
exits 0 before running anything unless OpenRig gave that seat `OPENRIG_SEAT_PROJECT_DIR` and an explicit
**Launching one spec under another name.** `rig up <spec> --name <rig>` creates the rig as `<rig>` instead of the spec's `name:`, so one spec can run as several rigs at once, for example `--name alpha` and `--name beta`, with seats `{pod}-{member}@alpha` and `{pod}-{member}@beta`. The spec file is not changed. The rig keeps the chosen name from then on: `rig ps`, `rig down alpha`, `rig up alpha --existing`, snapshots and restore all use it. The same checks as a launch without `--name` apply to the chosen name: a running rig of that name refuses the launch, and a stopped one is archived and replaced, as an explicit spec import does today. `--name` does not rename an existing rig, so the CLI refuses it with the name of an existing rig to restore, with a topology and with a GitHub bundle link. A library spec name works: `rig up starter --name beta` launches the library spec as `beta` even while a rig named `starter` exists. Over `--host`, pass the spec path or bundle file with `--name`. A spec that sets `services.project_name` refuses `--name`: every rig launched from it would share that Compose project, and `rig down` or a failed service boot of one would stop the others' services. Without `project_name`, each rig gets its own project. Two launches of the same spec started at the same moment can answer 409 (already in progress for this source) even under different names; start them one after the other.
### Starting one materialized seat
`rig import ./team.yaml --materialize-only` records the team without starting its harnesses.
For a seat that has never started, use its positional logical ID:
```bash
rig launch <rig-id> dev.lead --json
```
This starts only that seat, preserving the rig's node IDs and the other seats. The daemon retains
the materialized declaration and resolves its agent and startup files from the original source
root at launch time; keep those files available. Current saved model, effort and permission
choices take precedence over the retained declaration; launch reports the differences. A prior snapshot isn't required. Seats with
session history continue through restore. Explicit `--snapshot-id` and `--seats` use restore too.
`--plan` previews restore selection; it requires a snapshot and does not preflight this first start.
Rigs materialized by older daemons lack the retained declaration; this path doesn't retrofit them.
### Attaching a permission policy
Attach a policy to a rig with `permission_policy`, either at the rig level or on a member:
@@ -219,6 +236,131 @@ future managed launches of that stable seat; it does not rewrite this spec or
its inherited policy provenance. `inherit` removes that override. See
Choose one of `--mode`, `--rules`, `--codex-permissions` or `--codex-profile` per call. A seat
keeps one explicit permission choice: setting an envelope replaces a recorded mode, and setting
a mode (including `inherit`) clears the envelope, in the same audited write that names both.
A runtime switch keeps the envelope while the seat runs Claude Code and applies it again when
`rig seat set-runtime` brings the seat back to Codex. A switch back to Codex with an explicit
`--permission-mode` replaces the envelope when the switch commits, and the switch's plan and
event name it. A switch that doesn't commit leaves it in place.
A profile name is separate from the envelope and from approval: a resumed conversation keeps
its saved approval unless an envelope sets one. `--codex-profile inherit` clears the profile.
The profile command checks the profile in the config home this seat's launches use: the seat's
own `CODEX_HOME` when its `env:` declares one, else the daemon's explicit `CODEX_HOME`. There it
reports an absent file (Codex loads it as an empty layer, so base config applies), records the
file's hash so a later check can report a change, and refuses a profile that fails to load,
keeping the previous one. When neither sets a `CODEX_HOME`, a seat's pane keeps its own, and the
command reports the profile as unverified rather than checking a different home. Every launch
still runs the native profile check.
Updates leave the running process and history unchanged; they apply at the next separately
authorized managed launch or resume. Restore reads the seat's current record, so an older
snapshot doesn't bring back a replaced profile. A fork copies the source's current profile and
envelope independently. Export contains the current record. A new generation from `rig up
<spec>` starts from the spec. An invalid or unreadable envelope refuses that seat's launch, fork
or export with a repair message rather than launching broader. Without the field or a recorded
update, launch arguments are unchanged.
**Downgrade:** an older OpenRig keeps the stored envelope but doesn't read it, so its launches
of the seat use the earlier posture decision, which can be broader. This is not
restriction-preserving. Keep a copy of the intended envelope and establish equivalent native
restrictions before using an older managed-launch path. Native enforcement must be checked on
the Codex version and configuration being used.
### Team launch defaults
A non-kernel Claude or Codex seat with no authored permission policy, explicit
@@ -356,16 +498,33 @@ pods:
- A seat gets the rig's `env` with its own `env` laid over it, name by name.
- The same environment is applied on first launch, on `rig up <rig-name>` restore, and to the successor of a seat handover.
- `rig up <spec> --env KEY=VALUE` (repeatable) adds or overrides a value for one launch. A one-off value belongs to the terminal that launch creates: it stays in that terminal's environment for as long as the terminal lives, and OpenRig removes it from the tmux session's environment as soon as the terminal has started, so a terminal started later in that session does not get it. If OpenRig can't take it out, the seat keeps running and the launch warns, naming the variable and the tmux command to put it back or remove it. Until then, a terminal started later in that session would get it. A restore, a handover successor or any later launch starts from the spec's `env:` alone, so the value is not saved and does not carry forward. To keep a value, put it in `env:`. One exception to "does not carry forward", for a managed Claude seat (see below): a one-off name that the seat's spec does not declare stays on the session's list of names, `OPENRIG_SEAT_ENV_KEYS` (names only, no values), because the first launch and an in-place restart of the same terminal read that list. So if a later pane in that session gets a value for that name from the tmux server's own environment, its managed Claude launch can forward that value, where a launch without `--env` would leave it out. The first launch's one-off value itself is not passed on to that pane. This comes from reading the code and has not been measured. `--env` does not apply to `rig up <rig-name>` (a restore) or to a topology (several rigs from their own specs); the CLI refuses both. For a topology, put `env:` in each rig's spec.
- `rig up <spec> --env KEY=VALUE` (repeatable) adds or overrides a value for one launch, except `CLAUDE_CONFIG_DIR` and `CODEX_HOME`, which the CLI leaves out with a note (see "A seat's own account" below). A one-off value belongs to the terminal that launch creates: it stays in that terminal's environment for as long as the terminal lives, and OpenRig removes it from the tmux session's environment as soon as the terminal has started, so a terminal started later in that session does not get it. If OpenRig can't take it out, the seat keeps running and the launch warns, naming the variable and the tmux command to put it back or remove it. Until then, a terminal started later in that session would get it. A restore, a handover successor or any later launch starts from the spec's `env:` alone, so the value is not saved and does not carry forward. To keep a value, put it in `env:`. One exception to "does not carry forward", for a managed Claude seat (see below): a one-off name that the seat's spec does not declare stays on the session's list of names, `OPENRIG_SEAT_ENV_KEYS` (names only, no values), because the first launch and an in-place restart of the same terminal read that list. So if a later pane in that session gets a value for that name from the tmux server's own environment, its managed Claude launch can forward that value, where a launch without `--env` would leave it out. The first launch's one-off value itself is not passed on to that pane. This comes from reading the code and has not been measured. `--env` does not apply to `rig up <rig-name>` (a restore) or to a topology (several rigs from their own specs); the CLI refuses both. For a topology, put `env:` in each rig's spec.
- **The runtime directory, on Linux.** When the daemon runs with an absolute `XDG_RUNTIME_DIR` (usually `/run/user/<uid>`), a seat gets the same `XDG_RUNTIME_DIR`, so a tool that keeps its socket there, such as an MCP server's daemon or `gpg-agent`, works inside the seat without per-tool setup. It comes with `DBUS_SESSION_BUS_ADDRESS=disabled:`, an address that D-Bus clients refuse. sd-bus, GDBus and libdbus look for your session bus at `$XDG_RUNTIME_DIR/bus`, or start one, only when that variable is unset, so a seat doesn't find your session bus (the keyring, notifications) on its own. This is a default, not isolation: `systemctl --user` reaches your service manager through its own socket in the runtime directory, as any tool there can.
- A seat's own value wins. Set `DBUS_SESSION_BUS_ADDRESS` in `env:` to give a seat a bus. Set `XDG_RUNTIME_DIR` there to choose the directory yourself; the seat then gets no bus address, as before, so its D-Bus clients find the bus in that directory. A name listed in tmux's `update-environment` counts as the seat's own too.
- A shell startup file that runs in the seat's terminal can still change either name. One that sets only `XDG_RUNTIME_DIR` now leaves the seat with `disabled:`, where before its clients found your bus; set the bus address in `env:` or in that file to keep it.
- With `terminal.inherit_tmux_environment` on, a seat gets tmux's environment as before, and OpenRig adds neither name. On macOS, and for a daemon started without `XDG_RUNTIME_DIR`, nothing changes.
- Codex passes only a fixed list of variables to the MCP servers it starts, so a Codex seat's MCP server gets the runtime directory only when its entry in `config.toml` names it: `env_vars = ["XDG_RUNTIME_DIR"]`. Codex's hooks and shell commands get it without that, and so do Claude Code's MCP servers and hooks. Pi and OMP agent processes don't get it (see below).
- It applies at a seat's next launch, restore or handover; a seat that is up keeps the environment it started with.
- Names starting `OPENRIG_` are reserved for OpenRig and refused. Empty values are refused, because the launch omits empty variables.
- `rig export` writes the rig and member `env:` back out.
**Where the declared names reach, by runtime.** Declared values are handed to the seat's terminal as tmux environment, so most seats take them as given:
- Plain Claude Code (no permission mode selected), Codex and terminal seats take a spec `HOME`, `PATH` or `CLAUDE_CONFIG_DIR` as given.
- The cleared environment (`env -i`) belongs only to a managed Claude launch, which is the one used when a permission mode is selected for the seat (for example `permission_policy: builtin:auto`). It forwards the declared names through the cleared environment, except `PATH`, `HOME` and `CLAUDE_CONFIG_DIR`, which OpenRig sets for that launch itself, and `CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN`, for which it sets its own renderer setting. A spec value for any of those four is not forwarded. A seat that selected the shipped `openrig-core` plugin also has `CLAUDE_CODE_PLUGIN_DIRS` (the vendored plugin, added after a list the seat declares itself) among its declared names, so it is forwarded like the others and the plugin's hooks load in a seat with a permission mode as in one without; a seat that didn't select the plugin has no such name added. Beyond the declared names, the launch also forwards, by name and only when the seat's terminal has them set, the terminal and locale variables (`TERM`, `COLORTERM`, `TERM_PROGRAM`, `TERM_PROGRAM_VERSION`, `LANG` and the `LC_*` names) and the person's editor and display session: `EDITOR`, `VISUAL`, `DISPLAY`, `XAUTHORITY` and `WAYLAND_DISPLAY`. They let Claude's external-editor action open the person's editor and let image paste reach the clipboard, without a value in a spec. `WAYLAND_DISPLAY` is passed as an absolute path: an absolute value is kept, and a relative one is joined to the terminal's `XDG_RUNTIME_DIR`; if the terminal has no `XDG_RUNTIME_DIR` for it, the name is left out. `XDG_RUNTIME_DIR` itself is not forwarded, because D-Bus clients look for the session bus at `$XDG_RUNTIME_DIR/bus` and would reach the keyring and `systemctl --user`. `DBUS_SESSION_BUS_ADDRESS`,`XDG_SESSION_TYPE`,`XDG_CURRENT_DESKTOP` and `SSH_AUTH_SOCK` are not forwarded either. A running seat picks the names up at its next managed Claude launch, not before: `rig seat launch <seat> --fresh --stop --reason "<why>"` for that seat alone (a new conversation), or a restore of the whole rig (`rig down <rig>`, then `rig up <rig> --existing`, which resumes each conversation but restarts every seat in the rig), or a handover. A seat that is up keeps the environment it started with.
- Codex seats run OpenRig's own Codex executable whatever a spec `PATH` says, and use the daemon's`CODEX_HOME` when the daemon has one.
- On Pi and OMP seats the values reach the terminal. The agent process gets only what the runner passes on, so a spec or one-off value reaches it only for the names the runner always passes: `PATH`, `HOME`, `USER`, `LOGNAME`, `TERM`, `LANG`, `LC_ALL`, `SHELL` and `TMPDIR`. Pi's agent process receives the runner's `HOME`, so a spec or one-off `HOME` value that reaches the runner is passed to Pi; OMP's agent process gets its seat state directory (`$OPENRIG_HOME/state/omp/<seat>`, see Oh My Pi below) as `HOME`, so a `HOME` value does not reach it. The selected provider's variables are passed separately, as described under each runtime.
- The cleared environment (`env -i`) belongs only to a managed Claude launch, which is the one used when a permission mode is selected for the seat (for example `permission_policy: builtin:auto`). It forwards the declared names through the cleared environment, except `PATH`, `HOME` and `CLAUDE_CONFIG_DIR`, which OpenRig sets for that launch itself, and `CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN`, for which it sets its own renderer setting. A spec value for any of those four is not forwarded as such; an absolute `CLAUDE_CONFIG_DIR` becomes the config dir OpenRig sets (see "A seat's own account" below). A seat that selected the shipped `openrig-core` plugin also has `CLAUDE_CODE_PLUGIN_DIRS` (the vendored plugin, added after a list the seat declares itself) among its declared names, so it is forwarded like the others and the plugin's hooks load in a seat with a permission mode as in one without; a seat that didn't select the plugin has no such name added. Beyond the declared names, the launch also forwards, by name and only when the seat's terminal has them set, the terminal and locale variables (`TERM`, `COLORTERM`, `TERM_PROGRAM`, `TERM_PROGRAM_VERSION`, `LANG` and the `LC_*` names) and the person's editor and display session: `EDITOR`, `VISUAL`, `DISPLAY`, `XAUTHORITY` and `WAYLAND_DISPLAY`. They let Claude's external-editor action open the person's editor and let image paste reach the clipboard, without a value in a spec. `WAYLAND_DISPLAY` is passed as an absolute path: an absolute value is kept, and a relative one is joined to the terminal's `XDG_RUNTIME_DIR`; if the terminal has no `XDG_RUNTIME_DIR` for it, the name is left out. The runtime directory and its `disabled:` bus address (see "The runtime directory, on Linux" above) are forwarded together, and the runtime directory is also forwarded beside a declared `DBUS_SESSION_BUS_ADDRESS`. A terminal's own `XDG_RUNTIME_DIR` or `DBUS_SESSION_BUS_ADDRESS`, from a shell startup file or tmux's `update-environment`, is not, because D-Bus clients look for the session bus at `$XDG_RUNTIME_DIR/bus` when no address is set; declare it in `env:` to forward it.`XDG_SESSION_TYPE` and`XDG_CURRENT_DESKTOP` are not forwarded. The SSH agent socket (`SSH_AUTH_SOCK`) is forwarded when OpenRig itself was started with one, so git over SSH works in the seat; a socket only the seat's terminal has stays out. To check, run `ssh-add -l` inside the seat. If it can't reach an SSH agent, start the OpenRig daemon from a terminal where `ssh-add -l` works. A running seat picks the names up at its next managed Claude launch, not before: `rig seat launch <seat> --fresh --stop --reason "<why>"` for that seat alone (a new conversation), or a restore of the whole rig (`rig down <rig>`, then `rig up <rig> --existing`, which resumes each conversation but restarts every seat in the rig), or a handover. A seat that is up keeps the environment it started with.
- Codex seats run OpenRig's own Codex executable whatever a spec `PATH` says. They use the seat's own`CODEX_HOME` when its `env:` declares an absolute one, else the daemon's when the daemon has one.
- On Pi and OMP seats the values reach the terminal. The agent process gets only what the runner passes on, so a spec or one-off value reaches it only for the names the runner always passes: `PATH`, `HOME`, `USER`, `LOGNAME`,`SSH_AUTH_SOCK`,`TERM`, `LANG`, `LC_ALL`, `SHELL` and `TMPDIR`. Pi's agent process receives the runner's `HOME`, so a spec or one-off `HOME` value that reaches the runner is passed to Pi; OMP's agent process gets its seat state directory (`$OPENRIG_HOME/state/omp/<seat>`, see Oh My Pi below) as `HOME`, so a `HOME` value does not reach it. The selected provider's variables are passed separately, as described under each runtime.
**A seat's own account.** Claude Code keeps its login in its config dir and Codex in its home, so a seat whose `env:`
declares an absolute `CLAUDE_CONFIG_DIR` (Claude Code) or `CODEX_HOME` (Codex) runs on whatever login that directory
holds. The member's value wins over the rig's. OpenRig follows it everywhere it launches or reads that runtime: the
launch, Claude's first-run trust settings, Codex's managed `config.toml`, hooks and plugin, conversation capture for
resume, context usage, `rig seat status` and `rig provider status`. A value that isn't an absolute path isn't used:
the seat resolves as if it declared none, and `rig seat status` shows the ignored value. Name the home in `env:`: a
one-off `rig up --env` value for either variable isn't applied, because a restore, a handover and `rig seat status` read
only the stored `env:`. Seats may share a home. Live usage refresh (`rig provider status --refresh`) still reads only the
daemon's own logins; reading each seat's home would need a native reader per home. OpenRig doesn't copy logins or conversation history between homes, so a conversation saved under a seat's earlier home
doesn't resume after the seat moves to another one. The `openrig-user` skill has the setup steps.
**Do not put secrets in `env:` or `--env`.** The values are not secret, and nothing here encrypts or hides them (see #306):
@@ -437,6 +596,7 @@ directory's `CLAUDE.md`, including blocks written by other rigs.
| `agent_ref` | string | yes | — | Reference to an AgentSpec. Must start with `local:` (relative) or `path:` (absolute). Exception: `builtin:terminal` for infrastructure nodes. |
| `profile` | string | yes | — | Profile name from the referenced AgentSpec. Use `default` for the default profile. Exception: `none` for terminal nodes. |
| `codex_config_profile` | string | no | — | Codex-only native profile passed as `-p <name>`; letters, numbers, `_`, `.`, `-`. Separate from the AgentSpec `profile`. With the normal launch mode, this replaces OpenRig's explicit workspace-write sandbox flag. A full-bypass policy instead emits danger-full-access and omits this profile argument. |
| `codex_permissions` | mapping | no | — | Codex-only sandbox and approval envelope, emitted as explicit flags on every managed launch and resume; see [per-member Codex permissions](#per-member-codex-permissions). |
| `runtime` | string | yes | — | Agent runtime. Current supported values: `claude-code`, `codex`, `pi`, `omp`, `terminal`, `stub`. `stub` is a deterministic test harness, not an agent: a Node runner in the seat's tmux pane goes through the normal launch, skill projection, startup-file and readiness path, follows `<cwd>/.openrig/stub/script.json` when present, and calls no model. See "What a stub can and cannot prove" in `docs/as-built/test-layers.md`. |
| `cwd` | string | yes | — | Working directory for the agent. A relative path resolves against the rig root (the directory containing the rig spec). If that path exists as written, it is used. Otherwise a leading `~` or `~/` expands to the home directory (`~user` does not) and `$VAR` / `${VAR}` expand from the daemon host's environment; a relative result still resolves against the rig root. A reference to an unset variable stays as written, so the cwd is that literal path and works only if it exists. Use `"."` for the rig root itself. Can be overridden at launch time with `rig up --cwd`. A cwd inside the OpenRig installation fails preflight unless `--cwd` is given. Editing this declaration does not update an existing seat; use [`rig seat set-cwd`](agent-startup-guide.md#change-an-existing-seats-working-directory) to save its future launch directory. |
| `label` | string | no | — | Human-readable member name. Shown in UI when present. |
@@ -493,7 +653,9 @@ own defaults/settings apply. Other runtimes ignore this field.
- **State:** Each seat uses `$OPENRIG_HOME/state/pi/<session>/agent` as its Pi agent directory, with `sessions/` beside it, instead of your default `~/.pi/agent`. The runner sets `PI_CODING_AGENT_DIR` to that directory. `<session>` is the seat's session name, unchanged; for a pod member it is `{podId}-{memberId}@{rigName}`. `$OPENRIG_HOME` defaults to `~/.openrig`. OpenRig creates these directories at launch and does not copy anything from `~/.pi/agent`.
- **Thinking level:** A Pi seat's effort (the choice saved with `rig seat set-effort`, else the spec's `effort`) is sent to Pi as `--thinking <level>` on every managed launch and resume: fresh launch, successor and restore. Pi accepts `off`, `minimal`, `low`, `medium`, `high`, `xhigh` and `max`; OpenRig passes the value as written and does not translate it, so Codex's `none` is not mapped to `off`. Only a value of the shape `set-effort` accepts (a letter, then up to 31 letters, digits, `-` or `_`) is sent; any other spec value, such as one with a space or one that starts with `--`, is left out, and `rig seat effort` says so. An unfamiliar level gets an advisory (a warning from `set-effort`), never a refusal, and Pi itself ignores an unknown level with a warning and keeps the level it would use without the flag: a model suffix, the resumed session's level, or its default. With no effort resolved, no flag is sent. The effort wins over a model suffix, and the model string is never changed. `rig seat effort` reports the level sent at launch and, on Pi 0.99.0 or later, the `thinkingLevel` Pi records on this launch's latest successful assistant turn (error and aborted turns are skipped); that is the session's level after Pi's own cap, not proof the provider applied it, and it is shown apart from the level sent when they differ. On older Pi it is NOT VERIFIED. Without an effort, you can still set the level as a model suffix, for example `model: openrouter/x-ai/grok-4:high`. Pi first looks for a model whose id is the whole pin, and uses it when there is one, suffix included. Only when there is none does Pi read the suffix as the level and record the model without it. Any other suffix, such as OpenRouter's `:free`, stays part of the model id. The model-divergence check reads the pin literally when the seat's `models.json` defines a model with that exact id; otherwise it accepts the model with or without the suffix. If the seat's `models.json` can't be read, a pin with a suffix stays unchecked, with the usual warning, when the recorded model matches the whole pin or the pin without its suffix. A record that matches neither is reported.
- **Custom models:** Pi reads `models.json` from its agent directory, so a seat reads `$OPENRIG_HOME/state/pi/<session>/agent/models.json`, not `~/.pi/agent/models.json`. Custom provider and model definitions for a seat go in that file. A seat that uses only providers Pi already includes does not need one. OpenRig does not create or write `models.json`.
- **Credentials:** The Pi process receives only `PATH`, `HOME`, `USER`, `LOGNAME`, `TERM`, `LANG`, `LC_ALL`, `SHELL`, `TMPDIR`, a fixed set of OpenRig seat and instance variables, `PI_CODING_AGENT_DIR`, `PI_CODING_AGENT_SESSION_DIR`, and at most one provider key. That key is `OPENROUTER_API_KEY`, `ZAI_API_KEY`, `KIMI_API_KEY` or `MINIMAX_API_KEY`, passed only when it is set in the seat's environment and the seat's `model` is written as `openrouter/<id>`, `zai/<id>`, `kimi-coding/<id>` or `minimax/<id>`. Naming that variable in `recovery.provider_auth_env_allowlist` (empty by default) makes the daemon add it, when set in the daemon's environment, to the seat's launch environment. No other variable reaches Pi, including other providers' keys and a custom provider's own key variable.
- **Credentials:** The Pi process receives only `PATH`, `HOME`, `USER`, `LOGNAME`,`SSH_AUTH_SOCK`,`TERM`, `LANG`, `LC_ALL`, `SHELL`, `TMPDIR`, a fixed set of OpenRig seat and instance variables, `PI_CODING_AGENT_DIR`, `PI_CODING_AGENT_SESSION_DIR`, and at most one provider key. That key is `OPENROUTER_API_KEY`, `ZAI_API_KEY`, `KIMI_API_KEY` or `MINIMAX_API_KEY`, passed only when it is set in the seat's environment and the seat's `model` is written as `openrouter/<id>`, `zai/<id>`, `kimi-coding/<id>` or `minimax/<id>`. Naming that variable in `recovery.provider_auth_env_allowlist` (empty by default) makes the daemon add it, when set in the daemon's environment, to the seat's launch environment. No other variable reaches Pi, including other providers' keys and a custom provider's own key variable.
- **Extension dialogs:** The RPC runner shows extension `select`, `confirm`, `input` and `editor` requests in the pane and cancels them because the managed pane cannot answer them. The seat needs attention through the end of the turn, until a new agent run starts. Review the cancelled request and send an instruction the extension can complete without a dialog. Extension `notify` text is shown without raising attention or sending a response.
### Oh My Pi (`runtime: omp`)
@@ -556,7 +718,11 @@ This is human-authored (you choose the pod/member IDs) and system-validated (the
| `spawned_by` | Source was spawned by target; the target launches first. Constrains launch order. | Child → parent in hierarchical topologies |
| `can_observe` | Source can observe target's output. Does NOT constrain launch order. | Reviewer → implementer, monitor → worker |
| `collaborates_with` | Peer collaboration relationship. Does NOT constrain launch order. | Co-equal peers working together |
| `escalates_to` | Source escalates to target for decisions. Does NOT constrain launch order. | Worker → lead for escalation |
| `escalates_to` | Fallback queue escalation for a seat without a declared delegation parent. Does NOT constrain launch order. | Local member or same-daemon `pod-member@rig` address |
A named `escalates_to` target may be in another rig on the same daemon and need not exist at import time.
See [fallback escalation across rigs](edge-types.md#fallback-escalation-across-rigs) for precedence, single-hop delivery,
cycle detection and visible fallback outcomes.
### Pod-Local Edges
@@ -639,6 +805,20 @@ the modified topology, run `rig snapshot <rig-id>` and use its returned ID with
Startup blocks can appear at three levels: rig, pod, and member. They are merged additively via the startup layering model (see [the layering model](agent-startup-guide.md#the-layering-model)). The rig's `culture_file` joins as a required file with the `auto` hint in the culture layer, on both fresh start and restore.
`rig export` includes the rig's saved culture file and startup block, and now also
writes each pod's saved startup files under that pod. The file order, delivery
hints, required flags, orientation and `applies_on` selections are retained.
Previously the saved pod file lists were omitted. Pods without a recorded file
list, including older rigs, keep their existing export behavior; the exporter
does not reconstruct declarations from a member's combined startup context.
File paths remain relative to the exported spec's folder. When exporting to a
different folder, supply the referenced startup files there or import with the
original `--rig-root`. The CLI warns once per missing required rig or pod file;
missing optional files do not trigger that warning. Pod startup actions and
member startup blocks remain outside this export; keep the source spec when you
need those declarations.
### Files
| Field | Type | Required | Default | Description |
@@ -647,7 +827,7 @@ Startup blocks can appear at three levels: rig, pod, and member. They are merged
| `orientation` | string | no | — | Set to `role` to identify a per-seat role file for `rig queue whoami --json` and refocus. Does not change delivery or replay startup. |
| `delivery_hint` | string | no | `auto` | How the file is delivered. One of: `auto`, `guidance_merge`, `skill_install`, `send_text`. |
| `required` | boolean | no | `true` | Whether startup fails if this file cannot be delivered. |
| `applies_on` | string[] | no | `[fresh_start, restore]` | When this file is delivered. Subset of: `fresh_start`, `restore`. |
| `applies_on` | string[] | no | `[fresh_start, restore]` | When this file is delivered. Subset of: `fresh_start`, `restore`. An exact resume of the saved conversation delivers none, apart from putting back a missing managed guidance block. |
#### Delivery Hints
@@ -665,8 +845,8 @@ Startup blocks can appear at three levels: rig, pod, and member. They are merged
| `type` | string | yes | — | Action type. One of: `slash_command`, `send_text`, `startup_proof`. Note: `shell` is explicitly NOT supported in v1. |
| `value` | string | yes | — | Command/text to send, or `authenticated` / `none` for `startup_proof`. |
| `phase` | string | no | `after_files` | When to execute text/commands. One of: `after_files` (after startup files are delivered), `after_ready` (after harness readiness check passes). Proof selection is resolved before projection regardless of phase. |
| `idempotent` | boolean | yes | — | Whether this action is safe to replay on restore. **Required field.** Non-idempotent actions must NOT include `restore` in `applies_on`. |
| `applies_on` | string[] | no | `[fresh_start, restore]` | When this action runs. Subset of: `fresh_start`, `restore`. |
| `idempotent` | boolean | yes | — | Whether this action is safe to run again on a restore without the earlier conversation or a retried start. **Required field.** Non-idempotent actions must NOT include `restore` in `applies_on`. |
| `applies_on` | string[] | no | `[fresh_start, restore]` | When this action runs. Subset of: `fresh_start`, `restore`. An exact resume of the saved conversation runs none (see the startup guide). |
The existing typing guard supports three modes. Before draft-aware mode,
automatic input either used the ordinary delivery path or was held unconditionally.
Draft-aware adds an opt-in check for unfinished input without a second control or
daemon-owned retry scheduler. Sibling seats keep their own mode.
The typing guard has six modes. `off` and `hold` are the two ends. Draft-aware adds an
opt-in check for unfinished input without a second control or daemon-owned retry
scheduler. Between off and hold, three interruption levels choose which automatic messages may
type: `openrig-urgent`, `urgent-only` and `sends-only`. Sibling seats keep their own mode.
| Mode | Terminal input | When input is unavailable |
|---|---|---|
| `off` (default) | Existing delivery and prompt checks | Existing send result |
| `draft-aware` | Paste into a recognized empty composer; check ownership again before Enter | Hold input and retain this attempt for inspection when bookkeeping is available |
| `openrig-urgent` | OpenRig's own messages (watchdogs, scheduled wakes, notices) and anything marked urgent type, never over a draft | Other agents' messages are held, the sender is told, and held messages stay readable |
| `urgent-only` | Only messages marked urgent type (`rig send --urgent`, or a queue item at priority urgent or critical), never over a draft | Everything else is held, the sender is told, and held messages stay readable |
| `sends-only` | Deliberate sends from people and agents type, as with `off`; a terminal member's typing isn't protected, because its shell input can't be read | OpenRig's own notices are held. A terminal member defaults to this level |
| `hold` | No automatic terminal input, even at an empty prompt | Retain for inspection outside the pane |
Lifecycle work is refused at `openrig-urgent` and `urgent-only`, as at `hold`.
A terminal member (`runtime: terminal`) defaults to `sends-only`, which holds OpenRig's own notices. Set one
to `off` and those notices, such as park reminders and other watchdog messages, type into whatever the pane
is running, and a shell prompt runs each line as a command, From and To lines included: OpenRig doesn't check
a terminal pane's foreground process. `openrig-urgent` and `draft-aware` type only into a recognized empty agent composer, so
a shell prompt holds them. Keep the default for a seat that may fall back to a shell.
Runtime permissions are separate. Recipient and interactive-prompt checks still
apply. `--raw` and `--force` do not bypass the typing guard. A deliberate
`--dangerously-interact --reason` remains available at every interruption level
and uses the existing-input check below. Direct human input remains available.
A message sent to a busy Codex seat joins its running turn and may redirect it.
Clients that present a specific seat can save its later-launch settings using its durable `nodeId`. The node ID is distinct from the current session and native conversation. These routes never launch, stop, or resume the seat.
The POST bodies and responses follow the corresponding name-addressed routes. A successful save's `seat.nodeId` and `seat.rigId` identify the node actually updated. The exact status response adds `node_id`, `contract: "seat-node.v1"`, and `supported_actions` listing the four setters. Existing name status responses retain their shape.
An unknown, deleted, or archived node returns `seat_not_found` (HTTP 404) at node resolution. After awaited validation of a native Claude permission mode or Codex profile returns, the exact node-ID path checks availability again before saving; an unavailable node then returns `seat_not_found` without a setting or audit write. Existing native validation may refuse a changed target before this check: for example, Claude's managed context guard can report `permission_selection_refused` during preparation. The daemon never resolves a node ID through a reusable seat name. Setting writes have no general session precondition; a changed occupant on the same available node can receive a later save.
For example, `POST /api/seat/set-model/node/<nodeId>` accepts the existing `{ "model": "...", "reason": "...", "operator": "..." }` body. The existing audit actor, reason, native validation, permission precedence, and terminal policy rules still apply. The older `/:seatRef` routes remain available, including their name ambiguity behavior.
- **Answers come back to where the person asked.** A person's new message is the root of its
answer: when the seat it reached replies with `--reply-to` that message's row, the answer and
later updates land in the person's thread, in the channel they used.
- **One conversation, whoever writes.** Messages routed to the same continuing agent
conversation can use that conversation's earlier context, whoever sent them. A queue row
records who sent a message and which seat owns it; it doesn't start a separate agent
conversation. If people need separate conversations, route them to separate seats
(`--inbound` names the seat a channel's new messages reach). Separate channels help only when
their routing also keeps the conversations separate: new messages in a seat's own channel
still go to the inbound destination unless its entry names `--inbound`. A conversation shared
on purpose is fine.
- Missed-message recovery (below) covers the default channel only.
Invite the app to every mapped channel (`/invite @OpenRig`). `rig slack verify` checks
@@ -190,7 +207,8 @@ app is in all of them. A saved change reaches a running connector when it next r
daemon restart does (`rig daemon stop`, then `rig daemon start`). `rig slack disable --reason
"<why>"` then `rig slack enable` rewires too, but alerts still waiting to be posted when it's
re-enabled are treated as already seen and aren't posted. Only an earlier post that failed or
didn't finish still posts: an alert whose row is still open, a decision-resolved notice, or a digest. The TUI's Connections page says whether the running
didn't finish still posts: an alert whose row is still open, a decision-resolved notice, or a digest. `rig slack post-open-asks`
then shows the asks still open. The TUI's Connections page says whether the running
configuration matches the file.
The map is stored as `channelMap` in `slack-connector.json`, as a list of `{ "match", "channel" }`
@@ -258,7 +276,7 @@ reaches a running connector when it next rewires, which a daemon restart does (`
then `rig daemon start`). `rig slack disable --reason "<why>"` then `rig slack enable` rewires too,
but alerts still waiting to be posted when it's re-enabled are treated as already seen and aren't
posted. Only an earlier post that failed or didn't finish still posts: an alert whose row is still
open, a decision-resolved notice, or a digest.
open, a decision-resolved notice, or a digest.`rig slack post-open-asks` then shows the asks still open.
## One app across machines (optional)
@@ -305,7 +323,7 @@ decisions, and posts its own replies.
removed. An enabled connector retries them; disabling it pauses retry without deleting them.
Let relays finish before removing a forward entry. A zero dead-letter backlog alone does not
prove they have drained: it does not count relay HTTP requests still in flight.
- **Who answered:** every post ends `from <seat> on <machine>`, using the machine's host id (set
- **Who answered:** every post starts `From <seat> on <machine>`, using the machine's host id (set
it with `host.name`).
- **The hub's own channels** are handled on the hub, as before. A channel can be relayed to one
machine only, and never the hub's own default channel.
console.log("note: Restored saved credential bytes only; sign-in is unverified. Saved credentials may expire, be revoked, or be superseded by refresh elsewhere. Restart the affected seat and use the existing account verification; fresh sign-in may be required.");
if(!match||width<1||height<1||width>1000||height>1000)return{error:`--size wants WIDTHxHEIGHT, each from 1 to 1000 (got ${JSON.stringify(opts.size)})`};
return{width,height};
}
/**
*Thelast`n`linesofacapture.Theblankrowsofthevisiblepanebelowitscontentaredroppedfirst: ona
?`its own window-size was given back, but ${readable.sizeBack}`
:readableRelease(readable.release);
console.error(`[rig capture: ${r["sessionName"]}: read at ${readable.width}x${readable.height}; ${after}]`);
}elseif(readable?.resized===false)console.error(`[rig capture: ${r["sessionName"]}: not resized for reading: ${readable.reason}]`);
};
// Multi-target result
@@ -127,6 +164,8 @@ export function captureCommand(depsOverride?: CaptureDeps): Command {
.option("--pod <name>","Capture all sessions in a pod")
.option("--lines <n>","Show the last N lines of the pane (without it: 20 history lines plus the whole visible pane)","20")
.option("--history-plus-pane","With --lines N, show N history lines plus the whole visible pane, as before --lines was exact")
.option("--readable","Read a seat whose pane is smaller than 120x40 at that size, then give its window back")
.option("--size <WxH>","With or without --readable: read at this size instead (for example 160x50)")
.option("--host <id>","Capture on a remote host declared in ~/.openrig/hosts.yaml (ssh hosts shell out; http hosts go CLI-direct to the remote daemon)")
.description("Post a message to a rig's chat room; the sender is this seat")
.argument("<rig>","Rig name")
.argument("<message>","Message to send")
.option("--sender <name>","(deprecated, ignored) the sender is derived from the seat env (X-OpenRig-Session); P21 made the chat route derive it from the transport header")
@@ -91,6 +109,7 @@ export function chatroomCommand(depsOverride?: StatusDeps): Command {
// chatroom history <rig> [--topic <name>] [--limit N] [--json]
cmd
.command("history")
.description("Print a rig's chat messages and topic markers, with filters")
.argument("<rig>","Rig name")
.option("--topic <name>","Filter by topic")
.option("--after <id>","Messages after this message ID")
@@ -154,6 +173,7 @@ export function chatroomCommand(depsOverride?: StatusDeps): Command {
// chatroom watch <rig> [--tmux]
cmd
.command("watch")
.description("Print a rig's chat messages as they arrive; --tmux runs it in its own tmux session")
.argument("<rig>","Rig name")
.option("--tmux","Run watch in a dedicated tmux session")
// r1 4d obs 2: default from the seat's own environment — a codex seat that
@@ -782,7 +778,8 @@ Examples:
// trace: the seat dir resolves from topology.root CONFIG; the write flows
// through the ONE store (supersession + addressability gate); advisory
// contract findings ride stderr while the write still lands — the boundary
// is never blocked on prose shape.
// is never blocked on prose shape. A process that may not write the topology
// tree (a sandboxed seat) hands the same recap to the daemon, which owns it.
cmd.command("recap-write")
.description("Write this seat's authored RECAP (decisions-with-rationale) at the handover boundary; supersedes the previous recap into the seat's chain")
.requiredOption("--rig <rig>","Rig name (the rigs/<rig> altitude)")
@@ -790,29 +787,33 @@ Examples:
.requiredOption("--file <path>","Markdown file containing the recap content")
console.log(`Not stopped: ${result.leftRunning.join(", ")}. Joined with rig attach as an external CLI, which OpenRig doesn't stop or check.`);
}
if(result.paneOnly&&result.paneOnly.length>0){
console.log(`Pane stopped: ${result.paneOnly.join(", ")}. A community harness's own processes may keep running after its pane; see its preset's limits.`);
}
// Exit code: errors first, then deleted, then alreadyStopped
console.warn("Warning: this export still installs as 'starter'. Before sharing, rename the team's name in rig.yaml; changing the bundle name alone does not rename the installed rig.");
console.warn(`Warning: ${pod.id}.${member.id} has an agent_ref outside this folder and is not portable. Copy that agent and its imports into this folder and use local: refs before sharing, or use rig bundle create with the original --rig-root to vendor them into an archive.`);
if(!["localhost","127.0.0.1","[::1]"].includes(newURL(client.baseUrl).hostname))thrownewError("the daemon is remote; copy it from the recorded rig root on that host");
copyCulture(culture,recordedRoot,outDir);
}catch(error){
console.warn(`Warning: could not copy culture '${culture}' from '${recordedRoot}': ${(errorasError).message}`);
}
}
constfilesToCheck: string[]=[];
if(typeofparsed["cultureFile"]==="string"){
filesToCheck.push(parsed["cultureFile"]);
@@ -71,11 +121,16 @@ export function exportCommand(depsOverride?: ExportDeps): Command {
.option("--organization <id>","The person's organization (create it first with rig gateway org set)")
.option("--group <id>","A group the person belongs to (repeatable; create it first with rig gateway group set)",(v: string,acc: string[]=[])=>{acc.push(v);returnacc;})
.option("--policy <text>","Readable policy for agents working with this person (text, not enforced)")
.option("--policy-file <path>","Read the policy text from a file")
.option("--default","Make this person the default: the one escalations, the notice digest and other unaddressed needs go to")
`refused: a human is already configured (${ids}). OpenRig supports one configured human, so \`rig gateway human add\` manages one; `+
`to register someone else, remove the existing one first (\`rig gateway human remove <entityId>\`). Fragments hand-authored under ${registry.humansDir()}`+
`are displayed as found, with an advisory, but no command manages several.`,
);
process.exitCode=1;
return;
// Several people may be registered. Their organization, groups, policy and the default go in the participant side
// file, never the fragment, so an older daemon still loads every person after a rollback.
if(opts.organization&&!side.file.organizations[opts.organization]){console.error(`refused: no organization "${opts.organization}" — create it with rig gateway org set ${opts.organization} --name …`);process.exitCode=1;return;}
if(unknownGroup){console.error(`refused: no group "${unknownGroup}" — create it with rig gateway group set ${unknownGroup} --organization … --name …`);process.exitCode=1;return;}
if(failed){console.error(`the person was registered, but part of their placement wasn't saved; fix it with rig gateway human set ${entityId} … or rig gateway default ${entityId}`);process.exitCode=1;}
.description("Show the configured human (OpenRig supports one; extra hand-authored fragments are listed with an advisory)")
.description("List the registered people, with delivery readiness and quiet hours (rig gateway participants adds organizations, groups, policy and shared channels)")
constquiet=human.command("quiet").description("Quiet hours: while on, routine asks to this person are held, not posted; urgent ones (tagged escalation) still reach them. Held asks post once, each on its own, when quiet ends");
@@ -520,13 +530,22 @@ Examples:
.description("Show the effective record: fragment values + which defaults filled the rest, with provenance")
.description("Edit one field through the verb (same validation as add; re-projection immediate). Fields: display-name, delivery-class, away, availability (available|focus|away|off, or unset), slack-subscription (the person's Slack subscription: every-ask, the default, posts every ask to Slack too; urgent-only posts only asks created with --alert, the rest wait on Steering and the TUI; or unset), binding.<n>")
.description("Edit one field through the verb (same validation as add; re-projection immediate). Fields: display-name, delivery-class, away, availability (available|focus|away|off, or unset), slack-subscription (the person's Slack subscription: every-ask, the default, posts every ask to Slack too; urgent-only posts only asks created with --alert, the rest wait on Steering and the TUI; or unset), binding.<n>; and, kept in the participant side file: organization (an id, or unset), groups (comma-separated ids, or unset), policy (text, @<path> to read a file, or unset)")
.option("--reason <reason>","Reason recorded with connector binding changes","update human binding")
.option("--actor <actor>","Named operator when outside a managed seat")
// ── Participants beyond people (0.7.3): shared channels, organizations, groups, readable policy and the default. All of
// it lives in gateway/participants.yaml, which older daemons don't read, so a rollback still loads every person.
constchannel=cmd.command("channel").description("Shared-channel participants: one vetted Slack channel is one participant (<id>@external), not a person per sender");
channel
.command("add <id>")
.description("Register a shared channel")
.requiredOption("--display-name <name>","Human-readable name, e.g. \"Acme customers\"")
.requiredOption("--binding <slack:connectorRef:secretsRef:channelId>","The channel: connector kind (slack), connector label, vault pointer for its secrets (never the secret), and the Slack channel id")
.option("--organization <id>","Its organization (create it first with rig gateway org set)")
.option("--group <id>","A group it belongs to (repeatable)",(v: string,acc: string[]=[])=>{acc.push(v);returnacc;})
.option("--policy <text>","Readable policy for agents answering this channel (text, not enforced)")
.option("--policy-file <path>","Read the policy text from a file")
.option("--replace","Explicitly replace an existing channel (no silent overwrite)")
if(parts.length<4||parts[0]!=="slack"){console.error("refused: --binding must be slack:<connectorRef>:<secretsRef>:<channelId>");process.exitCode=1;return;}
if(side.file.participants[id]?.kind!=="shared-channel"){console.error(`refused: no shared channel "${id}"`);process.exitCode=1;return;}
constaddress=`${id}@${registry.ADDRESS_DOMAIN}`;
constrowsRes=awaitqueueRows(address);
if(!rowsRes.ok){console.error(`refused: the queue could not be checked for rows addressed to ${address} (${rowsRes.error}); --force doesn't override an unchecked board`);process.exitCode=1;return;}
if(rowsRes.rows.length&&!opts.force){
console.error(`refused: ${rowsRes.rows.length} non-terminal row(s) are addressed to ${address} (${rowsRes.rows.map((r)=>r.id).join(", ")}); pass --force to remove anyway`);
.description("Show or choose the default person: the one escalations, the notice digest, Mission Control's my-queue and pairing go to when no person is named")
.option("--clear","Clear the chosen default (with one person, they stay the default)")
diagnosis.command("record <qitem-id>").requiredOption("--file <path>","Disposition JSON with verdict, causalStart, steering, uncertainty, evidenceRefs").option("--json")
diagnosis.command("record <qitem-id>").description("Record an agent's disposition for one occurrence from a JSON --file").requiredOption("--file <path>","Disposition JSON with verdict, causalStart, steering, uncertainty, evidenceRefs").option("--json")
detail:`replies addressed @${hostId} go to '${winner.id}', not '${host.id}' (${REPLY_ROUTE_ORDER})`,
fix:`run rig host doctor ${winner.id}; if it no longer reaches this machine, delete its entry from ${defaultHostRegistryPath()} (and its line in ${defaultHostBindingsPath()}, if any)`,
detail:`replies addressed @${hostId} resolve to '${host.id}', so they fail while it is unreachable`,
fix:`if another entry reaches this machine, delete '${host.id}' from ${defaultHostRegistryPath()} (and its line in ${defaultHostBindingsPath()}, if any), then run rig host doctor on that entry; otherwise restore this entry's connectivity`,
rows.push({step:"transport-reachability",status:"fail",detail:`daemon unreachable at ${(hostasHttpHostEntry).url}: ${(errasError).message}`,fix:"check tailnet connectivity and that the remote daemon is running (rig daemon start on the host)"});
@@ -23,24 +23,46 @@ export function mcpCommand(depsOverride?: StatusDeps): Command {
.option("--port <port>","Daemon port override")
.option("--http","Serve over Streamable HTTP at /mcp instead of stdio")
.option("--bind <host:port>","With --http: where to listen (default 127.0.0.1:7437). Beyond loopback needs a grant (rig mcp token add)")
.option("--grant-service <url>","With --http: check each request's key with the grant service at this URL instead of the token file")
.option("--grant-service-header-file <path>","With --grant-service: a file holding one 'Name: value' header to send with each grant request")
.option("--oauth-resource <url>","With --grant-service and --oauth-issuer: the public https URL clients reach this server as (its path ends in /mcp), for OAuth discovery")
.option("--oauth-issuer <url>","With --oauth-resource: the OAuth authorization server that issues the keys --grant-service checks")
?`OpenRig MCP over HTTP at ${served.url}: each request needs a key from the grant service, checked with ${grantService}.`
:served.authenticated
?`OpenRig MCP over HTTP at ${served.url}: each request needs a bearer credential from ${tokenFile}.`
:`OpenRig MCP over HTTP at ${served.url}: no grants, so loopback only, acting as ${seat||"no seat"}, declared and not authenticated. Add a grant (rig mcp token add) before reaching it through a tunnel or proxy.`);
if(oauth)console.error(`OAuth discovery names ${oauth.resource}, issued by ${oauth.issuer}.`);
experimental.command(verb).requiredOption("--config <file>","Explicit local experiment JSON; contains no credential")
experimental.command(verb).description(experimentVerbDescriptions[verb]).requiredOption("--config <file>","Explicit local experiment JSON; contains no credential")
.option("--max-requests <n>","Maximum requests per foreground run, 1..20")
console.log(`Claude token: ${claude.tokenFile?`"${claude.label}", read from ${claude.tokenFile} when Claude starts`:"none (the config dir's stored login)"}`);
if(claude.instead)console.log(`instead of the stored login, the seat would use ${claude.instead}`);
if(claude.checked.length)console.log(`checked for anything that outranks it: ${claude.checked.join("; ")}`);
if(claude.notChecked.length)console.log(`not checked (the seat's /status shows what it uses): ${claude.notChecked.join("; ")}`);
?`configured: profile ${c["profileRef"]} (registry, recorded ${c["recordedAt"]}${c["profileSaved"]===false?"; profile not saved on this host":c["profileSaved"]===null?"; whether the profile is saved: unknown":""})`
:c["source"]==="default_login"&&c["homeFrom"]
?`configured: the seat's own home (${c["home"]}, from its ${c["homeFrom"]} env)`
if(ignored)console.log(` ignored: its ${ignored["from"]} env sets ${ignored["variable"]}=${ignored["value"]}, which isn't an absolute path, so it isn't used as this seat's home`);
?`${pad} identity refresh failed at ${last["at"]}: ${failureText(last)}; the identity shown is from the last refresh that worked, if any`
:`${pad} refresh failed at ${last["at"]}: ${failureText(last)}; last reading kept, marked old`);
}
@@ -369,14 +409,22 @@ export function providerCommand(depsOverride?: StatusDeps): Command {
.option("--json","Output as parseable JSON")
.option("--refresh","First read the Codex login's usage windows and the Claude login's identity natively (up to 35 s here, 75 s with --all-hosts/--hosts; provider.usage_windows is off by default: rig config set provider.usage_windows true)")
.option("--provider <p>","With --refresh, read only this provider (codex|claude)")
.option("--claude-token-file <path>","With --refresh --provider claude, probe this absolute token-file reference on the selected daemon (one model turn; no token value in argv)")
.option("--credential-label <label>","Operator label for the selected Claude token file; not provider-observed account identity")
.option("--all-hosts","Usage windows across every registered host, as each host already holds them (off by default: rig config set provider.usage_windows true)")
.option("--hosts <ids>","Like --all-hosts, for these registered hosts (comma-separated); this host is always included, so --hosts b --refresh also reads this daemon")
console.error("A token probe requires --refresh --provider claude --claude-token-file <absolute path> --credential-label <label>, on one daemon (no --all-hosts/--hosts).");
process.exitCode=1;return;
}
if(tokenSelected)console.error("Claude token usage refresh spends one model turn; timeout or refusal does not prove no allowance was consumed.");
constclient=awaitgetClient(getDeps());
if(!client){
process.exitCode=1;
@@ -395,7 +443,7 @@ export function providerCommand(depsOverride?: StatusDeps): Command {
.option("--to-account <a>","Codex: the login's saved name in the seat's Codex home (rig auth list --codex-home <home>). Claude: your label for the token")
.option("--token-file <path>","Claude: the absolute path of a 0600 file holding the seat's own subscription token; it's read only as Claude starts")
.option("--stored-login","Claude: move the seat back to its config dir's stored login")
if(!res.data.safe)process.exitCode=1;// let scripts gate on an unsafe verdict
});
cmd
.command("switch")
.description("Switch a seat to an account (precheck-gated; the daemon orchestrates the switch)")
.description("Move one seat to another subscription login, keeping its conversation: a Codex seat to a login saved in its Codex home (Linux only), a Claude seat to its own token file")
.option("--force-unsafe","Override a non-stranding precheck failure (still refuses to strand a live conversation)")
.option("--to-account <a>","Codex: the login's saved name in the seat's Codex home (rig auth list --codex-home <home>). Claude: your label for the token")
.option("--token-file <path>","Claude: the absolute path of a 0600 file holding the seat's own subscription token; it's read only as Claude starts")
.option("--stored-login","Claude: move the seat back to its config dir's stored login")
.option("--force-unsafe","Kept for scripts; a seat's checks can't be overridden, since each means nothing safe to restart or no such login")
message:`The CLI timed out waiting for the daemon. The switch may still be running, or queued behind another switch on the same Codex home; a queued switch hasn't changed anything yet. `
+`For a Codex seat, it has restarted the seat once rig seat restart ${opts.seat} --keep-conversation --plan shows a lastRestart that finished after ${startedAt}. `
+`Until then an eligible plan, or an older lastRestart, doesn't mean it ended, so don't run the switch again: a second one would queue behind it. `
+`For a Claude seat, rig seat status ${opts.seat} shows its token reference and whether it runs; a second switch would wait for this one.`}};
console.log(`to restore the home's saved credential bytes: ${seat.undo}`);
console.log("undo restores saved credential bytes only; sign-in is unverified. Saved credentials may expire, be revoked, or be superseded by refresh elsewhere. Restart the affected seat and use the existing account verification; fresh sign-in may be required.");
}
}elseif(seat){
console.log(`Claude token: ${seat.tokenFile?`"${seat.account}", read from ${seat.tokenFile}`:"the config dir's stored login"}${seat.loginChanged
?seat.tokenApplied===false?" (reference saved; the token didn't take effect)":" (set)":""}`);
@@ -165,7 +165,9 @@ function terminalDeliveryResult(
"claimed":"Terminal receipt unconfirmed, but the seat has claimed the item (claimed).",
"retained":`The wake is held (${wakeResult}): nothing was typed into the pane. A held create wake is not retried automatically; inspect it with rig seat held-messages ${seat}.`,
return{row: null,note:`Row ${qitemId}${where} exists, but this CLI couldn't read this daemon's host id to tell whether its source is this create's, so the outcome is still unknown.`};
}
if(differs){
return{row: null,note:`Row ${qitemId}${where} exists but isn't this create (its ${differs} differs), so the outcome is still unknown. Don't reuse this ID for other work.`};
}
return{row: res.data,note:`The create committed after all: row ${qitemId}${where} (read back by its ID).`};
}
if(res.status===404)return{row: null,note:`No row ${qitemId}${where} yet (read back once by its ID); it may still commit.`};
return{row: null,note:`Reading row ${qitemId}${where} back answered ${res.status}, so the outcome is still unknown.`};
}catch(err){
return{row: null,note:`Reading row ${qitemId}${where} back didn't answer (${(errasError).message}), so the outcome is still unknown.`};
// P21 I3 reconcile: the claimant is DERIVED from the seat env — --destination deprecated + ignored,
// no body claim. Verify the env (the header source) or the daemon returns 400 actor_required (no seat identity to record; P18 retired the 401 refusal).
@@ -1025,11 +1194,11 @@ export function queueCommand(depsOverride?: QueueDeps): Command {
cmd
.command("update <qitemId>")
.description("Append a note and/or mutate qitem state. A note without --state never changes row state. state=done REQUIRES --closure-reason (one of: handed_off_to, denied, canceled, no-follow-on, escalation, superseded). To wait for another qitem, use rig queue block <id> --on <child>. Closure ≠ acceptance: handed_off_to records delivery to the next stage; acceptance is the next stage's verdict on its own qitem, not this closure.")
.description("Append a note and/or mutate qitem state. A note without --state never changes row state. state=done REQUIRES --closure-reason (one of: handed_off_to, denied, canceled, no-follow-on, escalation, superseded). To cancel a row: --state done --closure-reason canceled. To wait for another qitem, use rig queue block <id> --on <child>. Closure ≠ acceptance: handed_off_to records delivery to the next stage; acceptance is the next stage's verdict on its own qitem, not this closure.")
.option("--actor <session>","(deprecated, ignored) the actor is derived from the seat env (X-OpenRig-Session); P21 I3 made the update route derive it from the transport header")
.option("--reopen","Explicitly acknowledge a deliberate terminal-to-active repair; requires --state and --note")
.option("--closure-reason <reason>","Required for state=done; also 'superseded' on state=canceled (with --closure-target = the successor) records a supersession, distinct from an abandoned cancel")
.option("--closure-reason <reason>","Required for state=done. --state canceled takes no reason, except 'superseded' (with --closure-target = the successor), which records a supersession, distinct from an abandoned cancel")
.option("--closure-target <target>","Required for handed_off_to, escalation, and superseded; blocked_on park records use state=blocked with --blocked-on")
.option("--resolution <text>","The outcome, stored on the row and shown by rig queue show. Needs --state done, canceled, denied, failed or handed-off, and non-blank text. Stored when the update closes an open row, after anything the row already has (a fallback line, an earlier outcome); a row that is already closed keeps what it has")
.option("--blocked-on <blocker>","For state=blocked: the blocker — a qitem id (must exist and be live), a human seat (FR-6 park; requires summary + evidence_ref), or a typed non-qitem gate 'fold:<what>' / 'auth:<what>' / 'external:<what>'")
@@ -1074,7 +1243,7 @@ export function queueCommand(depsOverride?: QueueDeps): Command {
// P21 I3 reconcile: the actor is DERIVED from the seat env (X-OpenRig-Session, stamped by
// DaemonClient) — --actor is deprecated + ignored, no body actorSession. Verify the env (the
// header source) or the daemon returns 400 actor_required (no seat identity to record; P18 retired the 401 refusal). Matches `resolve`.
@@ -1162,8 +1331,8 @@ workspace home that is deferred/not-imminent belongs in its mission/slice.`)
// in-progress on the SAME item) — never a closure, never a new owner.
cmd
.command("resolve <qitemId>")
.description("Resolve a leg-1 parked qitem (state=blocked on a human seat): records the decision text durably in queue_transitions, unparks blocked -> in-progress, and nudges the owner. Non-closure.")
.requiredOption("--decision <text>","The human's decision text (non-empty; lands in transition_note + the audit row)")
.description("Resolve a qitem blocked on a human seat or a typed gate (external:, fold:, auth:): records the decision or satisfaction evidence durably, unparks blocked -> in-progress, and nudges the owner. Non-closure; qitem dependencies are not resolved by this command.")
.requiredOption("--decision <text>","The human decision or typed-gate satisfaction evidence (non-empty; lands in transition_note + the audit row)")
.option("--actor <session>","(deprecated, ignored) resolver is derived from the seat env (X-OpenRig-Session)")
.option("--bearer <token>","Operator bearer token for the mission-control write gate (or set OPENRIG_AUTH_BEARER_TOKEN; loopback daemons without a configured bearer need none)")
.option("--no-notify","Skip the best-effort owner nudge (the unpark still commits)")
@@ -1178,7 +1347,7 @@ workspace home that is deferred/not-imminent belongs in its mission/slice.`)
// P21: the resolver is DERIVED from the seat env (X-OpenRig-Session, stamped by DaemonClient) —
// --actor is deprecated + ignored. The pre-check verifies the env (the header source); else the
// daemon returns 400 actor_required (no seat identity to record; P18 retired the 401 refusal).
@@ -1238,7 +1407,7 @@ workspace home that is deferred/not-imminent belongs in its mission/slice.`)
})=>{
// P21 I3 reconcile: the handing-off seat is DERIVED from the seat env (X-OpenRig-Session) —
// --from deprecated + ignored, no body fromSession. Verify the env or the daemon returns 400 actor_required (no seat identity to record; P18 retired the 401 refusal).
@@ -1342,7 +1511,7 @@ workspace home that is deferred/not-imminent belongs in its mission/slice.`)
})=>{
// P21 I3 reconcile: the handing-off seat is DERIVED from the seat env (X-OpenRig-Session) —
// --from deprecated + ignored, no body fromSession. Verify the env or the daemon returns 400 actor_required (no seat identity to record; P18 retired the 401 refusal).
// P21 I3 reconcile: the sender is DERIVED from the seat env (X-OpenRig-Session) — --sender
// deprecated + ignored, no body senderSession. Verify the env or the daemon returns 400 actor_required (no seat identity to record; P18 retired the 401 refusal).
:member.hosted?"A hosted member: it has no pane, and OpenRig doesn't observe it between calls"
:"No exact hostSelfId and seat match; check observation gaps")
:current?"Registry, activity and labelled last model observation; not a promise about the next turn":"Seat is not reported running; current runtime and model are unknown",
runtime: current?text(node?.runtime):null,
configuredModel: current?text(node?.model):null,
@@ -122,6 +76,11 @@ export function enrichRosterMember(member: RosterMember, inventory: RosterInvent
for(constsourceofobs.sources)if(source.status!=="ok")console.error(`Observation gap (${source.scope}): ${source.warning??source.error??source.status}`);
@@ -1057,7 +1068,7 @@ function buildResolveNotesCommand(): Command {
functionbuildAuditCommand():Command{
returnnewCommand("audit")
.description("Read-only scope audit: flag scope findings and show the advisory dependency graph")
.description("Read-only scope audit: flag scope structure findings and show the advisory dependency graph. It doesn't read proof readiness: use rig proof show")
.requiredOption("--mission <name>","Mission to audit")
.option("--json","Machine-readable JSON output")
.action(async(opts,command)=>{
@@ -1065,7 +1076,7 @@ function buildAuditCommand(): Command {
.description("Scope tree primitive: missions, slices, sub-slices (per conventions/scope-and-versioning)")
.option("--workspace <path>","Workspace root; use its project.yaml missions.root, else missions/. A directory named missions without its own missions/ child is used directly. If the tree is missing, fall back to configured workspace.slices_root, except mission create, which creates the named tree, and approve, which refuses. Without this flag, OPENRIG_WORK_ROOT is tried first with the same exceptions.");
.option("--workspace <path>","Workspace root; use its project.yaml missions.root, else missions/. A directory named missions without its own missions/ child is used directly. If the tree is missing, fall back to configured workspace.slices_root, except slice create and approve, which refuse, and mission create, which refuses a path that isn't an existing directory and otherwise creates the missions tree inside it. Without this flag, OPENRIG_WORK_ROOT is tried first with the same exceptions.");
console.log(`Runtime home (${h.variable}) for launches: ${display(h.home)} (${from}; configured, not proof of the login a running session uses)`);
if(h.ignored)console.log(` Ignored: its ${h.ignored.source} env sets ${h.variable}=${h.ignored.value}, which isn't an absolute path`);
}
if(status.claude_token){
constt=status.claude_token;
console.log(`Claude subscription token: ${t.label}, read from ${t.token_file} at each launch (${t.file==="readable"?"readable now":"won't apply at the next launch"})`);
// The packet was pasted and Enter pressed: the successor may already be working on it, so don't send it again.
console.log(`The captured startup context (restore packet) was sent to the successor, but its submission is unconfirmed: ${result.restorePacket.reason}.`);
console.log("Check the successor's screen before sending the context again; it may already be working on it.");
console.log("No conversation continuity, provenance markdown, or session stop was performed.");
}elseif(result.source.mode==="fork"){
console.log("No packet delivery: fork context rides the native conversation itself.");
.option("--mode <mode>","off, draft-aware, openrig-urgent, urgent-only, sends-only or hold; choose this or --enabled")
@@ -542,7 +611,7 @@ rig seat handover, THEN retarget the view. Examples:
cmd
.command("clear-attention")
.argument("<session>","Canonical session name (e.g. dev-impl@my-rig)")
.option("--reason <text>","Attest startup or subset-restore attention; cannot bypass full-restore or pane-identity checks")
.option("--reason <text>","Attest startup or subset-restore attention, or that a prompt the latest hook names is gone; cannot bypass full-restore or pane-identity checks")
.option("--json","JSON output for agents")
.description("Reconcile seat attention using the checks for its attention class")
@@ -692,14 +766,47 @@ identity remains unverified; a version number alone cannot clear it.
cmd
.command("set-permissions")
.argument("<seat>","Canonical session name or logical seat ref")
.requiredOption("--mode <mode>","floor, full_bypass, inherit, or a Claude mode supported by the bound managed launch context")
.option("--mode <mode>","floor, full_bypass, inherit, or a Claude mode supported by the bound managed launch context")
.option("--rules <file>","JSON allow/deny lists for this Claude seat; replaces its recorded rules without changing its mode")
.option("--codex-permissions <file>","JSON sandbox/approval envelope for this Codex seat; replaces its recorded mode")
.option("--codex-profile <name>","Codex config profile for this seat, or inherit to clear it; approval stays with the envelope or session")
.requiredOption("--reason <text>","Reason for the audited future-launch selection")
.option("--operator <address>","Operator recorded on the audit event when no session identity is present")
.option("--json","JSON output for agents")
.description("Select native permissions for future managed launches; no relaunch or work-posture change")
.addHelpText("after","\nUse inherit to clear this seat's explicit selection. Current native processes, history, rules and hooks remain unchanged. A later lifecycle action needs its own authorization.")
.addHelpText("after","\nUse inherit to clear this seat's explicit selection. Current native processes, history, rules and hooks remain unchanged. A later lifecycle action needs its own authorization.\n--rules takes a JSON object with allow and deny lists only. Use empty lists to clear the seat rules. It does not remove inherited grants or change the running process.\n--codex-permissions takes a JSON object: sandbox (workspace-write or read-only), approval (never, on-request or untrusted), and for workspace-write network_access, writable_roots (absolute paths), exclude_tmpdir_env_var and exclude_slash_tmp. It replaces a recorded mode; --mode replaces the envelope. Full access stays --mode full_bypass.\n--codex-profile reports an absent, changed or unchecked profile file without refusing; a profile that fails to load is refused.")
console.log(`Codex permission envelope ${data["changed"]===false?"unchanged":"recorded and audited"}${replaced?.mode?.mode?`; it replaces the recorded ${replaced.mode.mode} mode`:""}.`);
if(observed?.detail)console.log(`Profile file: ${observed.file??"unverified"}${observed.changedSinceRecorded?", changed since last recorded":""}. ${observed.detail}`);
if(data["dryRun"])console.log(`Runtime switch plan for ${name}: ${String(data["from"])} -> ${String(data["to"])}. Nothing changes until you run it without --dry-run.`);
elseconsole.log(`Switched ${name} from ${String(data["from"])} to ${String(data["to"])} (switch ${String(data["switchId"])}).`);
console.log(`Settings on ${String(data["to"])}:`);
if(confirmation)console.log(`The successor confirmed the handover: "${confirmation.note}"`);
console.log(`Queue: ${String(data["openRows"]??0)} open rows stay addressed to the seat; ${String(data["claimsMoved"]??0)} claims moved to the successor.`);
@@ -238,7 +238,7 @@ export function sendCommand(depsOverride?: SendDeps): Command {
.option("--rig <name>","Send to every seat in a rig (fan-out, per-recipient results)")
.option("--verify","Verify pane only delivery by checking content after send")
.option("--force","Back-compat no-op: a mid-task/busy pane already sends-with-advisory by default; --force never bypasses the interactive-prompt/permission guard")
.option("--wait-for-idle <seconds>","Wait until the target is explicitly idle before sending")
.option("--wait-for-idle <seconds>","Wait until the target is explicitly idle before sending. If it's still busy, or its activity is unknown, when the wait ends, nothing is sent (exit 1) and nothing is kept to send later; put separate work in a queue row (rig queue create)")
.option("--raw","Send exact text/keystrokes without the From/To messaging envelope (still guarded against interactive prompts)")
.option("--dangerously-interact","DANGEROUS: type an answer as keystrokes into an interactive prompt (implies --raw; requires --reason). Letters can select menu shortcuts; CR/ESC act as keys. Enter is added only for the complete visibly staged answer.")
.option("--type-without-checking","With --dangerously-interact: type without reading or clearing existing input; may join or submit that text")
@@ -282,7 +282,11 @@ determined (unknown / missing / stale telemetry) the send PROCEEDS with an
lines.push(`Queued or uncertain asks have no Slack receipt yet. Run ${POST_OPEN_ASKS} again later to see where they landed; it reuses each ask's decision rather than offering it again.`);
}
if(counts.has("state-unavailable")){
lines.push(`No new offer was made for an ask whose state couldn't be read; its detail says what couldn't be read and what is known. Run ${POST_OPEN_ASKS} again once that reads, and the same ask continues.`);
}
if(counts.has("transport-failed"))lines.push("A transport failure is on the ask's row, and `rig queue undelivered` lists it for the seat that asked.");
?"Kernel auto-boot skipped (kernel rig already managed). If its seats are not running, for example after a reboot, bring it back with: rig up kernel --existing"
:"Kernel auto-boot skipped (--no-kernel or test mode), including the operator that helps you start a team. To start it later, run rig, set up or select kernel, then start its operator seat.");
// This command does not restore a kernel the daemon skipped; say why, and the way back.
console.error(`${terminalFailure?"Kernel failed to start":"Kernel did not report ready before the deadline"}: state=${kernelResult.kernelState??"unknown"}, detail=${kernelResult.detail??"none"}`);
"Open the OpenRig view and agent conversations in terminal tiles",
).addHelpText("after","\nThe OpenRig TUI and operator (after install, and whenever the person wants their agents):\n rig terminal open saved:kernel --window\n Opens the window itself on the daemon's desktop; an agent can run it from its shell.\n Uses herdr when installed, otherwise the same layout in plain tmux.\n Herdr needs a terminal the person can see; TUI navigation does not open one.\n Over headless SSH, give the exact connection/attach command for a new terminal/tab.\n Only if the window cannot open: rig tui --shared is the dashboard-only fallback.\n On a desktop, the agent opens the view; it does not finish by printing a command to copy.\n");
).addHelpText("after","\nThe OpenRig TUI and operator (after install, and whenever the person wants their agents):\n rig terminal open saved:kernel --window\n Opens the window itself on the daemon's desktop; an agent can run it from its shell.\n Inside Rex it opens a Rex session and shows it in the Rex app; otherwise it uses herdr when installed, else the same layout in plain tmux.\n Herdr needs a terminal the person can see; TUI navigation does not open one.\n Over headless SSH, give the exact connection/attach command for a new terminal/tab.\n Only if the window cannot open: rig tui --shared is the dashboard-only fallback.\n On a desktop, the agent opens the view; it does not finish by printing a command to copy.\n");
constgetDeps=():TerminalDeps=>
depsOverride??{
@@ -111,27 +126,43 @@ export function terminalCommand(depsOverride?: TerminalDeps): Command {
cmd
.command("open")
.argument("<view>","a rig name, mission:<id>, slice:<id>, or a saved-view id")
.argument("<view>","a rig name, pod:<rig>/<pod>, seat:<rig>/<logical-id>, mission:<id>, slice:<id>, qitem:<id> (current local obligation owners), or a saved-view id")
.description("Open a desktop terminal showing the view's live agents as interactive tiles")
.option("--provider <name>","herdr or cmux: use an existing workspace without opening a window; tmux requires --window")
.option("--provider <name>","herdr, cmux or rex: open in the running provider without a desktop window; each open adds a new workspace (inside Herdr, --window reuses a matching one); tmux requires --window. Inside Rex, the default opens in Rex")
.option("--session <name>","Herdr session on the daemon's host; --session default selects Herdr's default session")
.option("--window","Open a new desktop terminal tab/window (the default when --provider is omitted)")
.option("--expected-plan <id>","Open only if the view still matches this preview")
.option("--follow","Keep one qitem:<id> workspace following current obligation owners (Linux Herdr 0.9.5/protocol 22)")
.option("--no-follow","Stop following and keep the existing workspace and tiles as a fixed layout")
.option("--max-tiles <count>","Following tile limit, 1–256; explicitly raise it to show more members",Number)
.option("--pin <seats...>","Retain these following tiles after they leave the task")
.option("--unpin <seats...>","Remove pins from these following tiles")
.option("--suppress <seats...>","Temporarily hide these following tiles; agents keep running")
.option("--unsuppress <seats...>","Show these following members again")
.option("--suppression-ms <ms>","Suppression duration, default 60000, at most 86400000",Number)
.option("--grace-ms <ms>","Departure grace, default 4000, at most 60000",Number)
.option("--focus-retention-ms <ms>","Extra focused-reading retention, default 12000, at most 300000",Number)
printResult(opts.json??false,{error: preview.data.error??"The daemon did not confirm the requested Herdr session. Update the daemon before opening a named session.",code:"terminal_session_unconfirmed"},preview.status>=400?preview.status : 409);return;
}
@@ -141,7 +172,8 @@ export function terminalCommand(depsOverride?: TerminalDeps): Command {
console.error(`--env ${name} isn't applied: a seat's runtime home comes from env: in its rig spec (member or rig), so a restore, a handover and rig seat status all agree. Declare it there.`);
?"Kernel auto-boot skipped (kernel rig already managed). If its seats are not running, for example after a reboot, bring it back with: rig up kernel --existing"
:d.startsWith("kernel rig already managed")
?`Kernel auto-boot skipped: ${d}`
:"Kernel auto-boot skipped (--no-kernel or test mode), including the operator that helps you start a team. To start it later, run rig, set up or select kernel, then start its operator seat.";
Loaded 100 of 868 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
dev-guard