A first user whose Node came from a tarball or a manual install, so it isn't on the login shell's PATH, could see Codex seats report `rig: command not found`. Preflight now runs the seat's login-shell lookup for `rig` with the declared environment, through the existing bounded probe, for Codex seats only, since their tools use a login shell. When it can't confirm `rig`, it prints an advisory warning with the fix, and launch continues. getting-started.md explains putting the Node bin directory on PATH in `~/.profile` (with Bash's profile order), and checking with `bash -lc 'command -v node rig'`. Found in Quality's 0.7.8 first-user test.
The kernel's original template now survives a daemon restart. /api/kernel/status keeps the built-in template the kernel was booted from, so rig daemon start --wait-for-kernel no longer prints variant=(none) on a lost-kernel restore, a deliberate stop, a stale kernel or a --no-kernel start. The selection is read from the rig's latest bootstrap_runs entry with source_kind rig_spec, including a partial launch, so kernels booted before this change are covered when their recorded source still matches the installation. Only the three kernel templates under the current installation's built-in specs directory are recognized. A custom project path with the same suffix, missing bootstrap history, or an old source path that can't be verified, for example after a Node version change moves the global install, reads an unknown variant, never a default. Nothing new is written: no migration, column or rig API field. The live rig spec still describes the current configuration; this value describes its origin. Reported in #21 by @tgrundtvig. Contributed by @Aschenbath.
`rig down` removes OpenRig's managed blocks from the guidance file of every seat runtime that writes one, now including Pi and omp (AGENTS.md), with the same target used for teardown, live-file protection, exact resume and node inventory. Once a working folder has no live Claude seat of any rig, down also removes OpenRig's own Claude additions there: the collector status line and the relay hook groups in .claude/settings.local.json (matched exactly as launch claims them, keeping other hooks and fields), and .openrig/context-collector.cjs when its bytes still match the shipped asset. Empty .openrig and .claude folders are removed without recursion, and settings.local.json is kept as {}. Edited, unreadable and still-shared files, including targets another live seat reaches through a symlink or hardlink, are kept and reported. An exact resume puts its activity hooks back.
Source +211/-64, tests +248/-8, docs +4/-2.
OpenRig's managed seats can now run on a tmux server of their own instead of sharing the person's default server. `rig config set terminal.tmux_server isolated` keeps them on a persistent server derived from the canonical OpenRig home, so they stop cluttering the person's own `tmux ls`. `inherit` remains the default and keeps the existing native server selection and attachment behaviour; both modes keep normal tmux configuration. The selection is made before reconciliation, and a change waits while this instance's registered seats still run on the previous server, or while that server can't be inspected; it never moves or kills a live pane. Launch, capture, inventory, terminal views and cleanup use the effective selection. Ordinary inheritance tolerates missing or invalid advisory records and gains no new identity prerequisite; strict record and identity checks apply to isolation. Fixed isolated and migration selections carry a durable pin, and an opt-out records it before removing the marker, so startup and offline cleanup agree after an interrupted update. SSH tiles follow the viewing instance's effective mode: inherited views keep `ssh -t … tmux attach`, and isolated views use the remote `rig terminal attach` and never fall back to a same-named session on the default server. The reference includes a two-instance recipe with separate homes, databases and ports.
The shared kernel dashboard's recovery steps now take the terminal's registered session name from `rig ps --nodes --rig kernel --json` (the `operator.human` row's `canonicalSessionName`), and use it in the capture and fresh-launch commands. The checks stay the same: capture the pane before concluding, launch fresh without `--stop` so a live session is never replaced, check the result before repeating, then reopen the view with `rig terminal open saved:kernel --window`. The kernel operator's guidance drops its redundant fixed session name and keeps the same lookup. Neither document hard-codes a session address any more, which package assembly refused.
The install pins on main move from `v0.7.4` to `v0.7.5`, now that 0.7.5 is published: the README's `skills add` lines, its install-script lines and the sentence naming the release, plus the same install-script lines in `docs/reference/getting-started.md` and the example tag in `docs/reference/quickstart.md`. `docs/reference/whats-new.md` stays at main's note, because it names `packages/cli`'s version. Text only.
The getting-started troubleshooting section now explains how to bring back the shared kernel dashboard when the kernel's other agents recovered but its `operator.human` terminal didn't. It shows how to find the terminal's session with `rig ps --nodes --rig kernel --json`, how to check the real pane with `rig capture`, why a stored running row alone doesn't prove the session is alive, and how a one-seat fresh launch restores the dashboard. The kernel operator's guidance says the same, so the operator agent can do it.
It doesn't claim a cause for #2201. A retained `excluded_from_subset` may predate the latest reboot, and #2201 stays open.
Thanks to @skv-io for the field report in #2201.
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.
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.
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.
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.
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.
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.
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 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.
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.
## 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.
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.
## 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)
An optional stop for two OpenRig daemons sharing one database. With daemon.db_conflict=stop, rig daemon start stops before the database opens when another running OpenRig is confirmed to hold it (an open-file holder, a matching daemon.json and listener PID), names the reason, and offers a one-start go-ahead: rig daemon start --allow-db-conflict. The default stays warn, with today's warning text; an explicitly selected database outside OPENRIG_HOME alone only warns, and an unknown holder never stops.
The go-ahead flag applies only to that start's child and isn't saved. An exported OPENRIG_ALLOW_DB_CONFLICT=1 still affects later starts from that shell, and an inherited policy value overrides the file; the docs say so. daemon.db_conflict is read at boot, and rig config set notes that.
Four protections for the seat-skills line, the one line OpenRig can add to a seat's CLAUDE.md or AGENTS.md when a person opts in with rig setup --router-line yes:
- An edit to the line is kept. rig down leaves an edited block in place and names it ("Kept 1 edited OpenRig block(s) in guidance files; remove them by hand if you don't want them:"), and a start leaves it as it is, reports the file as edited and warns seat_skills_line_edited. An unedited line is still removed by rig down, back to the file's original bytes. "Edited" is the exact bytes, ignoring only the writer's own framing (edge newlines, CRLF), so an indented line counts as an edit; down and start share that rule (managedBlockBodyMatches).
- A linked guidance file isn't written through: the start leaves the link and its target alone, reports linked with a seat_skills_line_linked warning, and starts the seat without the line.
- A resume honours the answer: rig up --existing puts the line back only with a yes, never through a link, and doesn't report the skipped line as a restore gap.
- Setup says what is actually written: "one line, plus OpenRig's markers so it can be removed cleanly", and the preview prints the exact text from the writer itself, with where it goes.
Other managed blocks behave as before; they still follow links, which many people use on purpose. Cost: source and docs about +179/-32, tests +198/-3; new outcomes linked and edited with their warnings, none refusing a launch.
Advances development main to 0.7.0 now that 0.7.0 is published, and carries its release text, the same way #1558 did for 0.6.12.
- Version fields only, 0.6.12 to 0.7.0, in the root, cli, daemon and ui package.json and package-lock.json; no dependency or script change.
- docs/reference/whats-new.md is byte-equal to v0.7.0's (tag v0.7.0, c99450f3).
- The install pins in getting-started.md and quickstart.md name v0.7.0.
This keeps main truthful about the published release while it continues toward 0.7.1; the release branch itself is unchanged.
Before anything changes, a person can see each seat's planned permissions and choose whether OpenRig adds its one router line to shared guidance files.
- rig seat status shows the native permission argument a seat's next fresh managed launch will pass, where it comes from (a seat choice, a member or rig policy, the kernel default, the team default, or the floor), what OpenRig adds (team or kernel lists, Codex writable roots, non-interruptive flags) and what isn't known (native settings OpenRig doesn't manage, whether the harness applies it, Codex's network default). A seat with no policy shows the floor it actually launches with; a Codex rebuild that carries its predecessor's permissions is named as conditional. It's labelled planned, not observed.
- rig setup previews the router line, the files it goes in and what a no gives up, and saves the answer with --router-line yes|no; a saved no stops only that line, and the environment setting still takes precedence.
This is a partial step: it covers existing seats, not a pre-launch view of a new team, and it doesn't move OpenRig's other writes, which setup now lists accurately.
A kernel seat waiting at a prompt, such as Claude's usage-limit menu, wasn't named to the person, and the operator's guidance didn't say that launch grants, team defaults or another seat's answer aren't the person's answer to a trust, hook-review or permission prompt.
Now the operator tells the person which seat is waiting, when it resets and its choices, and keeps the choices the person made during install. It answers such a prompt only when an operation the person asked for names it, or when they told it outright to decide that kind of prompt (step 10).
Cost: text only, +24/-5 (3 files). No new refusal.
Seats launched by a daemon that was started with a chosen database or a custom tmux directory could pick up a different OPENRIG_DB or TMUX_TMPDIR from the shell, so their rig commands talked to the wrong state.
Now the daemon passes the database it actually selected (resolved to an absolute path, with :memory: kept as is) and its TMUX_TMPDIR, when set, into every launched seat, across scoped launch, its fallback and shell startup. The getting-started page says so.
Cost: source +4/-1 (2 files), tests +53/-11 (4 files), docs +4/-2. No new refusal or dependency.
The daemon chose its Herdr session once, at startup, from its own environment, so someone running two rigs on one host couldn't keep their tiles apart: a per-command `HERDR_SOCKET_PATH` was ignored.
Now `rig terminal open <view> --provider herdr --session <name>` places a view in the named Herdr session on the daemon's host. Preview, status, desktop opening, workspace reuse and layout use the same selection, and each request has its own transport, so concurrent opens don't change another request's socket or the daemon's environment. Leaving out `--session` keeps the configured endpoint, and `--session default` selects it explicitly. A requested session that can't be used stops with an error instead of falling back to the default session.
Behaviour that changed, for direct HTTP requests: a rig-addressed open now checks the preview it carries, so an out-of-date preview stops the open and asks for a refresh, as the main terminal-open address already did. A `session` value is no longer ignored: an invalid name, a value that isn't text, or a provider that can't select a session (cmux) gets an error instead of opening in the old default place. The CLI also stops, rather than opening silently in the wrong place, when an older daemon can't confirm the selected session or when an in-Herdr window open would cross into another endpoint. When the caller's session is known, that error suggests the matching `--session`, named from the same socket the check used.
Limits: the selected session must already exist on the daemon's host. The tests use real sockets with synthetic Herdr peers; the Herdr desktop app wasn't exercised.
Thanks to @Aschenbath for the PR, and to @team-sudarshana for the issue and for checking the shape on their own host.
Cost: source +174/-69 (7 files), docs +105/-3 (4 files), tests +401/-6 (3 files). The two HTTP changes above were approved by the founder; two new error codes (`invalid_terminal_session`, `unsupported_terminal_session`); the rig-addressed open reuses the existing `preview_changed`.
On Ubuntu 22.04, the packaged tmux is 3.2a, which exits its whole server when asked about a pane or session that has just closed. OpenRig's seat checks could send that query when a seat's session closed, stopping every agent on that tmux server. A new entry in getting-started's restart section, beside #980's, says what happens, how to tell (`tmux -V`), and what to do: put tmux 3.4 or later first on `PATH` (for example by building a current release), then restart the daemon from a shell that sees it. It says newer versions weren't tested against this crash.
This describes released versions. #1755 stops the crashing query on main, so the entry gets a "before 0.7.1" qualifier at 0.7.1's docs refresh (recorded in that mission's notes).
Cost: docs +18/-0.
Refs #980
`rig setup` wrote `set -g history-limit 50000` into its managed tmux block. It now writes the value of a new setting, `terminal.history_limit`: default 10000, an integer from 2000 to 1000000, overridable with `OPENRIG_TERMINAL_HISTORY_LIMIT`. To keep more, run `rig config set terminal.history_limit 50000` and rerun `rig setup`. A later `history-limit` line of your own in `~/.tmux.conf` still wins.
A running tmux server keeps its old limit until it restarts or you run `tmux source-file ~/.tmux.conf`; before tmux 3.7 that changes new panes only. `rig setup --help`, `rig config --help` and getting-started say so.
At 10000 rows an attached pane and the TUI terminal view keep less scrollback than at 50000, and `rig capture --lines N` reads up to that depth. Transcripts at the default `transcripts.lines` of 1000 are unaffected. The setting appears in the settings API, `rig config` and the TUI's settings view.
Daemon start restores a managed kernel whose terminals were lost (for example after a reboot), while deliberate stops stay stopped.
- **Startup:** a kernel whose seats are all detached and still bound to their newest sessions is restored in the background through the same snapshot selection and restore pipeline as `rig up kernel --existing`. Live, partly stopped, unclaimed and otherwise indeterminate kernels are left alone, and `OPENRIG_NO_KERNEL=1` stays authoritative. Other rigs keep their explicit start behaviour.
- **Status and `rig start`:** kernel status tells a restore in progress from one that finished and derives readiness from the seats actually running. `rig start` carries on with other rigs while the kernel restores, and exits unsuccessfully with a recovery command if the restore finished without a ready kernel.
- **A stop wins:** `rig down kernel` during the startup restore waits, then stops what the attempt left, keeping the deliberate-stop record. An explicit `rig down` of any rig whose tmux server is gone starts an empty server and probes again, and records the stop and clears the binding only when the session is positively absent; it may leave an empty tmux server running and never launches an agent.
- **Joining:** an equivalent explicit `up`, including one that repeats the saved non-interruptive choice, joins the automatic attempt during or after it while its launched occupants still hold their seats, rechecked after every wait. The Explorer up route shares this.
- **Explicit overrides:** `up --fresh <seats>` replaces only the named seats still held by startup's sessions; after an operator corrects a seat's conversation target, an explicit `up` or `restore` replaces that seat; a different non-interruptive choice after startup launched agents is refused, explaining that the rig must be stopped and the command rerun.
Built and carried through five review rounds by @haralez.
New agents no longer pick up unrelated values stored in the tmux server's global environment.
- **Default:** new managed agents and handover successors start from the daemon-selected launch environment plus the seat's declared values. Values named by tmux's `update-environment` list (SSH agent and display defaults included) are kept from the daemon; stored server values aren't copied. Generated pane identity and the selected auth and endpoint forwarding are kept.
- **Opt back in:** `terminal.inherit_tmux_environment=true` (default `false`) restores inheritance for setups that rely on server globals. Setup gives informational advice when it detects a custom tmux configuration, without changing the setting.
- **Unchanged:** shell startup and custom default commands still run; running agents and server globals are left alone; existing-command restarts without a new seat environment behave as before.
- **If preparation fails** (Windows, or shell or option inspection unavailable), the previous launch environment is kept with a warning in fresh launch results and the daemon log. It never refuses a launch.
Refs #1178.
Two fixes from first-user runs.
- **Node.js on a standard-user Mac:** the quickstart's "What you need" now gives the nvm route with its commands (`touch ~/.zshrc`, nvm v0.40.8's install line, a new terminal, then `nvm install 22`), with no administrator password for nvm itself, and says to run `xcode-select --install` if nvm's installer asks for Apple's command line tools. The README and getting-started name the same command.
- **Shell blocks that paste cleanly:** a trailing `# …` note in a shell block becomes arguments to the command in a Mac's default zsh, so those notes in the quickstart and README now sit in the sentence before their block.
- **No sandbox-only paths for the person:** the rigs skill (both copies) says that a file or command given to the person for their own terminal uses a path that exists on their side; a file a sandboxed agent writes under `/tmp` may not.
On a Mac with more than one user account, a second user's `rig` commands can reach the first user's daemon on its default port. This adds an optional check, off by default.
- **The setting:** `transport.local_user_guard` (default `false`). When it's on, the CLI's common client checks a local daemon before talking to it.
- **The evidence:** the daemon's `/healthz` now reports its own effective UID as `euid`, beside `pid`. The check reads it twice and corroborates it with `ps -o uid=,lstart= -p <pid>` twice (fixed path, no shell, bounded to 1 s).
- **When it refuses:** only when every read agrees on a UID different from the caller's effective UID. The error names the reported PID and UIDs, and the way out: `rig daemon start --port <unused-port>`, or a deliberate `OPENRIG_URL`.
- **When it permits:** an older daemon with no `euid`, malformed, changing or disagreeing reports, `ps` failing or timing out, a non-loopback URL, or a non-Mac platform all read as unknown and let the call through. A same-user daemon never refuses.
- **What it isn't:** it trusts the daemon's report and corroborates that process; it doesn't prove who owns the socket. It's a partial check against accidental routing, not authentication or user isolation, and identity can change between the check and the connection. Running `sudo rig …` against a user-owned daemon refuses when the guard is on.
With the guard off, kernel readiness resolves the setting once before its wait and keeps the same polling and final status request as before. Each request still reads the setting once. `/healthz` gains the additive `euid` field whether the guard is on or off.
Hosted Mac checks observed an owned listener reporting its UID and an unprivileged `ps` read of another account's process. A live two-account daemon session wasn't run.
Onboarding docs: let your coding agent set OpenRig up, and say plainly what installing changes.
- **New `docs/reference/quickstart.md`:** the human getting-started page, with a short glossary of the first words a person meets.
- **`docs/reference/getting-started.md`:** a new title and opening for the agent doing the setup; the rest of the page, and every inbound link and `rig context get` lookup into it, is unchanged.
- **README:** the skill-first install block opens "Install and first run", followed by "Install it yourself"; a short box says what installing and starting change on the machine; the Getting started links point to the new page, and Key Concepts links to the glossary.
- **Facts kept current:** the example tags and version sample now match the v0.6.12 install pin.
- **`scripts/check-first-run-references.mjs`:** the first-run references check now also covers the new page.
Docs only; no product behaviour changes.
Development main now carries the published 0.6.12's versions and release text.
- **Versions:** root, `packages/cli`, `packages/daemon` and `packages/ui` read 0.6.12, and the lockfile matches; `packages/tui` stays 0.1.0.
- **Release text:** the 0.6.12 CHANGELOG section and whats-new entry as published, and `docs/releases/v0.6.12.md`, the published release notes byte for byte.
- **Capability map:** 0.6.12's additions (for example `rig seat set-effort` and `rig usage cost`) alongside main's later entries (`rig seat set-cwd`, the adopted-seat restart note, Pi effort and `rig usage top`).
- **Installer pins:** the README and getting-started now name `v0.6.12`, keeping the standard-user Mac Node route.
The release's two text and version commits are cherry-picked with `-x`; this isn't a merge of `release/0.6.12`, whose source changes main already has whole.
Two fixes from a first-user run on a Mac with fresh accounts.
- **Node.js for a standard Mac user:** someone who isn't an administrator, or whose Homebrew belongs to another account, can install Node.js in their own home folder with nvm. They run `touch ~/.zshrc` first, because a new Mac account has none and nvm's installer only adds itself to a profile file that already exists. Then they run nvm's install command, open a new terminal, and run `nvm install 22`. No administrator password is needed, and `npm install -g` then installs into the nvm folder. This is in `docs/reference/getting-started.md` and the README. Nothing is claimed about Node.js's own installer for a standard user.
- **What the registry checks decide:** `docs/reference/publishing-a-rig-bundle.md` now says that a submission with a taken name is still received, that a team sharing a listed team's `rig.yaml` name (such as an unchanged copy) passes with a maintainer notice, and that listing is the maintainer's review decision, not the checks'. Registry policy is unchanged.
Text only. The registry wording was read against `tools/registry-check.mjs` and `tools/ci/bundle-check.mjs` at the registry's main.
Four onboarding facts that had drifted, corrected in place. Text only, with no change to the onboarding path.
- The install script pin moves from `v0.6.8` to `v0.6.11`, the newest published release, in `README.md` and `docs/reference/getting-started.md`. Nothing moves these pins automatically.
- The `rigs` skill's footer drops "Written for OpenRig 0.6.7." and keeps the rule that `rig <command> --help` wins when it disagrees with the skill. Both copies stay byte-identical.
- The README and getting-started prerequisites now say one working Claude Code or Codex account is enough: `rig setup --providers` takes either, and the kernel operator adapts the shipped `starter` team to whichever the person has.
- The skill's disclosure of what starting OpenRig and a team writes now names Claude Code workspace trust in `~/.claude.json`, the activity hooks in `.claude/settings.local.json` and a status line there unless the project already has its own. It also says that, unless a permission policy, a per-seat choice or (for Codex) a named profile applies, the kernel's own seats run with an operational default: Codex with `-s danger-full-access -a never`, and Claude Code with its file tools, web fetches and operational commands, including reads under the home folder, allowed without asking.
`npm run test:repo` (docs guard, first-run references, skill mirrors, context packs) and the packaged-skill identity test pass.
From the shared TUI (`rig tui --shared`) viewed in a Herdr pane, opening a seat's terminal printed `Unrecognised or unavailable hosting terminal: "unknown"` and opened nothing. On Linux it now opens the view in the Herdr of the tmux client that was active last, which is normally the person looking at it.
The TUI runs in the daemon's tmux server, so the person's Herdr markers sit on their tmux client and never reached it. When the TUI isn't itself in Herdr, `open-window.ts` lists the clients attached to its tmux session. If exactly one interactive client was active last, it reads only `TERM_PROGRAM` and the `HERDR_*` markers from that client's environment and passes them to the `rig terminal open --window` child in place of its own.
- Last active is a hint, not the sender of the key: it can belong to a different viewer, and input sent with `send-keys` or by a control-mode client marks no client active. The docs and the code comment say so.
- Every case without a single last-active Herdr client keeps today's result: no client, a tie in the same second, an unreadable or non-Herdr newest client (an older client is never used instead), control-mode clients, and macOS and other platforms. A newest client in a different Herdr session gets the existing endpoint refusal. There's no new refusal or message.
- The CLI is unchanged, so ordinary `rig terminal open` callers keep their environment and desktop-terminal choice.
Tests cover the real read path against a tmux shim and Herdr-marked processes, including ties, unreadable and non-Herdr newest clients, control-mode clients and a failing tmux. `docs/reference/getting-started.md` describes the behaviour.
The getting-started guide now has a short "Built by the community" list, after the section on viewing your team. Its first entry is Rig HQ by dmelo, a read-only pixel-office viewer for rigs, seats, attention and queue handoffs, which its author reports testing with OpenRig 0.6.5.
The list says that these tools are maintained by their authors, that we haven't tested them, and that it doesn't promise support or compatibility with your OpenRig version. Setup and support questions go to each tool's repository.
A seat can now opt into a draft-aware typing guard: `rig seat set-typing-guard <seat> --mode draft-aware`. Every seat stays off by default. In this mode, automatic input checks the seat's input box just before typing and again before Enter. A seat with an unsubmitted draft isn't typed over: the delivery is held or refused with its reason, and nothing is retried automatically. `hold` keeps its current behaviour, and the legacy on/off setting maps to hold or off.
This re-lands Nash Aschenbath's reviewed work from #1072 on current main, with commits also from Mr-Neutr0n (whose commits carry the name Harikrishna KP). The original commits, with their authorship, stay on this pull request's branch and in #1072. The squash adds a merge of main with its conflict choices, a helper rename that merge needed, test updates, and one follow-up: a draft-aware seat now skips the idle wait outside the seat's lease, as a hold-mode seat already does, so a draft or an unreadable input gets its immediate result.
Limits that ship with it:
- Off by default isn't inert. Migration 100 and the shared transport and startup changes apply to every seat.
- In draft-aware mode, an empty input waits for idle inside the seat's lease, which can delay other work for the same seat. The empty-input test starts from an idle seat, so lease occupancy during a long busy wait wasn't measured.
- Turning draft-aware off between the input snapshot and the lease can still take that in-lease wait. This was read from source, not exercised.
- The gap between the last observation of the input box and typing remains. There's no guarantee against text a person types at that moment, and no automatic retry or replay of uncertain input.
- Native harness behaviour isn't newly proved here. The evidence is in-process tests and CI.
Refs #1072
Co-authored-by: Nash Aschenbath <[email protected]>
Co-authored-by: Harikrishna KP <[email protected]>
Co-authored-by: Mr-Neutr0n <[email protected]>
Getting-started now gives explicit Claude Code and Codex commands for reading the `rigs` skill, pinned to the release tag that matches the installed `rig --version`, so the skill isn't silently taken from main and the agent isn't left unspecified.
- `rig --version` prints the version and a commit, for example `0.6.11 (379f0a0d)`; the tag is `v0.6.11`.
- The skill is in the repository from v0.6.6; an older install uses that tag or upgrades first.
- One Linux prerequisite line links the recorded bubblewrap loopback error to OpenAI's sandbox prerequisites, and leaves AppArmor changes to the machine's owner.
Documentation only: no preflight, configuration or command changes.
Keep watching a Claude resume that is still starting.
- When a restored Claude seat hasn't drawn its screen at the end of the unchanged 3.2 s quick window and the boot is still in progress, the Claude adapter keeps polling for the rest of `runtime.readiness_timeout_seconds` (30 s by default, 1 to 600), as the Codex adapter does.
- Claude's screen appears: the seat is `resumed`. It doesn't: the seat ends `attention_required` ("Claude resume did not finish within Ns; Claude may still be starting, so the launch was kept"), with the pane kept and the attempted resume token recorded as an attempt, not certified. It is never `resumed` because a process is alive.
- Only a boot in progress extends the wait. A real gate (login, trust, MCP approval, unproven auto-mode identity), a missing conversation and a resume-selection prompt keep their results. A different occupant (another conversation's Claude, a stable Codex, or a ready-looking screen whose lineage failed the check) keeps today's `failed` result, checked at the window's end, about once a second during the longer wait, and once more at its end.
- At settings of 1, 2 or 3 s no extra polls fit, but an unresolved boot still ends `attention_required` rather than the ordinary token-losing failure.
- With provider-prompt auto-driving on (off by default), a trust prompt during the longer wait gets Enter only when the occupant check shows this launch's own Claude.
- With #1417 on main, a screen showing only Claude's "Not logged in · Run /login" footer is no longer a login gate; during a slow resume it now waits the readiness bound like any boot in progress and, if unresolved, ends `attention_required` with the attempted token kept, where main ends "timed out". A current login refusal still stops early and fails as before.
What it costs:
- The bound is the existing readiness setting, so raising it for slow fresh launches also lengthens this wait. It counts polls from the adapter's verification, not from the launch, so read it as about the setting, not a wall-clock promise (about 31 s a seat at the default in the author's live run).
- Restore starts seats one after another, so the cost adds up per seat that never starts Claude (about 95 s for three at the default, measured by the author; an illustration, not a limit).
- `rig up` and `rig launch` wait 120 s for the daemon, so a few stuck seats can pass it. A client timeout with exit 1 is not a rollback: check `rig ps` before running the command again. The two commands word that timeout differently.
- The later readiness wait (`waitForReady`) runs only after the adapter succeeds; its first check runs straight away, so it adds no backoff sleep when that first check reads ready.
- During the longer wait, the shell and occupant checks run about once a second (about 80 process listings over a 30 s bound), plus the quick window's two tmux reads per extra poll.
Not in this change: Claude's screen recognition (#86 stays open); the older `adapters/claude-resume.ts`; any other runtime.
For #1351.
Say how to add a newline when Shift+Enter submits in a Claude Code seat.
- One row in the getting-started table of what can interrupt the OpenRig view: whether Shift+Enter reaches Claude Code as its own key depends on the terminal and on tmux's extended-key support and settings.
- To add a newline anyway, press Ctrl+J, or type `\` and then press Enter. The row links Claude Code's tmux configuration guide and the tmux manual's `extended-keys` and `terminal-features` entries.
- It changes no tmux option, configuration or launch behaviour.
Refs #1394.
`rig policy apply <policy> --seat <seat>` now changes an existing seat's stored permission policy without re-creating the seat. It records the new policy, its provenance and a `node.policy_changed` audit event in one transaction; the running process and the rig spec file are unchanged.
Restore, resume and launches that read the seat's stored state use the stored policy, unless an explicit native selection (`rig seat set-permissions`) takes precedence. `rig up` by a saved rig name uses it; a launch from a spec that declares a policy replaces it with the spec's policy, which later restores then use. `--seat none` sets an explicit floor for that seat and doesn't inherit the rig's policy. Afterwards, a `rig launch --retry-startup-from` file has to carry the new policy.
`--seat` accepts the built-in policies and `none`, and an ambiguous seat name is refused without a change.
When the daemon runs inside tmux on a non-default socket, the attach commands OpenRig prints name that tmux server, taken from the daemon's own TMUX, so they reach the sessions instead of reporting no sessions. With no TMUX, commands are unchanged.
Four first-hour fixes from a first install on a fresh Mac. rig setup --providers claude|codex|both leaves an unchosen provider uninstalled and reports it Not selected; a chosen provider's failure still fails, and setup without the option is unchanged. A first rig daemon start no longer prints tmux's "error connecting" line. Setup's next steps say starting OpenRig and handing the person to the operator are part of the install. The operator's first copy no longer stops for an approval prompt.
Getting started covers kernel seats that all fail at the first start on a tmux whose server exits on capture-pane: a throwaway-socket check, the reporter's recovery when no kernel seat is still running, and why a later start doesn't retry them. Refs #980.
After install the agent opens the OpenRig TUI and operator as the handoff, sized to the person's terminal (operator alone under 120 columns, 50/50 from 120, an openrig kernel space inside Herdr), reusing a space only under its own name with live attached panes. Supersedes #989, #990 and #992.
Mike Schwarz