@openrig/cli 0.6.1 → 0.6.3

package/daemon/assets/claude-statusline-context.cjs

@@ -95,13 +95,22 @@ function normalizeRateLimits(value) {
   for (const key of ["five_hour", "seven_day"]) {
     const window = value[key];
     if (!window || typeof window !== "object" || Array.isArray(window)) continue;
+    const resetsAt = typeof window.resets_at === "number"
+      ? unixSecondsToIso(window.resets_at)
+      : window.resets_at;
     if (typeof window.used_percentage !== "number" || !Number.isFinite(window.used_percentage)
-      || typeof window.resets_at !== "string") continue;
-    result[key] = { usedPercent: window.used_percentage, resetsAt: window.resets_at };
+      || typeof resetsAt !== "string") continue;
+    result[key] = { usedPercent: window.used_percentage, resetsAt };
   }
   return result.five_hour || result.seven_day ? result : null;
 }
 
+function unixSecondsToIso(value) {
+  if (!Number.isFinite(value)) return null;
+  const date = new Date(value * 1000);
+  return Number.isNaN(date.getTime()) ? null : date.toISOString();
+}
+
 function writeJsonAtomic(outputPath, value) {
   const tmpPath = outputPath + ".tmp";
   const dir = path.dirname(outputPath);

package/daemon/assets/plugins/openrig-core/skills/applying-a-permission-policy/SKILL.md

@@ -1,12 +1,13 @@
 ---
 name: applying-a-permission-policy
 description: >-
-  Use when a user asks an agent to configure OpenRig command permissions, reduce
-  repeated native approval prompts, or apply a selected rig/seat permission policy.
+  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.
 metadata:
   openrig:
     stage: established
-    docs_checked: "2026-09-25"
+    docs_checked: "2026-09-29"
     verification_status: "Verify the installed harness version and effective settings; a rule-parser result is not a native permission test."
 ---
 
@@ -17,10 +18,40 @@ OpenRig operating posture, native command rules, sandbox access and launch flags
 are separate controls. A command rule grants execution capability, not authority
 to invent tasks, publish work or change another host.
 
+## Ask once before team launch
+
+Reuse an existing explicit choice for these harnesses and this scope from the
+user's onboarding context; do not ask again. Existing rules are configuration,
+not evidence of consent to expand their scope. Preserve them without expansion.
+If the choice is unknown, briefly explain:
+
+> This allows the whole `rig` command family, including starting/stopping agents,
+> changing OpenRig configuration and launching processes. It is not global YOLO
+> or permission to invent work. The scope is your personal settings for this
+> project unless you explicitly choose your user-wide sessions instead.
+>
+> Allow your agents to run OpenRig commands without repeated permission prompts?
+> **Yes — recommended** / **No — keep prompts**
+
+- **Yes:** require an actual affirmative answer, then apply the procedure below
+  at that scope for the selected harnesses. Never substitute user-wide rules
+  when project rules are unsupported. Native restrictions still apply.
+- **No:** leave permission settings unchanged and continue with existing prompts.
+- **No answer:** make no settings change, infer no consent and continue with
+  existing prompts. Do not keep asking during this setup.
+
+Remember an explicit Yes or No in the existing onboarding/project context the
+agent already reads: choice, harnesses and scope. For Yes, record the exact files
+and entries added, any pre-existing equivalents, and the loading/verification
+result. Do not add a preference service or native configuration key. No answer
+is not a remembered No. Offer broader permissive operation only as a separate
+explicit opt-in; the setup question does not select a builtin policy or mode.
+
 ## Choose the intended scope
 
-Use an existing explicit choice; otherwise explain these options and ask which
-the user wants. Do not ask again for routine steps already authorized.
+Outside the setup question above, use an existing explicit choice; otherwise
+explain these options and ask which the user wants. Do not reopen the menu after
+an answered setup question or ask again for routine steps already authorized.
 
 | Choice | What the agent configures |
 | --- | --- |
@@ -47,7 +78,14 @@ execution, an entire interpreter or a generic shell wrapper.
    hooks, auth, MCP, model settings and unrelated values. An allow must not erase
    a stricter rule or managed requirement. Report a real conflict instead of
    silently bypassing it.
+   Check both bare and actual absolute command spellings: a restriction on one
+   may not match the other. If a new allowance would evade a stricter restriction,
+   leave that addition unapplied and report the conflict; do not switch spellings
+   to bypass it.
 4. Back up touched files and merge only authorized additions, avoiding duplicates.
+   Recognize equivalent existing entries (including Claude's legacy `Bash(rig:*)`);
+   leave their markers untouched. Reapplying the same choice must be a no-op when
+   the required entries already exist, including no timestamp-only rewrite.
    The agent performs these edits; hand-editing is an option, not a required user
    chore. Apply the selected scope without another conversational permission round.
    Native enforcement still applies.
@@ -60,8 +98,15 @@ execution, an entire interpreter or a generic shell wrapper.
    not destructive probes. Report effective settings and remaining prompts.
    A parser match alone does not establish native behavior.
 
-For rollback, remove only this setup's additions, preserving later unrelated
-edits. Builtin policy specs remain read-only; customize in user space.
+Give the user this short undo: **“Undo the OpenRig command allowances added by
+this setup; keep my other rules.”** The agent removes only the recorded entries
+from their exact files, preserving pre-existing rules and subsequent edits.
+For Codex remove those `prefix_rule` entries; for Claude remove those
+`permissions.allow` entries. Delete a newly created rules file only if it still
+contains solely this setup's additions. Never restore the entire backup over
+later changes. Record the changed choice in the same context and verify native
+reloading/revocation; other pre-existing allowances may still permit `rig`.
+Builtin policy specs remain read-only; customize in user space.
 
 ## Codex command rules
 
@@ -103,8 +148,10 @@ codex execpolicy check --pretty --rules /absolute/path/to/openrig.rules -- print
 ```
 
 Inspect matches, not only exit status; repeat `--rules` for other effective
-files. A matching `prompt` or `forbidden` overrides allow. Verify rule loading
-in the target conversation after the required reload. For project-only scope,
+files. A matching `prompt` or `forbidden` overrides allow. The official procedure
+loads `.rules` at session startup; a file edit alone does not reload this turn.
+Preserve the conversation and use an authorized supported resume when needed,
+then verify loading in the target conversation. For project-only scope,
 confirm the layer is active there and absent from an unrelated project's active
 layers. An evaluator given an explicit `--rules` file proves matching, not that
 scope or automatic loading. Existing user-wide rules may already permit the
@@ -134,7 +181,9 @@ Current syntax uses ` *` for a command family; `Bash(rig:*)` is also supported.
 Narrower examples are `Bash(rig ps *)` and `Bash(rig queue list *)`.
 Preserve `deny`/`ask` entries and `defaultMode`; do not add `Bash(*)` or switch
 to bypass to resolve a mismatch. Inspect native `/permissions` and verify the
-actual command spelling.
+actual command spelling. A bare rule does not cover every absolute invocation:
+derive the actual executable and, after the stricter-rule check above, add its
+exact `Bash(/actual/path/to/rig *)` spelling if needed. Do not use a path wildcard.
 
 Choose scope using the [settings reference](https://code.claude.com/docs/en/settings):
 `.claude/settings.local.json` for personal project settings,
@@ -143,6 +192,9 @@ Choose scope using the [settings reference](https://code.claude.com/docs/en/sett
 Confirm the effective project root, especially for worktrees. Keep personal
 settings out of commits. Managed restrictions and sandbox/network controls
 still apply; a Bash allow is not a general network policy.
+Current Claude settings documentation describes live reload of permission
+edits. Confirm the rule's source in `/permissions` and repeated harmless calls
+in the target conversation; do not claim prompt behavior from JSON validity.
 
 ## Existing policies and broader modes
 
@@ -154,9 +206,10 @@ is unavailable, explain the remaining choice instead of selecting broader access
 
 For explicitly chosen broader operation, inspect
 `rig policy current --spec <user-owned-rig.yaml>` and the compatible getting-started guide's **Opt-in permissive
-operation** section. OpenRig's Codex `builtin:yolo` supplies `-s danger-full-access`;
-it does not itself select `approval_policy` and replaces a named
-`codex_config_profile` argument. Claude's corresponding launch flag is
+operation** section. OpenRig's Codex `builtin:yolo` supplies
+`-s danger-full-access -a never` and replaces a named `codex_config_profile`
+argument. The legacy environment-only YOLO path selects only the sandbox.
+Claude's corresponding launch flag is
 `--dangerously-skip-permissions`. Neither a resource `profile: default` nor OpenRig
 operating posture is a native permission policy. Do not change shipped defaults
 or assume editing a launch spec changes an existing seat.

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.1"
+version: "0.6.3"
 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.1"
+version: "0.6.3"
 taxonomy: world
 purpose: "The public capability map and source map referenced by the default onboarding walk."
 files:

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

@@ -1,9 +1,9 @@
 # Getting started: one useful change in your repository
 
 Start with a repository and one bounded change you can exercise. The shipped
-`first-project` starter provides two native Codex seats: an outcome owner and
-an independent checker. It uses your installed Codex executable and login;
-terminal-provider support does not change the harness or account being used.
+first-project recipes provide the same two seats: an outcome owner and an
+independent checker. Choose Claude Code, Codex, or one of each using the accounts
+you already have. Terminal-provider support does not change the harness or login.
 
 You need Node.js 22 or 24 and tmux, on macOS or Linux. On a Mac with Apple
 silicon, use Node.js 22 (see the [compatibility
@@ -11,14 +11,17 @@ history](../releases/v0.5.15.md#known-compatibility-limitation)). Native
 Windows is not supported yet, and WSL2 has not been tested. Node 20 is no longer
 supported; Node 26 and other versions are untested.
 
-**Choose permissions before starting the team.** The unchanged starter launches
-Codex with `-s workspace-write`; it leaves approval policy to your native Codex
-configuration. Network access is normally off in that sandbox, including access
-to the local OpenRig daemon. Its `profile: default` selects OpenRig resources,
-not a Codex permission profile. Ordinary permission prompts are therefore expected.
-You can keep those prompts, remember selected commands, or choose broader access.
-[Ask your agent to configure that choice](#have-your-agent-configure-permissions);
-OpenRig does not choose permissive operation for everyone.
+**Choose permissions before starting the team.** Ordinary OpenRig launches use
+Codex's `-s workspace-write`, with approval policy from your native configuration,
+or Claude Code's `acceptEdits`, which still leaves commands subject to native
+rules and prompts. Codex's sandbox normally blocks network access, including the
+local OpenRig daemon. A command allowance does not change general sandbox/network
+settings. The starter's `profile: default` selects OpenRig resources, not a native
+permission profile.
+Agent-guided setup [asks once](#have-your-agent-configure-permissions): “Allow
+your agents to run OpenRig commands without repeated permission prompts?”
+**Yes — recommended** / **No — keep prompts**. An existing explicit choice is
+reused; No or no answer leaves settings unchanged. Broader access is separate.
 
 > Everything below reports **what is currently true**, never a guarantee that
 > downstream work will succeed. "Daemon up" does not mean every agent is healthy;
@@ -57,33 +60,69 @@ to return (tmux defaults to Ctrl-b, then d). Decide native trust/auth prompts
 there. If a fresh start paused before context delivery, **c** finishes that
 delivery to the same occupant. **r** reads actual state again; **d** expands details.
 
-Install OpenRig and inspect `rig setup --dry-run` before applying machine
-changes. Check `tmux -V`, `codex --version` and `codex login status` in your
-launch shell; install missing prerequisites and complete `codex login` when
-needed. This starter needs tmux and Codex, without a Claude login or Herdr
-plugin. The kernel selects its available native runtime variant separately.
+### Choose your providers
 
-`rig setup` currently installs/checks both harnesses and cmux. Use it when you
-want that full environment. Its overall failure can include an optional
-component for this starter: read the individual result and verify the three
-prerequisites above rather than treating a missing Claude login as broken
-Codex. A missing Codex login remains a real launch blocker.
+Ask: **“Which working account do you want this team to use: Claude Code, Codex,
+or both?”** Reuse an explicit choice already made. Recommend the account the
+user already has working; a second subscription is not a prerequisite.
+
+| Choice | Starter name | Owner / checker runtime and model |
+| --- | --- | --- |
+| Two Codex agents (existing route) | `first-project` | Both `codex`, pinned `gpt-6-astra` |
+| Two Claude agents | `first-project-claude` | Both `claude-code`, configured native default model |
+| One of each | `first-project-mixed` | Claude owner (native default); Codex checker (`gpt-6-astra`) |
+
+Claude uses the same unpinned model convention as the existing Claude kernel and
+implementation-pair recipes: OpenRig does not pass a model override. Read the
+selected harness's configured model and show it alongside the recipe and launch
+command before proceeding. Confirm account access to any pin; if unavailable,
+ask for a supported model choice rather than silently substituting a model or
+provider. After launch, confirm the actual native model before assigning work.
+
+Install OpenRig and check `tmux -V`. Check **only the selected providers**:
+
+- Claude Code: `claude --version` and `claude auth status`. If sign-in is missing,
+  ask once: “Please run `claude auth login` in your launch environment.”
+- Codex: `codex --version` and `codex login status`. If sign-in is missing,
+  ask once: “Please run `codex login` in your launch environment.”
+
+Install a missing selected CLI using its provider's installation instructions.
+The other provider's CLI/login and Herdr/cmux are optional. Do not copy credentials
+or start repeated sign-in attempts. Recheck the selected login after the user
+completes it. `rig setup --dry-run` previews the broader setup; applying
+`rig setup` installs/checks **both** harnesses and cmux, so it is optional for
+this selected-provider path, not a requirement to fix an unused provider.
+
+### Kernel startup stays automatic
+
+On a fresh instance, ordinary daemon startup chooses the kernel variant from
+successful native auth probes: Claude alone, Codex alone, or both. Thus an absent
+unused provider is fine. The project recipe does **not** constrain that probe:
+if both accounts are authenticated, automatic kernel startup uses both, even
+when the two project agents use just one provider. No manual kernel setup is
+needed for this journey. The starter choice is not an instance-wide provider
+restriction; a request to use only one provider for everything is separate.
+Preserve any existing managed kernel and working rigs.
+
+### Launch the two project seats
+
+Set `starter` to the chosen name from the table; the existing Codex route remains:
 
 ```sh
 cd <your-repository>
-rig specs preview first-project
-rig up first-project --cwd . --plan
-rig up first-project --cwd .
+starter=first-project  # or first-project-claude or first-project-mixed
+rig specs preview "$starter" --kind rig
+rig up "$starter" --cwd . --plan
+rig up "$starter" --cwd .
 rig status
-rig ps --nodes --rig first-project
+rig ps --nodes --rig "$starter"
 ```
 
-Preview the starter's seats and resources; plan checks resolution and
-preflight for the selected working directory. Launch starts the daemon if needed; the kernel boots in the
-background. Read readiness for the project seats, not only daemon health. If a
-seat has an authentication, trust or permission prompt, resolve the named
-prompt before assigning it work. A model pin is configuration; the native
-harness must report the intended model before consequential work.
+Preview the selected seats, models and resources. Plan checks resolution and
+preflight for the working directory. Launch starts the daemon if needed, with
+the kernel behavior above. Read readiness for the project seats, not only daemon
+health. Resolve a named authentication, trust or permission prompt before giving
+that seat work. No new team is needed when returning to an existing project.
 
 When a seat pauses, open its existing terminal with **o** in the startup view.
 Read the proposed command, working directory and target instance. For an intended
@@ -100,7 +139,7 @@ already have taken effect. A delivered message or disappearing prompt alone is
 not progress. If startup is still waiting for context delivery, use **c** for the
 same occupant, then **r** to refresh. Do not start another seat to clear a prompt.
 
-`first-project` is a deliberately small starting point, not a universal team.
+These starters are deliberately small starting points, not universal teams.
 For a different installed runtime or team shape, inspect `rig specs ls --kind
 rig` and `rig specs preview <name>` before selecting it. A seven-seat showcase
 is optional and consumes more concurrent capacity.
@@ -110,7 +149,7 @@ is optional and consumes more concurrent capacity.
 For example, in a project that imports CSV files:
 
 ```sh
-rig send dev-owner@first-project 'Improve the CSV import error when a required column is missing: name the column and leave the existing data unchanged. Add a regression check, ask dev-check for an independent check of the exact candidate, and record the result and how I can try it. Keep the change local; do not publish.'
+rig send "dev-owner@$starter" 'Improve the CSV import error when a required column is missing: name the column and leave the existing data unchanged. Add a regression check, ask dev-check for an independent check of the exact candidate, and record the result and how I can try it. Keep the change local; do not publish.'
 ```
 
 Replace the example with a real problem in your repository. Include what the
@@ -120,11 +159,12 @@ independent check. You should not have to relay the review between terminals.
 `rig send` is the initial conversation; the queue and repository artifacts
 retain the work. An unbound shell does not need to impersonate a queue owner.
 
-From an actual `first-project` seat, follow the work with
+Use the chosen rig name in its seat addresses (for example,
+`dev-owner@first-project-claude`). From an actual project seat, follow the work with
 `rig queue list --limit 1000`: its default scope is the caller's current rig.
 `queue list` has no `--rig` option. From an observer shell or another rig, use
-`rig queue list --destination dev-owner@first-project --limit 1000` and the same
-command for `dev-check@first-project`, after verifying those live addresses.
+`rig queue list --destination "dev-owner@$starter" --limit 1000` and the same
+command for `"dev-check@$starter"`, after verifying those live addresses.
 These show each destination's obligations, not a whole-rig view. An unbound shell
 must not pretend to be a seat to change scope; use `--all-rigs` only when that
 broader view is intended. Then read `rig queue show <id> --full` and
@@ -150,7 +190,7 @@ start or replace a terminal, so a missing binding is reported with recovery
 guidance rather than creating a second kernel.
 
 Herdr users follow the same launch and task path. To place the managed team in
-Herdr, use `rig terminal open first-project --provider herdr`; for the shared
+Herdr, use `rig terminal open "$starter" --provider herdr`; for the shared
 dashboard, use `rig terminal open kernel --provider herdr`. The equivalent
 cmux provider is also available. Read the opened/absent/degraded result: a
 partial terminal view is not a healthy team. Repeated terminal-open calls can
@@ -244,18 +284,30 @@ shows a small reviewed example and how to retain custody through a genuine wait.
 
 ## Have your agent configure permissions
 
-You choose the scope; the agent inspects the target harness and applies it.
-For example:
-
-> Configure persistent permission for OpenRig commands in this project. Explain
-> what the whole `rig` family allows and offer narrower verbs if appropriate.
-> Preserve existing deny/ask rules and unrelated settings, back up touched files,
-> apply my choice, then verify repeated ordinary reads without extra approvals.
-
-Allowing all `rig` commands includes lifecycle, topology and configuration
-operations, not only reads. Keeping prompts or selecting broader permissive
-operation are also valid choices. An existing explicit choice authorizes the
-routine setup; the agent need not ask you to approve each file edit again.
+Before team launch, your agent asks once, unless you already made an explicit
+choice for these harnesses and this scope:
+
+> Allow your agents to run OpenRig commands without repeated permission prompts?
+> **Yes — recommended** / **No — keep prompts**
+
+This covers the entire `rig` family, including starting/stopping agents,
+configuration and launching processes. It is not global YOLO or permission to
+invent work. The scope is your personal settings for this project unless you
+explicitly choose user-wide sessions, which can affect your other projects.
+
+On an actual **Yes**, the agent backs up the relevant files, adds the existing
+native rules without duplicates, and preserves stricter rules and unrelated
+settings. It checks bare and actual absolute-path invocations, rule loading and
+repeated harmless reads in the target conversation. No or no answer leaves
+settings alone and continues with existing prompts. Unsupported scope or a
+managed restriction is reported; it is not permission to grant broader access.
+
+The agent remembers an explicit choice, scope and exact additions in existing
+onboarding context, so setup does not ask again. You do not need to approve each
+routine edit separately. To undo, say **“Undo the OpenRig command allowances
+added by this setup; keep my other rules.”** The agent removes only its recorded
+additions, preserves earlier rules and later edits, and verifies reloading.
+Other pre-existing allowances may still permit commands after this undo.
 
 Use the maintained **Applying a permission policy** procedure:
 

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.1"
+version: "0.6.3"
 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/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.1"
+version: "0.6.3"
 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.1"
+version: "0.6.3"
 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/SKILL.md

@@ -1,12 +1,13 @@
 ---
 name: applying-a-permission-policy
 description: >-
-  Use when a user asks an agent to configure OpenRig command permissions, reduce
-  repeated native approval prompts, or apply a selected rig/seat permission policy.
+  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.
 metadata:
   openrig:
     stage: established
-    docs_checked: "2026-09-25"
+    docs_checked: "2026-09-29"
     verification_status: "Verify the installed harness version and effective settings; a rule-parser result is not a native permission test."
 ---
 
@@ -17,10 +18,40 @@ OpenRig operating posture, native command rules, sandbox access and launch flags
 are separate controls. A command rule grants execution capability, not authority
 to invent tasks, publish work or change another host.
 
+## Ask once before team launch
+
+Reuse an existing explicit choice for these harnesses and this scope from the
+user's onboarding context; do not ask again. Existing rules are configuration,
+not evidence of consent to expand their scope. Preserve them without expansion.
+If the choice is unknown, briefly explain:
+
+> This allows the whole `rig` command family, including starting/stopping agents,
+> changing OpenRig configuration and launching processes. It is not global YOLO
+> or permission to invent work. The scope is your personal settings for this
+> project unless you explicitly choose your user-wide sessions instead.
+>
+> Allow your agents to run OpenRig commands without repeated permission prompts?
+> **Yes — recommended** / **No — keep prompts**
+
+- **Yes:** require an actual affirmative answer, then apply the procedure below
+  at that scope for the selected harnesses. Never substitute user-wide rules
+  when project rules are unsupported. Native restrictions still apply.
+- **No:** leave permission settings unchanged and continue with existing prompts.
+- **No answer:** make no settings change, infer no consent and continue with
+  existing prompts. Do not keep asking during this setup.
+
+Remember an explicit Yes or No in the existing onboarding/project context the
+agent already reads: choice, harnesses and scope. For Yes, record the exact files
+and entries added, any pre-existing equivalents, and the loading/verification
+result. Do not add a preference service or native configuration key. No answer
+is not a remembered No. Offer broader permissive operation only as a separate
+explicit opt-in; the setup question does not select a builtin policy or mode.
+
 ## Choose the intended scope
 
-Use an existing explicit choice; otherwise explain these options and ask which
-the user wants. Do not ask again for routine steps already authorized.
+Outside the setup question above, use an existing explicit choice; otherwise
+explain these options and ask which the user wants. Do not reopen the menu after
+an answered setup question or ask again for routine steps already authorized.
 
 | Choice | What the agent configures |
 | --- | --- |
@@ -47,7 +78,14 @@ execution, an entire interpreter or a generic shell wrapper.
    hooks, auth, MCP, model settings and unrelated values. An allow must not erase
    a stricter rule or managed requirement. Report a real conflict instead of
    silently bypassing it.
+   Check both bare and actual absolute command spellings: a restriction on one
+   may not match the other. If a new allowance would evade a stricter restriction,
+   leave that addition unapplied and report the conflict; do not switch spellings
+   to bypass it.
 4. Back up touched files and merge only authorized additions, avoiding duplicates.
+   Recognize equivalent existing entries (including Claude's legacy `Bash(rig:*)`);
+   leave their markers untouched. Reapplying the same choice must be a no-op when
+   the required entries already exist, including no timestamp-only rewrite.
    The agent performs these edits; hand-editing is an option, not a required user
    chore. Apply the selected scope without another conversational permission round.
    Native enforcement still applies.
@@ -60,8 +98,15 @@ execution, an entire interpreter or a generic shell wrapper.
    not destructive probes. Report effective settings and remaining prompts.
    A parser match alone does not establish native behavior.
 
-For rollback, remove only this setup's additions, preserving later unrelated
-edits. Builtin policy specs remain read-only; customize in user space.
+Give the user this short undo: **“Undo the OpenRig command allowances added by
+this setup; keep my other rules.”** The agent removes only the recorded entries
+from their exact files, preserving pre-existing rules and subsequent edits.
+For Codex remove those `prefix_rule` entries; for Claude remove those
+`permissions.allow` entries. Delete a newly created rules file only if it still
+contains solely this setup's additions. Never restore the entire backup over
+later changes. Record the changed choice in the same context and verify native
+reloading/revocation; other pre-existing allowances may still permit `rig`.
+Builtin policy specs remain read-only; customize in user space.
 
 ## Codex command rules
 
@@ -103,8 +148,10 @@ codex execpolicy check --pretty --rules /absolute/path/to/openrig.rules -- print
 ```
 
 Inspect matches, not only exit status; repeat `--rules` for other effective
-files. A matching `prompt` or `forbidden` overrides allow. Verify rule loading
-in the target conversation after the required reload. For project-only scope,
+files. A matching `prompt` or `forbidden` overrides allow. The official procedure
+loads `.rules` at session startup; a file edit alone does not reload this turn.
+Preserve the conversation and use an authorized supported resume when needed,
+then verify loading in the target conversation. For project-only scope,
 confirm the layer is active there and absent from an unrelated project's active
 layers. An evaluator given an explicit `--rules` file proves matching, not that
 scope or automatic loading. Existing user-wide rules may already permit the
@@ -134,7 +181,9 @@ Current syntax uses ` *` for a command family; `Bash(rig:*)` is also supported.
 Narrower examples are `Bash(rig ps *)` and `Bash(rig queue list *)`.
 Preserve `deny`/`ask` entries and `defaultMode`; do not add `Bash(*)` or switch
 to bypass to resolve a mismatch. Inspect native `/permissions` and verify the
-actual command spelling.
+actual command spelling. A bare rule does not cover every absolute invocation:
+derive the actual executable and, after the stricter-rule check above, add its
+exact `Bash(/actual/path/to/rig *)` spelling if needed. Do not use a path wildcard.
 
 Choose scope using the [settings reference](https://code.claude.com/docs/en/settings):
 `.claude/settings.local.json` for personal project settings,
@@ -143,6 +192,9 @@ Choose scope using the [settings reference](https://code.claude.com/docs/en/sett
 Confirm the effective project root, especially for worktrees. Keep personal
 settings out of commits. Managed restrictions and sandbox/network controls
 still apply; a Bash allow is not a general network policy.
+Current Claude settings documentation describes live reload of permission
+edits. Confirm the rule's source in `/permissions` and repeated harmless calls
+in the target conversation; do not claim prompt behavior from JSON validity.
 
 ## Existing policies and broader modes
 
@@ -154,9 +206,10 @@ is unavailable, explain the remaining choice instead of selecting broader access
 
 For explicitly chosen broader operation, inspect
 `rig policy current --spec <user-owned-rig.yaml>` and the compatible getting-started guide's **Opt-in permissive
-operation** section. OpenRig's Codex `builtin:yolo` supplies `-s danger-full-access`;
-it does not itself select `approval_policy` and replaces a named
-`codex_config_profile` argument. Claude's corresponding launch flag is
+operation** section. OpenRig's Codex `builtin:yolo` supplies
+`-s danger-full-access -a never` and replaces a named `codex_config_profile`
+argument. The legacy environment-only YOLO path selects only the sandbox.
+Claude's corresponding launch flag is
 `--dangerously-skip-permissions`. Neither a resource `profile: default` nor OpenRig
 operating posture is a native permission policy. Do not change shipped defaults
 or assume editing a launch spec changes an existing seat.

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

@@ -1,10 +1,10 @@
 # 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.1"
+version: "0.6.3"
 taxonomy: "skills"
-purpose: "Use when a user asks an agent to configure OpenRig command permissions, reduce repeated native approval prompts, or apply a selected rig/seat permission policy."
+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:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "Use when a user asks an agent to configure OpenRig command permissions, reduce repeated native approval prompts, or apply a selected rig/seat permission policy."
+    summary: "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."

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.1"
+version: "0.6.3"
 taxonomy: "skills"
 purpose: "Use when a Claude Code session has just compacted, is about to compact, reached context limit, resumed after /compact, or needs to rebuild its working mental model from Claude JSONL transcripts and touched files."
 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.1"
+version: "0.6.3"
 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.1"
+version: "0.6.3"
 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:

package/daemon/context-packs/skills/core/cross-host-rig-commands/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: "cross-host-rig-commands"
-version: "0.6.1"
+version: "0.6.3"
 taxonomy: "skills"
 purpose: "Use when addressing a registered remote OpenRig host, choosing its transport, or interpreting a cross-host result."
 files: