@openrig/cli 0.6.14 → 0.7.0

package/daemon/assets/skills/rigs/SKILL.md

@@ -14,7 +14,8 @@ if the person asks you to. When they say what they want built, give it to OpenRi
 building it yourself.
 
 Tell the person what you're about to run and why before you run it. Don't install system packages or change their
-machine without a yes. Starting OpenRig and a team writes files: Codex hooks and settings in
+machine without a yes, and don't start a team, including `rig up`, without their yes to what it will start; a yes they
+already gave for that same launch counts, so don't ask twice. Starting OpenRig and a team writes files: Codex hooks and settings in
 `~/.codex/config.toml`, Claude Code workspace trust in `~/.claude.json`, discovery skills in `~/.claude/skills` and
 `~/.agents/skills`, and, in the repository, managed guidance in `AGENTS.md` or `CLAUDE.md`, activity hooks in
 `.claude/settings.local.json` and a status line there unless the project already has its own, plus the team's skills
@@ -23,6 +24,10 @@ seats run with an operational default: Codex with `-s danger-full-access -a neve
 tools, web fetches and operational commands, including reads under the home folder, allowed without asking. Say so
 before you start OpenRig ([the full list](https://github.com/mvschwarz/openrig#what-openrig-changes-on-your-machine)).
 
+When you give the person a file or a command to run in their own terminal, use a path that exists on their side. A
+file a sandboxed agent writes under `/tmp` may not exist in the person's terminal (seen with Codex), so put files the
+person needs in their project or home folder and name that path.
+
 ## 1. Install OpenRig, if it isn't installed
 
 - **Check first:** `rig --version`. If it prints a version, go to step 2.
@@ -106,13 +111,18 @@ before you start OpenRig ([the full list](https://github.com/mvschwarz/openrig#w
   `--node <logicalId>` binds to an existing seat instead. Attach once, and keep the variables it prints
   (`OPENRIG_NODE_ID` and `OPENRIG_SESSION_NAME`). Each command may run in a fresh shell, so put them in front of every
   later `rig` command. Check with `rig whoami --json`.
+  If they decline, a message that must still say who it's from can go as a queue item with a declared source,
+  `rig queue create --source <their id>@external --destination <seat> --summary "<one line>" --body-file <file>`: the
+  seat sees that name, recorded as declared, and can reply to them if they're registered (`rig gateway human list`).
+  A declared name is a claim, not a seat's own identity: for a team that acts only on seat identity, the attached
+  shell above is the route.
 - **Give the operator the goal:** ask what they want worked on, in which repository and on which branch, unless they've
   said. Find the `operator.agent` row in `rig ps --nodes --rig kernel --json`, take its `canonicalSessionName`
   (never the logical ID or a guessed name) and send:
   `rig send <canonicalSessionName> 'This is the agent that installed OpenRig. The person will answer in your pane. Goal: <goal>. Project folder: <absolute path>. Branch: <branch>.'`
   Or the person types the goal and folder in the operator's pane. If they give you a goal later, forward it the same
-  way. The operator helps them pick a team that fits their logins, starts it on their yes and gives the goal to the
-  team's lead. Before that yes, it says what launching into their folder changes for their own agent there; relay
+  way. The operator helps them pick a team that fits their logins, starts it (`rig up`) only on their yes to the plan it
+  shows, and gives the goal to the team's lead. Before that yes, it says what launching into their folder changes for their own agent there; relay
   that with the question. Show them where the operator answers, and don't build the project yourself.
 - **Relay the operator's questions:** the operator asks in its own pane, and the person may not be looking there.
   After each step you hand it, read its screen with `rig capture <canonicalSessionName>`. When it asks the person
@@ -125,8 +135,17 @@ before you start OpenRig ([the full list](https://github.com/mvschwarz/openrig#w
 - **See what's running:** `rig ps`, then `rig ps --nodes --rig <rig>` for a team's agents. If a team is already
   running in that repository, tell the operator.
 - **Check it's ready before you say so:** `rig ps --nodes --rig <rig>`. If an agent is stopped at a prompt or a menu,
-  read it with `rig capture <seat>@<rig>` and answer with the key that screen shows (`rig send --help` says how to
-  send a digit, a letter or Escape), or ask the person. Capture it again before sending anything more.
+  read it with `rig capture <seat>@<rig>`. A permission prompt is the person's to answer: show it to them, with any
+  others waiting, one line each (seat, exact action, the choices offered). Before sending their choice, capture that
+  seat again: if its prompt changed, don't reuse the answer. Then send exactly the choice they made for that prompt
+  (`rig send --help` says how to send a digit, a letter or Escape to a prompt). A yes to one prompt isn't a
+  yes to the next, and never pick a "don't ask again" choice they didn't pick. If they've told you outright to decide a
+  kind of future prompt (say, "approve prompts that only write inside my project"), you may decide each one: read its
+  whole action, answer only when it's clearly inside what they said, and tell them you answered under that instruction,
+  not that they said yes. Bring anything unclear or outside it back to them; a command's name or a path that looks like
+  their project doesn't show what the action touches. Their instruction changes no permission setting.
+  Another kind of menu you can answer with
+  the key that screen shows, or ask the person. Capture it again before sending anything more.
 - **Replies:** in a plain shell, other agents can't type into this session. Read work sent to you with
   `rig queue list --destination <your address>` and `rig queue show <id> --full`, and read an agent's screen with
   `rig capture <seat>@<rig>`.

package/daemon/context-packs/help/manifest.yaml

@@ -1,6 +1,6 @@
 # Agent help: the single troubleshooting and escalation guide (docs/reference/help.md).
 name: help
-version: "0.6.14"
+version: "0.7.0"
 taxonomy: world
 purpose: "What an agent does when its user says OpenRig isn't working: diagnose, fix within permissions, verify, and escalate to OpenRig support."
 files:

package/daemon/context-packs/onboarding-width/manifest.yaml

@@ -1,6 +1,6 @@
 # Public capability and source-map width for the default onboarding walk.
 name: onboarding-width
-version: "0.6.14"
+version: "0.7.0"
 taxonomy: world
 purpose: "The public capability map and source map referenced by the default onboarding walk."
 files:

package/daemon/context-packs/onboarding-width/public-what-you-can-do.md

@@ -464,9 +464,9 @@ not have to tear one down to change it, and you rarely have to start from nothin
   the system see the live process **without launching anything**. A running seat that refuses every
   send because its tmux pane was never recorded (one launched by an older OpenRig) takes
   `rig reconcile-session <seat> --repair-missing-pane --no-launch`: it fills only the missing pane,
-  keeps the session and resume token, never adopts, and refuses while typing protection is on.
-  Plain reconcile adopts the seat into a new session without its resume token; use the repair even
-  where a protected seat's compaction refusal still suggests plain reconcile.
+  keeps the session and resume token, and never adopts. Plain reconcile adopts: a new session row
+  (any running row for the seat is superseded); it re-captures the resume token if it can, and
+  conversation continuity stays unverified. Both refuse while typing protection is on.
 - **`rig unclaim` / `rig release`** — stop managing one adopted session, or all of them,
   **without killing the process or the agent inside it**. Handing something back to its human is a
   first-class move, not an abandonment.
@@ -926,9 +926,7 @@ your circumstances is configuration, and the ones that are not, another agent ca
   better than `unknown`. A Codex account's last reading, its reset and its last observed exhaustion
   survive a daemon restart as history (`retained: "before_restart"`), never a current reading; a
   window whose reset has passed shows an `expectation`, which is planning, not a reading. Run `rig provider status --refresh`
-  before telling anyone an account has room. With `provider.subscription_moves`
-  on (off by default), `rig provider moves` records and lists moves of a Codex home's seats between
-  subscriptions.
+  before telling anyone an account has room.
 - **Codex configuration fragments** — a `codex_config_fragment` must open with a table header and
   never overrides a user-declared table; see `docs/reference/agent-spec.md`.
 - **`rig env`** — the real services behind a rig: are they up, what are they saying, how do you

package/daemon/context-packs/reference/getting-started.md

@@ -72,12 +72,16 @@ you aren't an administrator, or where Homebrew belongs to another account (its
 `brew install` is refused), install Node.js in your own home folder with
 [nvm](https://github.com/nvm-sh/nvm): run `touch ~/.zshrc` (a new Mac account
 has none, and nvm's installer only adds itself to a profile file that already
-exists), then the install command on nvm's page, open a new terminal, and run
-`nvm install 22`. That needs no administrator password, and `npm install -g`
-then installs into your nvm folder. Native
-Windows isn't supported. On Windows, use WSL2: it's the Windows route OpenRig
-supports, though OpenRig's automated tests don't run on it yet. One user's
-[working setup](#wsl2-a-reported-working-setup) is below. Node 20 and
+exists), then nvm's install command, for nvm v0.40.8
+`curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh | bash`
+([nvm's page](https://github.com/nvm-sh/nvm#install--update-script) has the
+newest), open a new terminal, and run `nvm install 22`. nvm itself needs no
+administrator password, and `npm install -g` then installs into your nvm folder.
+If nvm's installer says you need Apple's command line tools, run
+`xcode-select --install`, then its install command again. Native Windows isn't
+supported. On Windows, use WSL2: it's the Windows route
+OpenRig supports, though OpenRig's automated tests don't run on it yet. One
+user's [working setup](#wsl2-a-reported-working-setup) is below. Node 20 and
 odd-numbered releases (23, 25 and so on) are not supported; Node 26 and later
 even-numbered releases are untested.
 
@@ -177,20 +181,19 @@ You can also read [`skills/rigs/SKILL.md`](../../skills/rigs/SKILL.md) directly.
 script will do and changes nothing:
 
 ```sh
-curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.6.14/scripts/install.sh | sh -s -- --dry-run
+curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.7.0/scripts/install.sh | sh -s -- --dry-run
 ```
 
 The same command without `--dry-run`,
-`curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.6.14/scripts/install.sh | sh`, installs the
+`curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.7.0/scripts/install.sh | sh`, installs the
 latest published `@openrig/cli` with `npm install -g`,
 runs the Node.js and SQLite check, then `rig setup --dry-run` and `rig setup`. `rig setup` checks both Claude Code and
-Codex and may install a missing one, as described below. A failed step among the first three prints
-`FAILED [n/4] <command or check> (exit <code>)`. When `rig setup` (step 4) doesn't finish ready, for example because a
-provider isn't signed in yet, the script ends with `INSTALLED, SETUP NOT COMPLETE (exit <code>)`: the CLI is
-installed, and `rig setup` lists what's left under "Some steps need attention". If the only items left are provider
-sign-ins, sign in to each selected provider as below, then continue at
-[Start the kernel](#start-the-kernel-and-check-its-state); run `rig setup` again rather than reinstalling the CLI. To
-install only what the selected providers need, go step by step instead:
+Codex and may install a missing one, as described below. A failed step prints
+`FAILED [n/4] <command or check> (exit <code>)`. Where a provider isn't signed in yet, step 4 ends that way and
+`rig setup` lists each sign-in under "Some steps need attention". If the only remaining failures are provider
+sign-ins, the install steps finished: sign in to each selected provider as below, then continue at
+[Start the kernel](#start-the-kernel-and-check-its-state). To install only what the selected providers need, go step
+by step instead:
 
 ### Choose your providers
 
@@ -220,6 +223,26 @@ writes an OpenRig-managed block (mouse on, a longer history) into `~/.tmux.conf`
 It is optional for this selected-provider path, not a requirement to fix an unused
 provider.
 
+The block keeps `terminal.history_limit` rows of scrollback per pane (default
+10000). To keep more, run `rig config set terminal.history_limit 50000`, then
+`rig setup` again. 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.
+
+New managed agents and handover successors on macOS/Linux start from the daemon's
+selected launch environment and declared seat values, rather than stored tmux globals.
+Values named by tmux's `update-environment` option, including its default SSH-agent
+and display variables, come from the daemon's environment.
+Normal shell startup and configured tmux shell commands still run. If your custom setup
+intentionally supplies values through tmux's global environment, opt in with
+`rig config set terminal.inherit_tmux_environment true`. Setup points out this option
+when it detects custom tmux configuration; it never enables it automatically. The setting
+applies to future launches and successors, not running agents or your personal tmux server.
+If the scoped environment cannot be prepared, launch keeps its previous environment and
+reports a warning in fresh launch results and the daemon log. For handovers, check
+that log for this warning. This is not a promise that shell startup cannot add or override values.
+
+
 ## Start the kernel and check its state
 
 With a working selected login, start the daemon if it is stopped, then read its
@@ -251,9 +274,51 @@ A missing or unknown readiness signal is not proof of readiness. Follow
 startup or missing-seat problems.
 
 `rig setup` itself does not start the daemon. Preserve a daemon and kernel that
-already exist: ordinary daemon startup skips a managed kernel, and
-`OPENRIG_NO_KERNEL=1` skips automatic kernel startup. If neither runtime is
-authenticated, kernel boot reports `auth_blocked`. Do not restart or recreate an
+already exist: daemon startup does not boot a second kernel when one is managed,
+and `OPENRIG_NO_KERNEL=1` (`--no-kernel`) skips automatic kernel startup,
+including the restore below. If neither runtime is authenticated, kernel boot
+reports `auth_blocked`.
+
+Daemon startup restores one existing kernel by itself: a managed kernel whose
+seats are all `detached` and still bound to their newest session, which is what
+startup reconcile leaves when every kernel terminal is gone, for example after a
+reboot. It does not detect a reboot as such. It uses the same restore as
+`rig up kernel --existing`, and `rig status` reports it as `Kernel: booting`
+until the seats are ready. A kernel stopped with `rig down kernel`, including
+one whose seats were already detached, stays down on later starts. So do a kernel
+with only some seats stopped and seats you unclaimed. Start one again with
+`rig up kernel --existing`.
+When the tmux server is gone, an explicit `rig down` of any rig can start an
+empty server and probe again. It records the stop and clears eligible bindings
+only after confirming the sessions are absent. This can leave an empty tmux
+server running; it never launches an agent or provider session. Unreadable or
+permission results and changed occupants leave the stop bookkeeping unchanged.
+
+While that automatic restore runs, `rig start` continues to your other rigs and
+says the kernel is still restoring (`kernelRestore.state: "restoring"` with
+`--json`). Its exit status 0 then does not mean the kernel is ready; check
+`rig status`. When the restore has returned without a ready kernel, `rig start`
+still goes on to your other rigs but exits 1 (`kernelRestore.state: "failed"`),
+so `rig start && next` does not run `next`. A `rig down kernel` made during the
+restore waits for it to return and then stops the kernel, which stays down on
+later starts. A `rig up kernel --existing` with no fresh seats and no change to
+the saved non-interruptive choice, made during the restore, or after it restored
+every seat while those seats still run the sessions it started, reports that
+restore's outcome instead of starting another. Explicitly repeating the saved
+`--non-interruptive` or `--no-non-interruptive` choice also joins that restore.
+
+An explicit `rig up kernel --existing --fresh <seat...>` waits for startup's
+restore to finish, then replaces only the named seats that still hold the exact
+sessions startup launched. Other seats keep running. An operator's conversation
+correction also takes effect for that seat on the next explicit `up` or
+`restore`, using the corrected target; editing the token alone restarts nothing.
+Each replacement takes new seat leases, rechecks the managed occupant and terminal,
+and reports its own per-seat outcome. If the occupant changed, it is left alone.
+A different `--non-interruptive` or `--no-non-interruptive` choice after startup
+launched the seats is refused: the running launch choice stays unchanged. Stop
+the rig, then rerun with the desired choice.
+
+Do not restart or recreate an
 existing kernel merely to open its view. The startup TUI (`rig`) offers its own
 kernel setup and individual-seat recovery; it does not automatically boot agents
 when it starts the daemon.
@@ -690,7 +755,7 @@ the lifecycle API without booting a new kernel, then stop the remaining rigs.
 | Shared terminal is absent | Inspect the existing kernel binding and recovery state; use standalone `rig tui` while resolving it. |
 | Viewing terminal was closed | Open the conversations again with `rig terminal open saved:kernel --window`; `rig tui --shared` is only the dashboard fallback if that window cannot open. Do not relaunch the team. |
 | Daemon restarted but tmux survived | Re-read `rig status` and the existing queue; a daemon restart is not a fresh project. |
-| Host reboot lost tmux sessions | Open `rig`, start the daemon if needed (press **S** if it opens on the work views), and select the existing rig and seats. Resume is the default; a fresh conversation needs a separate decision. |
+| Host reboot lost tmux sessions | Starting the daemon restores the kernel by itself when all of its seats were lost; check `rig status`, and if it reports the restore failed, run `rig up kernel --existing`. For other rigs, open `rig`, start the daemon if needed (press **S** if it opens on the work views), and select the existing rig and seats. Resume is the default; a fresh conversation needs a separate decision. |
 | Launch reports no usable snapshot | Inspect the existing rig and retained project files, then follow the same-seat recovery below. |
 | Work is waiting on a prompt or decision | Read the row, transition and named prompt; preserve the obligation until the missing decision arrives. |
 
@@ -721,8 +786,9 @@ This recovery is for the case the reporter hit: the kernel's seats failed and no
 IDs, for example `advisor.lead operator.agent operator.human queue.worker` when all four failed. `--fresh` starts a
 new conversation for each seat you name. Seats you don't name follow their normal recovery policy and may remain
 awaiting a decision if their old conversation can't be resumed. A later `rig daemon start` doesn't retry the failed
-seats by itself: once a kernel exists, startup skips the built-in kernel boot, and `rig status` then reads
-`Kernel: skipped` whatever its seats' state, so check `rig ps --nodes --rig kernel --full`.
+seats by itself: once a kernel exists, startup skips the built-in kernel boot and restores only a kernel whose seats
+were all lost, not seats that failed. `rig status` then reads `Kernel: skipped` unless some of its seats are running
+and ready, so check `rig ps --nodes --rig kernel --full`.
 
 If a snapshot is unavailable, the startup view checks the selected seat's
 retained startup source and authoritative occupant relation. It reports a

package/daemon/context-packs/reference/manifest.yaml

@@ -1,7 +1,7 @@
 # Reference guides the help pack links to, loaded one file or section at a time by address
 # (rig context get reference/<file>#<section>). Each file is a symlink to docs/reference/.
 name: reference
-version: "0.6.14"
+version: "0.7.0"
 taxonomy: world
 purpose: "Version-matched reference guides the help guide links to. Load a single file or section by address; don't load the whole pack."
 files:

package/daemon/context-packs/reference/rig-spec.md

@@ -354,7 +354,7 @@ pods:
 
 - A seat gets the rig's `env` with its own `env` laid over it, name by name.
 - The same environment is applied on first launch, on `rig up <rig-name>` restore, and to the successor of a seat handover.
-- `rig up <spec> --env KEY=VALUE` (repeatable) adds or overrides a value for one launch. A one-off value belongs to the terminal that launch creates: it stays in that terminal's environment for as long as the terminal lives, and OpenRig removes it from the tmux session's environment as soon as the terminal has started, so a terminal started later in that session does not get it. A restore, a handover successor or any later launch starts from the spec's `env:` alone, so the value is not saved and does not carry forward. To keep a value, put it in `env:`. One exception to "does not carry forward", for a managed Claude seat (see below): a one-off name that the seat's spec does not declare stays on the session's list of names, `OPENRIG_SEAT_ENV_KEYS` (names only, no values), because the first launch and an in-place restart of the same terminal read that list. So if a later pane in that session gets a value for that name from the tmux server's own environment, its managed Claude launch can forward that value, where a launch without `--env` would leave it out. The first launch's one-off value itself is not passed on to that pane. This comes from reading the code and has not been measured. `--env` does not apply to `rig up <rig-name>` (a restore) or to a topology (several rigs from their own specs); the CLI refuses both. For a topology, put `env:` in each rig's spec.
+- `rig up <spec> --env KEY=VALUE` (repeatable) adds or overrides a value for one launch. A one-off value belongs to the terminal that launch creates: it stays in that terminal's environment for as long as the terminal lives, and OpenRig removes it from the tmux session's environment as soon as the terminal has started, so a terminal started later in that session does not get it. If OpenRig can't take it out, the seat keeps running and the launch warns, naming the variable and the tmux command to put it back or remove it. Until then, a terminal started later in that session would get it. A restore, a handover successor or any later launch starts from the spec's `env:` alone, so the value is not saved and does not carry forward. To keep a value, put it in `env:`. One exception to "does not carry forward", for a managed Claude seat (see below): a one-off name that the seat's spec does not declare stays on the session's list of names, `OPENRIG_SEAT_ENV_KEYS` (names only, no values), because the first launch and an in-place restart of the same terminal read that list. So if a later pane in that session gets a value for that name from the tmux server's own environment, its managed Claude launch can forward that value, where a launch without `--env` would leave it out. The first launch's one-off value itself is not passed on to that pane. This comes from reading the code and has not been measured. `--env` does not apply to `rig up <rig-name>` (a restore) or to a topology (several rigs from their own specs); the CLI refuses both. For a topology, put `env:` in each rig's spec.
 - Names starting `OPENRIG_` are reserved for OpenRig and refused. Empty values are refused, because the launch omits empty variables.
 - `rig export` writes the rig and member `env:` back out.
 

package/daemon/context-packs/reference/whats-new.md

@@ -1,87 +1,142 @@
-# What changed in OpenRig 0.6.14
+# What changed in OpenRig 0.7.0
 
-This note is for an agent on an install that was just upgraded to 0.6.14. It lists only what behaves differently from
-0.6.13 and what to do about it. For everything OpenRig can do, read the capability map:
+This note is for an agent on an install that was just upgraded to 0.7.0. It lists only what behaves differently from
+0.6.14 and what to do about it. For everything OpenRig can do, read the capability map:
 `rig context get onboarding-width/public-what-you-can-do.md`. Each release replaces this file, so
 `rig context get reference/whats-new.md` describes the installed version once the upgraded daemon is running. Without
 a running daemon, read `$OPENRIG_HOME/reference/whats-new.md`. The daemon refreshes that copy when it starts, so right
-after an upgrade it can still hold the previous version's note. Coming from 0.6.12 or earlier, also read 0.6.13's
-release notes: its changes and migration `117` arrive with this upgrade.
+after an upgrade it can still hold the previous version's note.
 
 ## After the upgrade
 
-- **Restart the daemon** (`rig daemon stop`, then `rig daemon start`). No migration runs. One setting is added,
-  `transport.local_user_guard`, off by default (see below).
-- **The bundled openrig-core plugin goes from 0.1.14 to 0.1.15.** Installed copies are replaced and carry refocus's own
-  notes lookup.
+- **Restart the daemon** (`rig daemon stop`, then `rig daemon start`). Six migrations run on the first start (116, 118,
+  119, 121, 122 and 123). Two settings are added, `terminal.history_limit` (default 10000) and
+  `terminal.inherit_tmux_environment` (default false), and `provider.subscription_moves` is removed.
+- **The bundled openrig-core plugin goes from 0.1.15 to 0.1.17.** Startup replaces installed copies of managed plugins and
+  marked global skills. It first copies every file it replaces under `$OPENRIG_HOME/backups/managed-refresh/<id>/`,
+  whether or not anyone edited it, and logs `[plugin-vendor] preserved previous contents of <file> at <copy> before
+  managed refresh` for each one. A stock upgrade from 0.6.14 copies about 22 files (about 250 KB), and a later start with
+  no new version copies none. The copies matter only for files someone changed: the copy keeps the bytes, but the change
+  may no longer be active after the refresh. Keep the log line, because it names the original file and the copy's folder
+  doesn't. If a copy fails, that plugin or skill isn't refreshed, its files are kept, and the log says so. Copies aren't
+  cleaned up.
+- **If you gave new agents accounts or API keys through tmux's global environment** (`tmux set-environment -g …`), new
+  agents no longer inherit it (below). Put the values in the seat's `env`, pass `rig up --env KEY=VALUE`, or keep the old
+  behaviour with `rig config set terminal.inherit_tmux_environment true`. Running agents aren't affected.
+- **If you write queue rows to another machine by its self-id** (`member@rig@<self-id>`), run `rig host doctor <alias>`
+  once per host: bindings learned before 0.7.0 have no address.
 
-## Output that changed shape
-
-- **`rig ask --wake`** on a seat whose runtime isn't Claude or Codex prints `Wake runtime '<runtime>' … is not
-  supported. Supported runtimes are claude and codex.` A `member@rig` target exits 2 (the daemon refuses it); a raw-id
-  `--runtime` value exits 1 (the CLI refuses it). No wake starts.
-- **`/healthz`** gains `euid`, the daemon's effective user ID, beside `pid`, whether or not the Mac check is on.
-- **`rig compact`** (manual) waits up to 240 seconds for its result, up from 180, because preparation now has 180
-  seconds, up from 120.
+## New things you can do
 
-## Seats and restore
+- **Hold a person's routine asks while they're away:** `rig gateway human quiet set <id> --daily HH:MM-HH:MM` or
+  `--until <time>` (`--tz`), and `end`, `clear` or `show`. A held ask posts once, without a mention, when quiet ends.
+  Asks tagged `escalation` or `wake-escalation` are not held.
+- **Apply a person's mode** ("asleep", "out of office"): `rig gateway human mode save <id> <name>` (with
+  `--availability`, `--expected-back`, `--decision-room "<their words>"`, `--exclude`, `--quiet`), then `apply <id>
+  <name> [--until …]`, `current`, `end` and `account`. Never tell the person "back to normal" while the account shows an
+  effect `kept`, `pending` or `failed`.
+- **Decide an ask inside a person's decision room:** check `rig gateway human mode room <id>`, then `rig gateway human
+  mode decide <qitemId> --application <id> --reason "…" --reversible|--irreversible`. It's recorded as delegated, never
+  as their answer, and only the agent that asked can decide. Permission prompts are refused (`permission-prompt`).
+- **Pass a rig's name instead of its id** to `archive`, `unarchive`, `release`, `shrink`, `expand`, `snapshot`,
+  `export` and `restore --rig`. A name two rigs share is refused and the matching ids are named: with `--json`,
+  `archive`, `unarchive`, `release`, `shrink`, `expand` and `restore status --rig` return `rig_ambiguous`.
+- **Stop a managed compaction's follow-up after `/compact` was sent:** `rig compact --cancel` now also disarms the
+  restore and audit prompts that would follow. It sends no input and can't undo the `/compact`.
+- **See your work candidates:** `rig queue whoami` adds `currentWorkChoice` when current work isn't settled.
+- **See why a wake didn't land:** `rig queue show --json` adds `lastNudgeInputBox`.
+- **See each seat's configured effort:** the TUI agent table's `CFG EFF` column, and `effort` and `effortSource` in
+  `rig ps --nodes --full --json`. It's the configured level, not what the model ran.
 
-- **A seat that refuses every send with "Managed pane identity unavailable or changed; no input written."** because an
-  older OpenRig never recorded its tmux pane can be repaired in place: `rig reconcile-session <seat>
-  --repair-missing-pane --no-launch`. It fills only the missing pane and keeps the session, resume token and occupant
-  generation; the result names the same session, with continuity unverified. It refuses, writing nothing, with
-  `repair_not_applicable` (the binding already has a pane), `pane_ambiguous` (more than one pane or window),
-  `pane_missing` (no PID), `guard_target_changed`, `guard_operation_in_progress`, `typing_guard_enabled` or
-  `repair_timed_out`. Against an older daemon it reads `repair_missing_pane_unsupported` and never adopts. It records no
-  event.
-- **A manual `rig compact` whose preparation stops at an ordinary approval** keeps waiting within its deadline instead
-  of giving up. OpenRig never answers the approval: the person, or an agent allowed to, answers it.
-- **Refocus resolves each ancestor's notes file itself** (`NOTES.md`, then `MISSION_NOTES.md`) instead of starting `rig
-  scope resolve-notes` per ancestor. Its output, budgets and settings are unchanged.
+## Behaviour that changed
 
-## New things you can do
+- **New agents start from a clean environment, not tmux's global one.** A new seat or handover successor gets:
+  - the launch environment: `PATH`, `HOME`, `USER`, `LOGNAME`, `CODEX_HOME`, `OPENRIG_HOME`, `OPENRIG_URL`,
+    `OPENRIG_PORT`, `OPENRIG_HOST`, the seat's own identity values (such as `OPENRIG_SESSION_NAME`) and the allowed
+    provider sign-in variables. Not `OPENRIG_DB` or `TMUX_TMPDIR` (see Known gaps);
+  - the daemon's `LANG`, `LC_ALL`, `LC_CTYPE`, `TZ`, `TMPDIR`, `XDG_CONFIG_HOME`, `XDG_DATA_HOME`, `XDG_CACHE_HOME` and
+    `CLAUDE_CONFIG_DIR`;
+  - the values named in tmux's `update-environment`;
+  - its own `env`.
 
-- **Repair a missing pane without adopting:** `rig reconcile-session <seat> --repair-missing-pane --no-launch`.
-- **Point a person at a page written for them:** `docs/reference/quickstart.md` ("Getting started") is the first-use
-  page, with a glossary. `docs/reference/getting-started.md` is now titled "OpenRig setup reference" and opens with what
-  the agent doing the setup needs; its sections and anchors are unchanged, so `rig context get
-  reference/getting-started.md#…` lookups still work.
+  Shell startup still runs. `rig setup` warns when it sees a custom tmux configuration.
+- **After a reboot, the daemon restores a kernel whose seats are all detached** (and still bound to their sessions), in
+  the background, as `rig up kernel --existing` would. `OPENRIG_NO_KERNEL=1` still skips it, and `rig start --json` reports `kernelRestore`.
+- **A seat missing a required startup file no longer blocks its rig's restore:** `rig up <rig> --existing` holds that
+  seat and restores the others (`partially_restored`).
+- **Seats added to a running rig** with `rig expand`, `rig grow` or add-member get its culture file and rig-level
+  startup, for rigs created on 0.7.0 or later. Older rigs get no backfill.
+- **A busy daemon gets the real request.** The CLI refuses only when the daemon is stopped or stale, the connection is
+  refused or blocked, or the daemon answering belongs to another OpenRig home. A slow daemon is no longer read as down.
+- **A new seat's first startup message** says it's OpenRig's identity context, not a task. A seat whose startup sends
+  nothing else is asked to run `rig whoami --json` and say it's ready for an assignment.
+- **A new Claude seat's first startup text** waits briefly (about five seconds) for Claude's input box before it's
+  sent.
+- **Codex seats that select openrig-core get the plugin installed into Codex.** While Codex hooks are on
+  (`runtime.codex.hooks_enabled`, default on), OpenRig installs it with Codex's own marketplace and plugin commands at
+  daemon start and at a fresh launch, unless the person's Codex configuration disables it.
+  - **A first install only** (no earlier install or plugin cache): OpenRig checks the installed hook files against its own
+    copy, then trusts the plugin's six shipped hooks by their exact definitions, so the seat starts without Codex's hook
+    review.
+    The file check happens only when trust is granted: a later edit to the cached hook scripts keeps that trust, as with any hook trusted in Codex.
+  - **An existing install keeps the person's choices.** A plugin or hook they disabled stays disabled. One they left
+    untrusted stays under Codex's review: Codex records nothing for "continue without trusting", so OpenRig doesn't read a
+    missing trust record as permission.
+  - **What it adds:** the four managed inline hooks stay the only activity reporters; the plugin adds refocus and its
+    skills.
+- **Watchdog delivery is recorded as it happened:** `rig watchdog status` outcomes are `sent`, `refused`, `failed`,
+  `skipped` or `terminal` (0.6.14 had `sent`, `skipped` or `terminal`). Every reminder carries "Delivery may repeat after
+  an unconfirmed attempt." under its header line, and two refusals in a row at one seat's prompt raise that seat's prompt
+  alert. A park wake shows the continuation its park recorded (`Recorded continuation: …`), so record one when you park.
+- **Slack:** a thread reply answers a parked question only if it was written after the question posted, and a message
+  Slack rejects as `invalid_blocks` isn't posted again.
+- **Claude Code team agents are asked for permission less often.** Housekeeping commands such as `archive`, `attach`,
+  `bind`, `release`, `reconcile-session`, `config set` and `seat continue` no longer prompt. `seat restart` and `policy
+  permissions apply` now do.
+- **`rig up --plan` waits as long as an apply** (120 seconds). An unanswered plan exits 1 and is safe to run again.
+- **`rig setup` keeps 10,000 rows of tmux history**, down from 50,000 (`terminal.history_limit`, 2000 to 1000000).
 
