Adds packages/daemon/assets/plugins/openrig beside openrig-core, shipped in the npm package. Its Claude Code manifest runs rig mcp serve --front-door with OPENRIG_SESSION_NAME from the plugin's seat setting, the app's address on the person's team as a hosted member; there is no root .mcp.json and no hooks. A marketplace manifest named openrig-app installs it from the package already on the machine, and a Codex manifest connects it with one command. One new skill, working-with-an-openrig-team, describes the loop around the existing MCP tools; its home is the spec copy, and mirror-skills generates the canonical and plugin copies and routes it in the skills index. rig mcp serve --front-door gives the plugin's seat front-door instructions (the person's questions and words, with no member work-loop authority), and rig_whoami answers a declared hosted seat with no session when its rig exists; the default instruction modes and tool exposure are unchanged.
rig acp serve runs OpenRig as an ACP agent over stdio. A prompt becomes a queue row to the receiver named by --to, attributed to the caller (--as, the seat environment, or the default person) with the session's follow-up lineage in its body; the turn follows the row and its handoffs, including handoff-and-complete's done/handed_off_to form, and ends with the team's result, naming the closer from the row's closing transition. The row ID is chosen before the create: when a create gets no answer, a readback that finds the row carries on, and one that doesn't keeps the ID as unconfirmed in the session's lineage; an answered 4xx is a plain refusal and a 5xx stays unknown. The JSON-RPC peer splits into the existing client end and a new stream end over stdin and stdout, with no protocol SDK dependency. The queue is the only store, and a 2 s poll follows open turns.
A timed-out or unreadable rig stream emit can still land late. Its error now names the retry that can't add a second item: with --id, repeat the same emit with that --id (the daemon keeps one item per stream item ID) or check first with rig stream show <id>; without --id, check with rig stream list --source <recorded seat> --since <five minutes before the send>, using the seat the daemon records, and pass a stable --id on later emits. queue create is unchanged; its existing --id already makes a retry safe, and the openrig-user skill now says so for both in one paragraph (skill digest updated). No new refusal, error code or setting.
scripts/fixtures/packaged-plugins-last-release.json now names release 0.7.9, its published archive (sha256 668b9305...) and the openrig-core 0.1.25 payload it shipped (f1838261...), byte-equal to a --snapshot of the published npm tarball and to the v0.7.9 tag's plugin tree. openrig-core moves from 0.1.25 to 0.1.26 in both harness manifests: its files changed on main after 0.7.9 (permission-stop descriptor, refocus and the trace script), and check-packaged-plugin-versions.mjs requires a greater version when packaged bytes change, so existing installs don't keep old content. The check fails at 0.1.25 and passes at 0.1.26; nothing else pins 0.1.25. No other file.
The openrig-core refocus hook marks a `rig queue whoami` lookup that ended in ETIMEDOUT and passes `--work-unknown-timed-out` with `--work-unknown`. With `--unresolved-work-advisory` (passed since #2582), trace-to-root.py prints "TRACE GAP — current work node UNKNOWN: queue whoami failed: spawnSync rig ETIMEDOUT" plus the project-level chain, labelled a broad orientation and not evidence of a current mission, and doesn't fail `--check`, so the timeout no longer counts toward "Refocus failed on N consecutive attempts". Non-zero exits, other spawn errors, unreadable answers, no remaining budget and a run without the advisory flag stay strict. A timed-out refocus now clears the pending post-compaction retry, as #2582's advisory does, so a slow daemon isn't queried again on every prompt. The skill digest is regenerated. Refs #2581: the part #2582 left open.
The openrig-core refocus hook passes a new --unresolved-work-advisory flag to the refocusing trace script. With that flag, when the work basis says typed work did not resolve (no matching node, or a mission or slice that resolves to more than one directory), the trace prints "TRACE GAP — no single current work node" with the reason, then the project-level chain labelled as broad orientation, not evidence of a current mission. The hook can then tell that advisory from an operational trace failure. Without the flag, and for conflicting tags, several fully resolved nodes, or an unreadable queue response, the script stays strict and exits nonzero as before. The skill's edge digest is regenerated. Refs #2581; the separate queue whoami timeout case is unchanged.
The packaged-plugin version check now compares against the published 0.7.8 package (archive f175a5b1, openrig-core 0.1.24), and openrig-core moves to 0.1.25 in both harness manifests. Since 0.7.8, the plugin's seat-continuity-and-handover skill changed (#2420) while its version stayed 0.1.24, and the old 0.7.6 baseline let that pass, so existing installs could have kept the old file under the same version. Against the new baseline the check fails at 0.1.24 and passes at 0.1.25.
The CLI package build now stages `packages/daemon/assets` with Node's `fs.cp` (recursive, `verbatimSymlinks`) instead of `cp -r`. Staged assets keep their source modes, so a build run under a narrower umask than the checkout no longer packs them as 0600 or 0700 (npm keeps owner-only bits when packing). A relative link stays a link in staging and is omitted by npm, rather than being followed and copied in on macOS. Copied bytes and sources are unchanged, and a failed copy still stops the build before the staged root is recorded. Only the assets step changes; the other copy steps still use `cp -r`. Contributed by @Aummadour.
A scheduled reminder that couldn't reach its seat, for example after a reboot where the daemon starts before tmux, now stays owed and recovers instead of silently moving on to the next cycle. Each periodic occurrence, including each parked-row digest member, gets its own receipt in the existing outbox and retries through the existing scheduler and wake retry settings (default three retries, five minutes apart). A confirmed delivery is never sent again after interrupted accounting or a restart, and an uncertain one is never replayed. Exhaustion or an unconfirmed result ends only that occurrence, with its cause and next action recorded, and a recurring reminder keeps its normal cadence under a new occurrence; only a permanent transport failure ends the job. A one-shot park timer records its failed wake on its row before it ends, and a pending retry leaves its binding armed with a retry note. The fire stamp and the queue wake receipt and one-shot retirement commit in one transaction, with input outside it. Refusals are read with the transport's own rule (sent false or input not reached), and the external-CLI and interactive-prompt refusals are labelled, which the queue wake classifier, draft-aware delivery, compaction preparation, claim hints and the transport receipt also read. Abandoned occurrence claims are marked indeterminate at startup, before anything sends. Limits: scope is periodic reminders and parked-row digests, while condition watches, the parked-owner policy and explicit sends are unchanged; no schema, API, scheduler or replay of earlier failures is added, and previously recorded failures can't be reconstructed; while a retry waits, the existing one-second loop still evaluates it; a later recurring cycle is a new occurrence, not confirmation of an uncertain one.
Step 4 of the openrig-upgrade skill now works on a host without the sqlite3 CLI when the running Node provides node:sqlite. backup-sqlite.mjs still uses the sqlite3 CLI's .backup first (OPENRIG_SQLITE_BIN, or sqlite3 on PATH); when the CLI isn't there, it uses Node's built-in node:sqlite online backup() for a page-for-page copy, and VACUUM INTO only when backup() isn't available, then checks the copy with PRAGMA integrity_check. With neither the CLI nor node:sqlite, it stops with a message naming both remedies. It needs no extra dependency. A focused test runs the helper with an empty PATH, confirms sqlite3 can't be found, and checks the copied database. Reported in #2391 by @ziadeh. Contributed by @mohitdixit02.
A rebuild handover's receipt now says what happened. sideEffects.provenanceRecordWritten is measured: commit() reads the node's occupant tenure before and after recording the handover in its own transaction, and reports true when a new handover-kind tenure exists for the reserved generation; a swallowed mint failure reads false. A new sideEffects.departingProcess reports ended-graceful, ended-forced or not-touched, from the in-place termination the successor launch already performs. departingSessionKilled stays false, which is accurate: the tmux session is kept and the pane respawns. The CLI's human lines and the seat-continuity-and-handover skill now say whether the lineage record was written, how the old process ended, and that a bound seat whose record is missing shouldn't be handed over again.
7 files, +125/-20, most of it tests.
A clean install of the CLI couldn't start: bare `rig` and `rig --help` exited 1 with `ERR_MODULE_NOT_FOUND` for `@modelcontextprotocol/sdk`. `packages/cli/src/commands/environment.ts` imports the SDK client at module load and `index.ts` loads the environment command statically, but the SDK was declared only in the CLI's `devDependencies`, so an install without development dependencies didn't have it. The SDK (`^1.32.2`) is now a production dependency of `packages/cli`; the lockfile update is metadata only (its dev flags), with no package added, removed or re-versioned. `scripts/cli-runtime-dependencies.test.mjs` walks the import closure from the CLI's entry points and fails if any external package it reaches isn't a production dependency, and the testbed image now runs `rig --help` after `rig --version`.
4 files, +77/-87.
The packaged-plugin version check (`scripts/check-packaged-plugin-versions.mjs`) requires a bundled plugin's version to advance when its files change, measured against `scripts/fixtures/packaged-plugins-last-release.json`. That baseline still described 0.7.2 (openrig-core 0.1.19), so a plugin change since 0.7.6 could pass without a version bump, and two installs could carry different hook or skill files under the same plugin version. The fixture now describes the published 0.7.6 package (openrig-core 0.1.23), checked byte-equal against the published tarball and the v0.7.6 tag's tree. openrig-core moves to 0.1.24 in both harness manifests: main was still at 0.1.21, because 0.7.6's version bump lived only on its release branch, and the plugin's files have changed since. Against the old baseline the check passed wrongly; against the new one it fails at 0.1.21 and passes at 0.1.24. Three files, +6/-6; no source or test change.
rig seat handover's help, guidance, skill and lifecycle doc now say --source fork:<seat>, which is what the command resolves; they said fork:<id>. A --dry-run now checks a fork source the same way the real run does (the session exists, has a native conversation id and runs the seat's runtime) and returns the same refusal, instead of accepting a source the real run would refuse. The real run's checks are unchanged, moved into one shared helper; the dry run writes nothing.
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.
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.
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.
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 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.
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.
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.
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.
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.
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`.
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.
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.
* 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]>
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.
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.
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.
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.
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 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.
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 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.
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.
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.
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.
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.
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.
## 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
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 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)
Extend the installed daemon-restart scenario with restarts that drop inherited TMUX/TMUX_TMPDIR and the test scaffold's forced-socket wrapper. It checks that the same two team seats, processes, sessions and bindings survive, with no new panes on the default socket and no superseded sessions.
The sequence (extended for #1906's option (a)):
- **First blind restart:** the team keeps running.
- **Second blind restart, after a real identity poll records a verdict with no pid:** the team still keeps running.
- **Recovery:** after a restart that can see the seats' server, a fresh sent marker reaches the pane.
- **Gone control:** before the kill it records the owned seat's processes (the pane shell, its child and the recorded pids) and rechecks the pane's identity. It then closes the owned pane with `tmux kill-pane`, since SIGTERM doesn't end an interactive shell. Every recorded pid must answer "No such process", and that seat must detach while the other stays running and untouched.
Scope: team seats under the existing `--no-kernel` helper; kernel duplication isn't exercised. The existing preserve/failed-backup and MCP checks stay in the same case. tmux fields use a literal `:` separator, because tmux without UTF-8 or `TMUX` renders a tab as `_`. Required result checks and negative controls cover missing or replaced seats, changed bindings, superseded sessions, duplicate panes, a retained wrapper, a changed fixture identity and a surviving process.
Validation: 23 local result tests pass (synthetic proofs; the mock renders tabs as tmux does without UTF-8, and models a surviving shell). `installed-scenario` passes in CI at this head on main with #1906 and #1907, with `daemon-restart-preserves-team-identity` PASS. Installed runs on the published baseline and candidate archives remain separate validation. No native or model calls.
An explicit rig send --dangerously-interact no longer types over text a person has already typed. Before pasting, it reads the target's composer under the existing lease and final target check, on every override path, including a broadcast that waits for idle. Typed or pasted text stops the send, and the caller is shown that text, apart from any suggestion (override_input_present). Input that can't be read stops with its reason (override_input_unknown) and is never treated as empty. An empty box, or one holding only a suggestion, types as before, and a recognised native prompt is still driven.
--type-without-checking skips the read for one send, says so, and clears nothing. To clear on purpose, use the native or tmux controls and send again; that clear happens outside OpenRig's checks and isn't recorded. Reading and pasting aren't atomic: a keystroke can land in between. The shown text goes only to the caller, never to the receipt, outbox, held messages, capture observer or audit.
Ordinary sends, notices, wakes and the guard-off default are unchanged. The openrig-user skill now teaches the stop and the deliberate clear.
A release-preparation check that changed bundled hooks and skills will reach existing installs. Managed refresh replaces installed plugin files only when the bundled version is strictly newer, so changed files at an unchanged version silently stay as they were. Run node scripts/check-packaged-plugin-versions.mjs candidate.tgz on the exact release-candidate archive: it compares the packaged plugins with the last release's (additions, removals, bytes, leaf-link targets), requires a strictly higher numeric version when anything changed, requires consumed manifests to be regular files and harness versions to agree.
The baseline is published 0.7.0's 53 plugin files. --snapshot refreshes it from a newly published archive, writing to a temporary file first so a failed run keeps the old baseline. The check isn't called from per-PR CI, so contributors don't bump plugin versions for individual edits. It runs on our own release-candidate archive and isn't hardened against a crafted one.
Docs only. cli-reference.md and openrig-user's SKILL.md now describe what 0.7.1 adds or changes, as the code does it:
- gateway human slack-subscription: set every-ask, urgent-only or unset; show prints the value and whether it's authored or the default.
- ps --nodes --json: the compact projection keeps the served needsAttention; arbitratedNeedsInput and needsInputEvidence come with --full or --fields.
- compact-plan: its flags are the plan's own thresholds, and the output shows policies.claude_compaction separately.
- The send guard at a complete, current Claude MCP approval menu: the send refuses with target_needs_input, and --dangerously-interact --reason is the only override.
- Startup attention: after a refused Claude startup turn, later inputs are held and counted; Cursor and other community-harness assisted startup is reported honestly.
The skill's MCP section also stops overstating three things: a missing or unreadable grant file is read again on every request and recovers without a restart; --owner offers every tool, not only --workspace; and several tools beyond the queue tools and rig_whoami return structured results.
Three files, +26/-5, including the skill's one digest entry. The PR body cites each change to source at the base and lists what was left unchanged and why.
Every ask to a person is on Steering and the TUI. Whether it also posts to Slack is the person's Slack subscription, the first attention subscription: a saved filter plus a destination on their gateway record (subscriptions: [{ destination: { connector: slack }, filter: { preset } }]).
- every-ask, the default: every ask posts to Slack, as on 0.7.0. Nothing changes on upgrade.
- urgent-only: only an ask marked --alert posts; the rest wait on Steering and the TUI (#1868's behaviour).
Set it with rig gateway human set <id> slack-subscription every-ask|urgent-only|unset; rig gateway human show prints it and whether it's authored or the default. --alert decides per item: a handoff doesn't inherit another ask's alert, and rig workflow route keeps a person's alert-worthy failed-step approval alert-worthy. The record's keys are closed and the preset must be a plain string, so a malformed entry is refused instead of silently quieting Slack. The skill, --alert help, the MCP text, --verify's not-alerted wording, the Feed and the Slack setup page use the subscription framing. A filter language, channel destinations and UI come later from the same record.
Mike Schwarz