docs: carry the guide's resume exceptions and the backoff cap's default

The capability map's eligible Codex resume now says it sends only the
missing blocks it can read: a block whose source is gone or can't be read
is reported missing, and the seat-skills line, after the person's yes,
still goes to AGENTS.md, as the startup guide says. The later
`up --existing` sentence names those readable blocks.

The network connector page says the retry cap is 5 minutes by default, or
the poll interval when that is longer, which is what the connector does.

docs/as-built/arteries.md

@@ -118,5 +118,5 @@ When a regression reaches a release, add one line: date, issue, artery, and whic
 - 2026-10-25, #1955, delivery (send readiness): approval-prompt text that a working Claude seat quoted in its own output read as a waiting prompt, so sends and queue wakes to that seat were refused. This one was present since 0.7.0, so it did reach a release; it was found during the 0.7.1 cut by real work on a test machine. Missed by classifier fixtures that had no working pane quoting prompt text. Fixed in #1955 for 0.7.2.
 - 2026-11-10, F4 (0.7.11, #2662 leg (a)), delivery (draft-aware, under Claude's update banner): beneath Claude's bare update banner, a draft-aware delivery pasted the message and withheld Enter, leaving it in the composer, where 0.7.10 held it. Caught at the cut by a native delivery run and accepted with disclosure, so it reached 0.7.11. Missed by footer-grammar fixtures that had no paste hint beside the update notice. Fixed in #2786 for 0.7.12.
 - 2026-11-10, Pi case 1c (0.7.11, #2630), launch (Pi account home): a Pi seat with its own Pi login and a declared absolute `PI_CODING_AGENT_DIR` stopped at launch even with an `auth.json` there, with a misleading missing-account-file error, where 0.7.10 started it. Found at the cut by source and function-level tests, not natively, and accepted with disclosure, so it reached 0.7.11. Not fixed: #2803 (0.7.12) makes the launch error name the real cause, and the stop stands. Scenario owed: a Pi seat with its own login and a declared account home.
-- 2026-11-12, a tracked `AGENTS.md` (0.7.12, repaired by #3039), restore and relaunch (Codex guidance blocks): on a Codex seat, a snapshot `rig restore`, and `rig down` followed by `rig up --existing`, each wrote OpenRig's managed guidance blocks back into the person's tracked `AGENTS.md` (249 B to 17,316 B), leaving the worktree modified. Seen at the cut by a native Codex run through restore and `up --existing`, and accepted with disclosure, so it reached 0.7.12: its release text says to check `git status` after either. Snapshot restore was already a disclosed 0.7.11 limit; `up --existing` was newly observed, and whether it regressed isn't established. The check that would tell, the same `up --existing` run on the previous release, hasn't run. #3039 merged after 0.7.13's cut, so the repair is on main for 0.7.14, not in 0.7.13. Scenario owed: a Codex seat in a repository with a tracked `AGENTS.md`, checked with `git status` after a restore and after `up --existing`.
+- 2026-11-12, a tracked `AGENTS.md` (0.7.12, partly repaired by #3039), restore and relaunch (Codex guidance blocks): on a Codex seat, a snapshot `rig restore`, and `rig down` followed by `rig up --existing`, each wrote OpenRig's managed guidance blocks back into the person's tracked `AGENTS.md` (249 B to 17,316 B), leaving the worktree modified. Seen at the cut by a native Codex run through restore and `up --existing`, and accepted with disclosure, so it reached 0.7.12: its release text says to check `git status` after either. Snapshot restore was already a disclosed 0.7.11 limit; `up --existing` was newly observed, and whether it regressed isn't established. The check that would tell, the same `up --existing` run on the previous release, hasn't run. #3039 merged after 0.7.13's cut, so the repair is on main for 0.7.14, not in 0.7.13. Scenario owed: a Codex seat in a repository with a tracked `AGENTS.md`, checked with `git status` after a restore and after `up --existing`.
 - 2026-11-12, `rig queue create` latency (0.7.13), queue writes (the CLI-to-daemon create path): on one performance host, under a before/after rule frozen ahead of the run (six alternating arms of 100 creates each, at the same offered load), whole `rig queue create` invocations had a median of 304.6 ms against 0.7.12's 276.0 ms, +10.39% (about +29 ms), and the two versions' per-arm medians didn't overlap. The p95 moved from 320.1 to 349.3 ms. Send latency, and memory and CPU under load, stayed within the comparison's unchanged range; the idle-memory comparison was inconclusive. Split at the daemon's insert timestamp, both the part before the insert (CLI start, transport, the daemon's handling before the insert) and the part after it moved, so no single segment carries the change, and the cause is unassigned. Caught at the cut by the release's representative-load performance comparison and accepted with disclosure, so it reached 0.7.13. Missed by the package suites and stub scenarios, which don't time whole invocations against the previous release. Not fixed: 0.7.14's stability comparison times the same path with CLI startup, transport, daemon handling and exit recorded separately. Scenario owed: the same before/after create timing on retained history, on one host at a fixed offered load, with those boundaries recorded.

docs/as-built/cli-reference.md

@@ -551,7 +551,7 @@ default-permit record (tag `runner-permission-permit`) opens no row.
 | `rig queue show <qitemId>` | — | `--full`<br>`--json`<br>`--host <id>` |
 | `rig queue artifact <qitemId>` | — | `--root <name>`<br>`--json` |
 | `rig queue transitions <qitemId>` | — | `--json`<br>`--full`<br>`--host <id>` |
-| `rig queue list` | — | `-a, --all`<br>`-A, --all-rigs`<br>`--full`<br>`--owned`<br>`--mine`<br>`-o <format>`<br>`--destination <session>`<br>`--source <session>`<br>`--state <state>`<br>`--target-repo <name>`<br>`--tag <tag>` (repeatable, AND)<br>`--mission <id>`<br>`--slice <id>`<br>`--limit <n>`<br>`--json`<br>`--host <id>` |
+| `rig queue list` | — | `-a, --all`<br>`-A, --all-rigs`<br>`--full`<br>`--owned`<br>`--mine`<br>`-o <format>`<br>`--destination <session>`<br>`--source <session>`<br>`--state <state>`<br>`--target-repo <name>`<br>`--tag <tag>` (repeatable, AND)<br>`--mission <id>` (repeatable)<br>`--slice <id>` (repeatable)<br>`--limit <n>`<br>`--json`<br>`--host <id>` |
 | `rig queue overdue` | — | `--rig <name>`<br>`-A, --all-rigs`<br>`--full`<br>`--limit <n>`<br>`--json` |
 | `rig queue undelivered` | — | `--rig <name>`<br>`-A, --all-rigs`<br>`--full`<br>`--limit <n>`<br>`--json` |
 | `rig queue inbox-drop <destinationSession>` | — | `--sender <session>`<br>`--body <text>`<br>`--body-file <path>`<br>`--tags <tags>`<br>`--urgency <urgency>`<br>`--audit <pointer>`<br>`--id <inboxId>`<br>`--json` |

docs/reference/agent-startup-guide.md

@@ -42,10 +42,11 @@ They are recognized from each harness's English prompt text.
 pre-approves N tool permissions" (from the folder's `.claude/settings.json`): OpenRig never
 answers it, not even with `recovery.auto_drive_provider_prompts`, because its default choice
 declines those permissions (or exits) and approving them is your call. With that setting on,
-the plain workspace trust prompt is answered only when its options are exactly "No, exit" and
+when a Claude Code seat is resumed, the plain workspace trust prompt is answered only when its options are exactly "No, exit" and
 "Yes, I trust this folder": Claude Code 2.1.322 opens it on "No, exit", so OpenRig moves the
 selection down once and presses Enter only after it reads the focus on "Yes". Any other option
 set, a prompt drawn without a cursor or a focus that does not reach "Yes" gets no confirmation.
+A fresh launch still stops at the trust prompt for you to answer.
 
 ## Continue a Codex fork whose child ID arrived late
 
@@ -415,7 +416,7 @@ Each startup file and action specifies when it applies:
 - `restore` — delivered when a seat is restored without its earlier conversation: a restore whose resume falls back to a fresh conversation, or a retried start
 - Default: `[fresh_start, restore]` (both)
 
-**An exact resume delivers neither.** When a restore reopens the seat's saved conversation (`rig up <rig> --existing` with a resume token), OpenRig types no startup actions and delivers no startup files, `restore` ones included: the conversation already has them, and typing them again would add turns to it. The one exception: the guidance file's managed blocks are brought up to date before the harness starts. A missing block is put back, and a stale one is refreshed (see below).
+**An exact resume delivers neither.** When a restore reopens the seat's saved conversation (`rig up <rig> --existing` with a resume token), OpenRig types no startup actions and delivers no startup files, `restore` ones included: the conversation already has them, and typing them again would add turns to it. The one exception: the guidance file's managed blocks are brought up to date before the harness starts. A missing block is put back, except on an eligible Codex resume, where it goes with the resume instead (see [Codex guidance at launch](#codex-guidance-at-launch)), and a stale one is refreshed (see below).
 
 **A seat handover does the same put-back.** Before a fresh, fork or rebuild successor starts, the handover puts the seat's missing managed guidance blocks back in its guidance file from the saved startup context. That's the rig's Claude file (`CLAUDE.md`, or `CLAUDE.local.md` when the rig uses it) for Claude, and `AGENTS.md` for Codex, Pi and omp. So a seat rebuilt into a new working directory keeps its guidance.
 

docs/reference/getting-started.md

@@ -756,9 +756,9 @@ Herdr, use `rig terminal open starter --provider herdr`; for the shared
 dashboard together with the kernel conversations, use the
 [saved first view](#open-the-kernel-conversations). The equivalent
 cmux provider is also available. Read the opened/absent/degraded result: a
-partial terminal view is not a healthy team. Each `--provider herdr` open adds
-a new workspace, numbered when the name is taken; return to the one already open
-when you want to preserve it. From inside Herdr, `rig terminal open <view> --window`
+partial terminal view is not a healthy team. A `--provider herdr` open focuses a
+workspace that still shows this view live instead of adding a copy; otherwise it
+adds a new workspace, numbered when the name is taken. From inside Herdr, `rig terminal open <view> --window`
 focuses a matching space instead of adding one. Herdr's own status for a seat can
 read idle or unknown while OpenRig shows it waiting (`needs-input`), for example in
 a narrow tile that wraps Claude's footer, or in a tile that shows the inner tmux

docs/reference/hosted-members.md

@@ -182,7 +182,8 @@ and nothing else is offered:
   can address count, and the first of these that any of them matches decides, so another seat's slug never makes an exact
   name ambiguous and a seat the grant can't address never shadows one it can. The item is stored under that
   seat's actual session. A slug two seats match returns `destination_ambiguous` with the candidates, and a name that no
-  seat the grant can reach has returns `destination_not_found`. A name the grant can't address as written (its own seat,
+  seat the grant can reach has returns `destination_not_found`. If the team couldn't be read to check, it returns
+  `destination_unchecked` and nothing was written; try again. A name the grant can't address as written (its own seat,
   or another assistant's without `team`/`list`) stays `out_of_scope`, whether or not that seat exists.
 - **Two assistants together:** a grant with `team`/`list` sees its rigs' seats with `rig_team`, and may address and hear from
   another connected assistant's seat. A grant without it never reaches a seat in the service's caller form

docs/reference/network-connector.md

@@ -83,7 +83,7 @@ rig network connect <seat> --hub <url> --as <participant> --token-file <path>
 - `<participant>` is the participant's address in the hub (`member@rig`), and the token file holds its bearer.
 - The binding follows the seat's node, so a relaunched or renamed seat keeps it.
 - The token is stored at `<OpenRig home>/network-secrets/<binding>/credential.json` (a 0700 folder and a 0600 file). It
-  is never returned by the API or shown in status. A token in the hub URL is refused.
+  is never returned by the API or shown in status. A user name or password in the hub URL is refused: put the token in its token file, not in the URL.
 - A plain-http hub URL needs `--allow-http` (see Limits).
 - One active binding per local seat, and one per hub participant.
 - On a daemon with an operator bearer configured, `connect` and `disconnect` send `OPENRIG_AUTH_BEARER_TOKEN`, as the
@@ -92,7 +92,7 @@ rig network connect <seat> --hub <url> --as <participant> --token-file <path>
 ## What the connector does
 
 The daemon runs the connector for every active binding. It normally polls every 30 seconds
-(`OPENRIG_NETWORK_POLL_SECONDS`, at least 5); a failing hub, backoff or a backlog can delay it. Each binding's pass has
+(`OPENRIG_NETWORK_POLL_SECONDS`; a value under 5 is ignored); a failing hub, backoff or a backlog can delay it. Each binding's pass has
 a deadline of 60 seconds, so one slow hub doesn't hold the others. With no active binding it makes no network call.
 
 1. It lists the participant's own items on the hub, claims each pending one, and creates a local queue item for the
@@ -144,7 +144,8 @@ a replaced installation. `--json` adds the connector's view: each binding's next
 - **The seat has no session:** its hub items stay pending and unclaimed, and the last error says why. They're taken
   once the seat has a session again. A stopped seat still has its session, so it still takes items; they wait for it.
 - **The hub can't be reached, or a pass runs past its deadline:** the binding stays active, the error is recorded, and
-  retries back off, doubling up to 5 minutes. A failure on this machine is recorded as local, not as the hub's.
+  retries back off, doubling to 5 minutes by default, or to the poll interval when that is longer, with up to 20%
+  jitter either way. A failure on this machine is recorded as local, not as the hub's.
 - **The hub refuses the credential** (HTTP 401): the binding is marked revoked and its credential removed. No new work
   comes in; local items and results stay.
 

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

@@ -103,7 +103,8 @@ person needs in their project or home folder and name that path.
   dashboard-only fallback; explain the failure and help with the chosen fallback. Herdr is visible only in a terminal
   the person can see; switching the shared TUI to `:terminals` does not open one. No and headless/SSH use are valid
   background outcomes. Provider-only `--provider herdr`, `--provider cmux` or `--provider rex` is for a provider that's
-  already running, not the first desktop window, and each such open adds a new workspace. `--provider herdr-app` opens
+  already running, not the first desktop window. Each `cmux` or `rex` open adds a new workspace; `herdr` focuses one
+  that still shows the view live, else adds one. `--provider herdr-app` opens
   the view in the herdr-app window you run it in (it adds OpenRig's mods there first). Inside a herdr-app
   terminal, plain `rig terminal open <view>` does the same when that window is answering. `--window` always asks for a
   new desktop window.

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

@@ -596,12 +596,16 @@ not have to tear one down to change it, and you rarely have to start from nothin
   A fresh Pi seat normally keeps OpenRig's guidance in its own agent folder, and a fresh Codex
   0.164.0+ seat normally gets it as launch developer instructions, so neither adds it to the
   repository's `AGENTS.md`. The repository file is still used when the Pi folder or its `AGENTS.md`
-  is a link, when a Codex config layer sets `developer_instructions` or can't be read, and for a
-  Codex resume, fork, restore or handover successor, or an older or unknown Codex version
-  (`docs/reference/agent-startup-guide.md` has the rule). At
+  is a link, when a Codex config layer sets `developer_instructions` or can't be read, for a Codex
+  fork or handover successor, a Codex resume in a rig without pods, or an older or unknown Codex
+  version. An eligible Codex resume (a rig with pods, Codex 0.164.0 or later, no configured
+  guidance, readable configuration) sends the missing blocks it can read with the resume instead;
+  a block whose source is gone or can't be read is reported missing, and the seat-skills line,
+  after the person's yes, still goes to `AGENTS.md` (`docs/reference/agent-startup-guide.md` has
+  the rule). At
   launch, a block a person edited is kept and named (`guidance_block_edited`), not replaced.
   `rig up <rig> --existing` puts back the OpenRig guidance blocks `rig down` removed before a
-  resumed seat starts. A seat still missing one makes the rig `partially_restored` (its node lists
+  resumed seat starts, except on that eligible Codex resume, where those readable blocks go with the resume. A seat still missing one makes the rig `partially_restored` (its node lists
   `guidanceGaps`) and `rig up` exits 1. A seat that wasn't running at the snapshot, but whose
   earlier session left a resume token, stops at `awaiting-decision` instead of starting fresh, in
   `rig up --existing` and in `rig launch` (exit 1); the message names the command that starts it

skills/rigs/SKILL.md

@@ -103,7 +103,8 @@ person needs in their project or home folder and name that path.
   dashboard-only fallback; explain the failure and help with the chosen fallback. Herdr is visible only in a terminal
   the person can see; switching the shared TUI to `:terminals` does not open one. No and headless/SSH use are valid
   background outcomes. Provider-only `--provider herdr`, `--provider cmux` or `--provider rex` is for a provider that's
-  already running, not the first desktop window, and each such open adds a new workspace. `--provider herdr-app` opens
+  already running, not the first desktop window. Each `cmux` or `rex` open adds a new workspace; `herdr` focuses one
+  that still shows the view live, else adds one. `--provider herdr-app` opens
   the view in the herdr-app window you run it in (it adds OpenRig's mods there first). Inside a herdr-app
   terminal, plain `rig terminal open <view>` does the same when that window is answering. `--window` always asks for a
   new desktop window.