-## Off by default
+## Output that changed shape
 
-- **A Mac local-user check.** On a Mac shared by several accounts, `rig config set transport.local_user_guard true` (or
-  `OPENRIG_TRANSPORT_LOCAL_USER_GUARD=true` in the CLI's environment) makes the CLI refuse a local daemon another account
-  runs. It compares the PID and effective UID the daemon reports in `/healthz` with two `ps` readings and a second
-  health response, and refuses only when they agree on another account; the refusal names `rig daemon start --port
-  <unused-port>`. Missing, disagreeing or timed-out evidence, and an older daemon without `euid`, keep today's
-  behaviour. No daemon restart is needed. Explicit `OPENRIG_URL` targets and registered remote hosts keep their routing,
-  later browser or TUI connections aren't checked, and with it on `sudo rig …` against a user-owned daemon refuses. It
-  isn't authentication: it trusts the daemon's own report. Details: `rig context get
-  reference/getting-started.md#optional-mac-local-user-check`.
+- **`rig gateway human list`** shows each person's availability (`available`, `focus`, `away` or `off`) where it showed
+  `away` or `available`, plus a `quiet:` line; JSON adds `availability` and `quiet`.
+- **`rig attach`** prints `Sender:` (and `Tmux:` when the names differ), and `rig whoami` adds `identity.senderAddress`.
+  A clashing member name is refused with `address_conflict`.
+- **Send results** carry `managedCompaction`, and the CLI prints a `Notice:` line.
+- **`rig ps --rig <unknown>`** exits 1, and `--host H --rig X` filters by rig.
 
 ## What to stop doing
 
-- **Don't use plain `rig reconcile-session` to fix a launched seat's missing pane.** It adopts the seat into a new
-  session with no resume token; use `--repair-missing-pane --no-launch`.
-- **Don't abandon a manual `rig compact` because preparation hit an approval.** Answer it, or ask the person to, within
-  the 180 seconds.
-- **Don't try `rig ask --wake` on a Pi or custom seat.** Use `rig ask` without `--wake` to search what it said, or send
-  to the live seat.
+- **Don't use `rig provider moves`:** it's gone with its setting. Report a subscription move as a queue item to whoever
+  asked.
+- **Don't steer a new seat's account or keys through tmux globals.** Use the seat's `env` or `rig up --env`.
+- **Don't close a row `done` with `--closure-reason blocked_on`.** It's refused with `invalid_closure_reason`; use `rig
+  queue block <id> --on <child>`.
+- **Don't treat "daemon did not respond" as down.** Check the effect before any retry or restart.
+- **Don't look up a rig id first** for the commands above; pass the name.
+- **Don't restart the daemon to stop a managed compaction's follow-up prompts.** Use `rig compact --cancel`.
+- **Don't run `rig up kernel --existing` by hand after a reboot** before checking `rig status`.
+- **Don't reuse a `deliveryId` to deduplicate a send,** and don't pass `--reason` or `--actor` to `rig slack verify`.
+
+## Known gaps in 0.7.0
 
-## Known gaps in 0.6.14
+- **A new seat doesn't get the daemon's `OPENRIG_DB` or `TMUX_TMPDIR`.** A tool in the seat that reads `OPENRIG_DB`
+  directly can fall back to the default database. If you rely on either, pass it in the seat's `env` or with `rig up
+  --env`.
+- **A launch that warns "Scoped tmux environment unavailable; retaining the previous environment"** didn't give that seat
+  the clean environment, and the seat may lack OpenRig's variables. Check `env` in the seat before relying on them.
+- **A Slack channel-mapping change needs a daemon restart** (`rig daemon stop`, then `rig daemon start`). Don't use `rig
+  slack disable` then `enable` for it: enabling marks any alerts waiting to post to Slack as already seen, so open
+  exchanges miss them.
 
-- **The compaction and refocus fixes** are tested without a native compaction or a loaded machine: confirm a
-  compaction by its restore request or the drop in context, and check that a restored seat is really working.
-- **The pane repair refuses while typing protection is on.** The compaction refusal for a protected seat whose pane
-  isn't recorded still suggests plain `rig reconcile-session <seat> --no-launch`, which adopts. For a running launched
-  seat whose pane was never recorded, use `rig reconcile-session <seat> --repair-missing-pane --no-launch` instead;
-  it needs typing protection off, so turn protection off only if the person agrees. A delivery held from before the
-  repair can still refuse.
-- **`rig context get reference/quickstart.md` doesn't resolve:** the page isn't in the reference context pack. Read it
-  from the package's `docs/reference/` or the repository.
-- **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 (7433) unless `transport.local_user_guard` is on. The check trusts the daemon's own report, identity
-  can change between the check and the connection, and direct HTTP clients aren't covered.
-- **0.6.13's other known gaps still apply:** a fresh in-place Claude handover can report ready early when the screen,
-  pane or process can't be read or proven; one Slack app across machines hasn't run on two real machines, and Slack
-  recovery doesn't catch up older open threads; `rig seat set-cwd` checks the new folder once.
+- **A new Claude seat's startup text can stay in its input box unsent.** If a fresh Claude seat sits idle with text at
+  its prompt, press Enter in its pane, or ask the person to.
+- **The TUI's terminal button refuses inside a Herdr pane reached over SSH.** Start the TUI with `env -u SSH_CONNECTION
+  -u SSH_CLIENT -u SSH_TTY rig tui`, or run `rig terminal open '<view>' --provider herdr`.
+- **Claude seats on a macOS native install can read as needing attention after a restore.** Check the pane before
+  acting on it.
+- **Ubuntu 22.04's stock tmux 3.2a can crash its whole server** when OpenRig checks a pane that has just closed. Avoid
+  tmux 3.2a for OpenRig (`tmux -V`).
+- **Delegated decisions:** the ask is created before the decision, so without quiet hours it can post to the person
+  first. Pair a decision room with quiet hours, or decide before asking.
+- **`restore-check` still treats a missing startup file as rig-wide.** Trust `rig up --existing`'s per-seat result.

package/daemon/context-packs/skills/agent-operated-software/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-operated-software"
-version: "0.6.14"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when designing, building, operating, or diagnosing an ongoing application whose live backend or control loop includes OpenRig agents, including applications with a Markdown, YAML, or JSON agent control plane or a thin surface over specialist agent roles."
 files:

package/daemon/context-packs/skills/agent-operated-workflows/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-operated-workflows"
-version: "0.6.14"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when a bounded real-world procedure has a deterministic happy path but brownfield, variable, or partially knowable state; when an operation must resume from verified evidence; or when deciding whether agent judgment or ordinary code should own a procedure's control loop."
 files:

package/daemon/context-packs/skills/applying-a-permission-policy/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "applying-a-permission-policy"
-version: "0.6.14"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use before launching a team during agent-guided setup, or when a user asks to configure OpenRig command permissions, reduce repeated native approval prompts, or apply a selected rig/seat permission policy."
 files:

package/daemon/context-packs/skills/claude-compaction-restore/SKILL.md

@@ -221,12 +221,19 @@ The audit message asks for a read-depth table and tells you not to conserve toke
 
 The next restore map links this note, which keeps the chain unbroken.
 
+## Then resume
+
+Resume the outcome selected by the user's current instructions, standing duties and assigned work. Use existing
+task records, decisions and your recap to recover the next useful action, remaining constraints and evidence
+already earned. Check uncertain effects before replaying work. Available skills and historical suggestions do not
+by themselves widen scope or create required stages. Use authorized skills, subagents, peer help and useful tests
+within your remit without another permission request. Route a missing decision to its existing owner and continue
+unaffected work.
+
 ## Guardrails
 
 - Compaction is survival, not housekeeping. Compact only when a seat is genuinely near its limit, never to
   "lean" a seat or prepare a starter image; a compacted seat can sound confident while missing the context it needs.
-- Continue from the map and the files, not from the summary's "next step" alone: a hold placed after the
-  summary was written still binds.
 - Do not launch a fresh session in place of restoring.
 - An honest `PARTIAL` with its reason is a correct outcome. Claiming coverage you did not reach is the
   failure.

package/daemon/context-packs/skills/claude-compaction-restore/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "claude-compaction-restore"
-version: "0.6.14"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when a Claude Code session is about to compact, has just compacted, reached its context limit, resumed after /compact, or must rebuild its working picture of a long-running seat from its own restore map, its JSONL transcript and the files it touched."
 files:

package/daemon/context-packs/skills/core/agent-starters/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-starters"
-version: "0.6.14"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when creating, refreshing, packaging, inspecting, promoting, or deprecating a named per-seat starting point — Agent Starter manifest authoring, the 6-state lifecycle (captured → named → inspectable → used → promoted → deprecated), provenance honesty, and refusal rules. NOT a VM image; a managed starting point composed from agent role + startup context + optional native session source + provenance."
 files:

package/daemon/context-packs/skills/core/agent-startup-and-context-ingestion/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-startup-and-context-ingestion"
-version: "0.6.14"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, \"rig context\" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent)."
 files: