@rosthq/cli 0.5.5 → 0.5.7

package/dist/index.js

@@ -41486,7 +41486,7 @@ var referenceDocuments = [
     order: 10,
     title: "{{brand}} implementation method",
     summary: "The staged operating-system setup path used by humans, CLI sessions, MCP clients, and in-app agents.",
-    version: "2026-06-16.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -41584,14 +41584,14 @@ The Compass is drafted, then activated by a human through supersession.
 
 ## When to stop for confirmation
 
-\`onboarding.advance_step\`, \`onboarding.finish\`, \`onboarding.create_invite\`, \`compass.approve_version\`, \`compass.reject_draft\`, \`compass.answer_gap\`, and \`compass.set\` are \`human_required\`. Attaching a reference document (\`onboarding.attach_reference\`) and drafting a Compass are safe for an agent; approving a version (a supersession) is a human act. The agent drafts and surfaces the approve link. See the confirmations guide.`
+\`onboarding.finish\`, \`compass.approve_version\`, \`compass.reject_draft\`, and \`compass.set\` are \`human_required\`. \`onboarding.advance_step\`, \`onboarding.create_invite\`, \`onboarding.attach_reference\`, \`compass.answer_gap\`, and drafting a Compass are \`none\` \u2014 none of them returns a pending confirmation. \`none\` is not the same as "agent-callable", though: \`onboarding.create_invite\` and \`compass.answer_gap\` record the human who ran them, so they run as a person, not from an agent session, while advancing a step, attaching a reference, and drafting a Compass are safe for an agent. Approving a version (a supersession) is a human act. The agent drafts and surfaces the approve link. See the confirmations guide.`
   },
   {
     slug: "responsibility-graph-playbook",
     order: 20,
     title: "Responsibility Graph playbook",
     summary: "How to build a functions-first graph with seats, owners, Stewards, vacancies, and clean authority.",
-    version: "2026-06-17.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "staffing"],
@@ -41688,7 +41688,7 @@ It ends every occupancy, archives the seat's active Charter, revokes the seat's
 
 ## When to stop for confirmation
 
-\`seat.create\`, \`seat.rename\`, \`seat.reparent\`, \`seat.set_type\`, and \`seat.decommission\` are \`human_required\`. Over MCP they return a pending confirmation with an approve link instead of mutating; the human approves with \`confirmation.approve\`. Never approve your own structural change from an agent session \u2014 surface the pending confirmation to a human. When a seat-targeted command does execute, its audit row is scoped to that seat (queryable by \`seat_id\`); on the deferred MCP path the executed audit is recorded against the human's \`confirmation.approve\`. See the confirmations guide.
+\`seat.reparent\`, \`seat.set_type\`, and \`seat.decommission\` are \`human_required\`; \`seat.create\` and \`seat.rename\` are \`none\`, so an agent can add and rename seats directly. The structural commands return a pending confirmation with an approve link over MCP instead of mutating; the human approves with \`confirmation.approve\`. Never approve your own structural change from an agent session \u2014 surface the pending confirmation to a human. When a seat-targeted command does execute, its audit row is scoped to that seat (queryable by \`seat_id\`); on the deferred MCP path the executed audit is recorded against the human's \`confirmation.approve\`. See the confirmations guide.
 
 ## Agent guidance
 
@@ -41769,7 +41769,7 @@ Drafting can be assisted by agents. Activation is a human decision. When authori
     order: 40,
     title: "Agent staffing playbook",
     summary: "How to decide whether a seat should be human, agent, or hybrid, and how to go live safely.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -41824,7 +41824,7 @@ Two creation paths, both draft-first. Read the stock-agents guide for templates
 
 ## When to stop for confirmation
 
-\`agent.create_from_template\`, \`agent.create_custom\`, \`agent.configure_tools\`, \`staffing.assign_user\`, \`agent.go_live\`, \`agent.update_schedule\`, and \`agent.decommission\` are \`human_required\`; \`mcp_token.create\` and \`credential.ingress\` are \`dangerous\`. An agent may draft, configure (with vault refs), and dry-run; the human approves go-live, credentials, schedule changes, and decommission. \`run_dry_run\` is ungated by human approval, but it is **precondition-gated**: the seat's permission manifest must be signed first (\`charter.sign_manifest\`). Attempting a dry run before sign-off returns a clean \`COMMAND_PRECONDITION_FAILED\` naming \`charter.sign_manifest\`, not a generic failure. Go-live after a passed dry run is \`human_required\`. See the confirmations guide.
+\`agent.create_from_template\`, \`agent.create_custom\`, \`staffing.assign_user\`, \`agent.go_live\`, \`agent.update_schedule\`, and \`mcp_token.create\` are \`human_required\`; \`agent.configure_tools\` and \`credential.ingress\` are \`credential_flow\` (both gate through the vault-backed credential path with human approval; \`agent.configure_tools\` stages the request and only \`credential.ingress\` takes the raw secret, as a vault reference); \`agent.decommission\` is \`dangerous\`. An agent may draft, configure (with vault refs), and dry-run; the human approves go-live, credentials, schedule changes, and decommission. \`run_dry_run\` is ungated by human approval, but it is **precondition-gated**: the seat's permission manifest must be signed first (\`charter.sign_manifest\`). Attempting a dry run before sign-off returns a clean \`COMMAND_PRECONDITION_FAILED\` naming \`charter.sign_manifest\`, not a generic failure. Go-live after a passed dry run is \`human_required\`. See the confirmations guide.
 
 ## Non-negotiables
 
@@ -41915,7 +41915,7 @@ In read-only or demo mode the **Add agent** affordance is disabled or routes to
     order: 42,
     title: "Design a custom agent",
     summary: "How to build a custom agent from operational questions through the Charter Builder, tools, dry run, and go-live without writing prompts.",
-    version: "2026-06-17.1",
+    version: "2026-06-18.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "charter_design"],
@@ -41971,18 +41971,18 @@ The same path is command-backed:
 
 ## Dry run and go-live
 
-The agent rehearses a representative task in a sandbox and is expected to escalate where the Charter requires it. A failed dry run keeps the draft and shows the reason so you can edit and rerun. When the dry run passes, a human promotes the agent live. The dry run rehearses the specific model tier you chose, so once it passes the model is locked \u2014 changing the model requires re-running the dry run on the new model before go-live.
+The dry run is a real sandbox rehearsal, not a stamp. It executes a mock-provider run derived from the Charter \u2014 the agent works against sandbox data only and is expected to escalate where the Charter's must-escalate clause requires it. The result is earned: a run that escalates the must-escalate boundary passes; a run that acts on that boundary instead of escalating fails. A failed dry run keeps the draft and shows the reason so you can edit and rerun. The rehearsal returns a transcript \u2014 the steps the agent took and the escalation it raised \u2014 shown step by step in the builder and printed by the CLI, so you can see the governance model working before anything goes live. When the dry run passes, a human promotes the agent live. The dry run rehearses the specific model tier you chose, so once it passes the model is locked \u2014 changing the model requires re-running the dry run on the new model before go-live.
 
 ## When to stop for confirmation
 
-\`agent.create_custom\`, \`agent.configure_tools\`, \`charter.sign_manifest\`, \`staffing.assign_user\`, and \`agent.go_live\` are \`human_required\`; \`credential.ingress\` is \`dangerous\`. \`agent.run_dry_run\` is ungated by human approval but **requires a signed manifest first** \u2014 a dry run before \`charter.sign_manifest\` returns a clean \`COMMAND_PRECONDITION_FAILED\` pointing at \`charter.sign_manifest\`. The go-live after a passed dry run is \`human_required\`. An agent may draft, configure (with vault refs), and dry-run; only a human approves the Charter, manifest, credentials, and go-live. A seat token can never create or approve its own setup. See the confirmations guide.`
+\`agent.create_custom\`, \`charter.sign_manifest\`, \`staffing.assign_user\`, and \`agent.go_live\` are \`human_required\`; \`agent.configure_tools\` and \`credential.ingress\` are \`credential_flow\` (both gate through the vault-backed credential path with human approval; \`agent.configure_tools\` stages the request and only \`credential.ingress\` takes the raw secret, as a vault reference). \`agent.run_dry_run\` is ungated by human approval but **requires a signed manifest first** \u2014 a dry run before \`charter.sign_manifest\` returns a clean \`COMMAND_PRECONDITION_FAILED\` pointing at \`charter.sign_manifest\`. The go-live after a passed dry run is \`human_required\`. An agent may draft, configure (with vault refs), and dry-run; only a human approves the Charter, manifest, credentials, and go-live. A seat token can never create or approve its own setup. See the confirmations guide.`
   },
   {
     slug: "sync-rhythm-playbook",
     order: 80,
     title: "Sync rhythm playbook",
     summary: "How Signal, Friction, Cascade, and Sync Briefs turn weekly meetings into decision time.",
-    version: "2026-06-17.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -42041,7 +42041,7 @@ Start with the exceptions, not a tour of every seat. Resolve the highest-value F
 
 ## When to stop for confirmation
 
-\`sync.run.start\`, \`sync.run.complete\`, and \`sync.item.assign\` are \`human_required\`; \`sync.brief.compile\` and \`sync.brief.get\` are not gated. Compiling the brief is safe for an agent to do before the meeting; starting, completing, and assigning follow-ups are human acts. An agent prepares the brief and proposed assignments and stops.
+\`sync.brief.compile\`, \`sync.brief.get\`, \`sync.run.start\`, \`sync.run.complete\`, and \`sync.item.assign\` are all \`none\`, so a tenant-admin seat runs the weekly rhythm directly without a per-action human gate. An agent can compile the brief and propose assignments ahead of the meeting; the human still owns the meeting and the decisions made in it, but {{brand}} does not force a confirmation on these commands themselves.
 
 ## After Sync
 
@@ -42052,7 +42052,7 @@ Decisions should be recorded as human decisions. Handoffs should attach to seats
     order: 45,
     title: "How agents work",
     summary: "How {{brand}} agents operate inside seats, use Charters, report work, and escalate beyond authority.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -42123,7 +42123,7 @@ A seat-scoped MCP token or the CLI runs the hand-shaped protocol. The server sti
 
 A seat-scoped MCP token already carries the seat, so its tools (\`rost_get_tasks\`, \u2026) need no seat argument. A tenant or owner CLI **session** does not, so pass \`--seat <seat-id>\` on seat-operating wrappers (an owner can target any seat in the tenant; a member only a seat they occupy). See "Seat scope" below.
 
-\`task.accept\`, \`task.decline\`, and \`task.complete\` are \`human_required\` for the acting human on the seat; \`status.record\`, \`work.log\`, and \`escalation.raise\` are not gated. An agent never approves a confirmation on behalf of a human.
+\`task.accept\`, \`task.decline\`, \`task.complete\`, \`status.record\`, \`work.log\`, and \`escalation.raise\` are all \`none\` \u2014 a seat operates its own queue and reports its own work directly. None of these carry a confirmation gate. An agent still never approves a human's confirmation on another seat's behalf; these are simply the acting seat's own reversible actions.
 
 ## What humans should review
 
@@ -42134,7 +42134,7 @@ Review the first dry runs, tool-call audit rows, escalations, and Signal impact.
     order: 46,
     title: "Tool access and vault",
     summary: "How to give agents access to tools without exposing raw credentials or expanding authority by accident.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing"],
@@ -42185,13 +42185,13 @@ Connecting a tool is a human-controlled step. The agent can recommend a tool, ex
 ## Connect tools and credentials from CLI or MCP
 
 - Stage tools on a draft agent: \`agent.configure_tools\` / \`rost_configure_agent_tools\` \u2014 connect or decline proposed tools and stage credential-ingress requests. Pass vault references, never raw secret material.
-- Store a secret: \`credential.ingress\` / \`rost_store_credential\` (scope: seat) persists only a vault reference. This command is \`dangerous\` \u2014 it returns a pending confirmation and runs only with a real human-provided secret.
+- Store a secret: \`credential.ingress\` / \`rost_store_credential\` (scope: seat) persists only a vault reference. \`credential.ingress\` is \`credential_flow\` \u2014 it returns a pending confirmation and runs only with a real human-provided secret, captured as a vault reference. (Because it redacts that secret, the pending confirmation also shows a high-risk badge \u2014 see the confirmations guide for badge-versus-level.)
 - Sign the manifest: \`charter.sign_manifest\` / \`rost_sign_charter_manifest\` requests human confirmation for the seat's permission manifest.
-- Mint local access: prefer \`{{cli}} mcp install\` for users; \`mcp_token.create\` is \`dangerous\` and returns the token once. List metadata with \`mcp_token.list\` (never token material); revoke with \`mcp_token.revoke\`.
+- Mint local access: prefer \`{{cli}} mcp install\` for users; \`mcp_token.create\` is \`human_required\` and returns the token once. List metadata with \`mcp_token.list\` (never token material); revoke with \`mcp_token.revoke\`.
 
 ## When to stop for confirmation
 
-\`credential.ingress\` and \`mcp_token.create\` are \`dangerous\`; \`charter.sign_manifest\`, \`agent.configure_tools\`, and \`mcp_token.revoke\` are \`human_required\`. Connecting a tool, storing a credential, or minting a token is a human-approved act. An agent drafts and explains; a human approves through the confirmation flow. Secrets never appear in prompts, logs, tool arguments, or an \`args_summary\`. See the confirmations guide.`
+\`credential.ingress\` and \`agent.configure_tools\` are \`credential_flow\`; \`charter.sign_manifest\`, \`mcp_token.create\`, and \`mcp_token.revoke\` are \`human_required\`. Connecting a tool, storing a credential, or minting a token is a human-approved act. An agent drafts and explains; a human approves through the confirmation flow. Secrets never appear in prompts, logs, tool arguments, or an \`args_summary\`. See the confirmations guide.`
   },
   {
     slug: "available-tools-guide",
@@ -42241,7 +42241,7 @@ Agents should explain the job, the required tool category, the minimum permissio
     order: 48,
     title: "CLI and MCP installation guide",
     summary: "Install the public CLI, register remote token-backed MCP clients, and find the full command and tool catalog.",
-    version: "2026-06-18.7",
+    version: "2026-06-18.10",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -42306,7 +42306,7 @@ The MCP server is remote and token-backed. There is no local MCP daemon to insta
 A headless agent cannot complete setup unattended. Two things always require a human, so plan to announce the handoff rather than stall silently:
 
 - **Device-code approval at first login.** \`{{cli}} login --device\` prints a code; a human must open the workspace URL in a browser, sign in with Google, match the code, and approve.
-- **Durable gated commands.** Setting or approving a Charter, staffing a seat, and taking an agent live each open a confirmation that a human approves (an agent never approves its own request \u2014 see the confirmations-guide). The CLI surfaces the \`confirmation_id\` and an \`approveVia\` URL for the human. (\`{{cli}} mcp install\` is the exception: it completes its own token-mint approval inline for the operator who runs it \u2014 see Approving the token mint below \u2014 so it is not a separate browser handoff.)
+- **Durable gated commands.** Setting or approving a Charter, staffing a seat, and taking an agent live each open a confirmation that a human approves (an agent never approves its own request \u2014 see the confirmations-guide). The CLI surfaces the \`confirmation_id\` and an \`approveVia\` URL for the human. (\`{{cli}} mcp install\` is a partial exception: for an **interactive** operator it completes its own token-mint approval inline; in a **headless/agent** session it surfaces the confirmation and stops unless \`--skip-permissions\` / \`{{envPrefix}}_CLI_SKIP_PERMISSIONS=1\` is set \u2014 see Approving the token mint below.)
 
 Treat these as blocking prerequisites: the agent prepares the request and waits for the human approver.
 
@@ -42420,6 +42420,8 @@ Or use the one-shot helper: \`{{cli}} init\` logs in when needed, optionally sel
 
 A direct \`mcp install\` now **requires an explicit \`--scope\`** \u2014 there is no silent default. Choose \`--scope seat --seat-id <id>\` (the narrowest scope, limited to one seat's Charter and permission manifest \u2014 prefer it for day-to-day operation) or \`--scope tenant-admin\` (can administer the whole company \u2014 reserve it for initial setup). Running \`mcp install\` without \`--scope\` errors and mints nothing, naming both options. (The first-run helper \`{{cli}} init\` is the exception: it defaults to \`--scope tenant-admin\` because no seats exist yet at setup; and \`--rotate\` inherits the old token's scope, so it does not need \`--scope\` either.)
 
+\`mcp install\` accepts an optional \`--skip-permissions\` flag (equivalently \`{{envPrefix}}_CLI_SKIP_PERMISSIONS=1\`). It governs the token-mint approval in a non-interactive session \u2014 see Approving the token mint below. An interactive operator never needs it.
+
 Claude Code (tenant-admin):
 
 \`\`\`bash
@@ -42450,9 +42452,13 @@ The \`<seat-id>\` comes from \`{{cli}} command seat.create\` output or \`rost_ge
 
 ### Approving the token mint
 
-Minting a token is a human-gated authority change at the command layer. For an interactive operator, \`{{cli}} mcp install\` completes that approval **inline**: the operator who ran the command is the human in the loop, so the CLI runs the gated mint, completes the confirmation for that same command, and prints the registration block \u2014 a single step, no separate URL to click.
+Minting a token (and the inline revoke that \`--rotate\` performs) is a human-gated authority change at the command layer. How \`{{cli}} mcp install\` handles that approval depends on whether it runs in an interactive session:
 
-The broader rule still holds for durable changes an agent proposes \u2014 charters, decisions, compass and charter amendments \u2014 where an agent never approves its own request and a human approves the surfaced \`approveVia\` confirmation. See the confirmations-guide for the four confirmation levels and that flow. (For a fully unattended headless agent session, treat the inline mint as the one place the running operator's identity stands in for the approval; if you need a separate human in that loop, raise it with your operator.)
+- **Interactive operator (a human at a real terminal).** The CLI completes the approval **inline**: the operator who ran the command is the human in the loop, so it runs the gated mint, completes the confirmation for that same command, and prints the registration block \u2014 a single step, no separate URL to click.
+- **Non-interactive / headless / agent session.** The CLI does **not** approve its own request. By default it **surfaces the confirmation and stops**, minting nothing: it prints the \`confirmation_id\`, the exact \`{{cli}} command confirmation.approve --json '{"confirmation_id":"<id>"}'\` command, and the \`approveVia\` URL when the server provided one, then exits non-zero ("pending human approval"). A human then approves it (in a browser or with that approve command) \u2014 and that approval **executes the mint and returns the token in the approve output** (shown once), so register it with your client from there. Do **not** re-run \`mcp install\` after approving: that starts a second mint and orphans the first token. (For an unattended agent that should mint and register in one step, use \`--skip-permissions\` below.)
+- **Opting into auto-approval in a headless session.** Pass \`--skip-permissions\` on \`mcp install\`, or set \`{{envPrefix}}_CLI_SKIP_PERMISSIONS=1\`, to auto-approve the mint/revoke confirmation inline even without a TTY. This is a deliberate loosening (the running session stands in for the human approver) \u2014 use it only for trusted automation where you accept that the agent approves its own token mint.
+
+The broader rule still holds for durable changes an agent proposes \u2014 charters, decisions, compass and charter amendments \u2014 where an agent never approves its own request and a human approves the surfaced \`approveVia\` confirmation. See the confirmations-guide for the four confirmation levels and that flow.
 
 ### Handling the printed token (read this before you paste anything)
 
@@ -42654,8 +42660,9 @@ These ergonomic wrappers (including the \`{{cli}} agent\` group) require **{{cli
 
 | Command | Purpose | Scope | Safe example |
 |---|---|---|---|
-| \`{{cli}} mcp install --client claude-code|codex|cursor --scope tenant-admin|seat [--seat-id <id>] [--expires-in <days>|--no-expiry]\` | **Direct install** syntax. \`--scope\` is **required** (seat is narrower \u2014 prefer it for day-to-day; tenant-admin can administer the whole company). \`--expires-in <days>\` (1..365) or \`--no-expiry\` sets the token TTL (default 90 days). | Tenant | \`{{cli}} mcp install --client codex --scope tenant-admin --expires-in 30\` |
+| \`{{cli}} mcp install --client claude-code|codex|cursor --scope tenant-admin|seat [--seat-id <id>] [--expires-in <days>|--no-expiry] [--skip-permissions]\` | **Direct install** syntax. \`--scope\` is **required** (seat is narrower \u2014 prefer it for day-to-day; tenant-admin can administer the whole company). \`--expires-in <days>\` (1..365) or \`--no-expiry\` sets the token TTL (default 90 days). \`--skip-permissions\` auto-approves the token-mint confirmation in a non-interactive session (see below). | Tenant | \`{{cli}} mcp install --client codex --scope tenant-admin --expires-in 30\` |
 | \`{{cli}} mcp install --client claude-code|codex|cursor --rotate <old-token-id>  (inherits the old token's scope; no --scope)\` | **Rotate** syntax. Mints a replacement, **inherits the old token's scope/seat** (so do not pass \`--scope\`), prints the new registration block, and revokes the old token. | Tenant | \`{{cli}} mcp install --client codex --rotate <old-token-id>\` |
+| \`{{cli}} mcp install ... --skip-permissions  (or {{envPrefix}}_CLI_SKIP_PERMISSIONS=1 \u2014 auto-approves the token-mint confirmation in a non-interactive session)\` | **Skip-permissions** opt-in. In a headless/agent session, auto-approve the \`human_required\` token-mint (and rotate revoke) confirmation inline instead of surfacing it for a human (a deliberate loosening). An interactive operator never needs it. | Tenant | \`{{cli}} mcp install --client codex --scope seat --seat-id <seat-id> --skip-permissions\` |
 | \`{{cli}} mcp install --client claude-code --scope tenant-admin\` | Mint a tenant-admin MCP token and print a Claude Code registration command. | Tenant | \`{{cli}} mcp install --client claude-code --scope tenant-admin\` |
 | \`{{cli}} mcp install --client codex --scope tenant-admin\` | Mint a tenant-admin MCP token and print Codex TOML. | Tenant | \`{{cli}} mcp install --client codex --scope tenant-admin\` |
 | \`{{cli}} mcp install --client cursor --scope tenant-admin\` | Mint a tenant-admin MCP token and print Cursor JSON. | Tenant | \`{{cli}} mcp install --client cursor --scope tenant-admin\` |
@@ -42748,6 +42755,8 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_update_agent_setup\` | \`agent_setup.update\` | Update parent, steward, lane, schedule, or answers on a setup draft. | Tenant | Call with \`setup_id\` and the fields to change. |
 | \`rost_update_agent_schedule\` | \`agent.update_schedule\` | Update a draft or live agent's scheduled execution. | Tenant | Call with \`agent_id\` and \`schedule_cron\`; expect human confirmation. |
 | \`rost_decommission_agent\` | \`agent.decommission\` | Retire an agent occupancy safely (no-orphan guarded). | Tenant | Call with \`agent_id\`; expect human confirmation. |
+| \`rost_pause_agent\` | \`agent.pause\` | Pause a live agent so it stops scheduled and on-demand runs; reversible. | Tenant | Call with \`seat_id\`; expect human confirmation. |
+| \`rost_resume_agent\` | \`agent.resume\` | Resume a paused agent back to live (no-orphan guarded). | Tenant | Call with \`seat_id\`; expect human confirmation. |
 | \`rost_create_custom_agent\` | \`agent.create_custom\` | Create a draft custom agent shell and draft Charter seed from operational answers. | Tenant | Call with \`seat_id\` and operational answers; expect human confirmation. |
 | \`rost_configure_agent_tools\` | \`agent.configure_tools\` | Connect or decline proposed tools and stage credential-ingress requests (vault refs only). | Seat or tenant-admin | Never send raw secrets; expect a credential confirmation. |
 | \`rost_run_agent_dry_run\` | \`agent.run_dry_run\` | Run the sandbox dry run for a draft agent; durable and idempotent per Charter version. | Seat or tenant-admin | Call after the manifest is signed; ungated by human approval, but precondition-gated on a signed manifest. |
@@ -42784,7 +42793,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_update_friction_issue_status\` | \`friction.update_status\` | Move a non-terminal issue between open and diagnosing. | Seat or tenant-admin | Call with \`issue_id\` and \`status\`. |
 | \`rost_resolve_friction_issue\` | \`friction.resolve\` | Resolve an issue with a root cause and remediation task. | Tenant | Human decision; expect confirmation. |
 | \`rost_link_task_to_friction_issue\` | \`friction.link_task\` | Attach an existing task as an issue's action task. | Seat or tenant-admin | Call with \`issue_id\` and \`task_id\`. |
-| \`rost_create_task\` | \`task.create\` | Create a task (a commitment between seats). | Seat or tenant-admin | Agent proposals land in draft for confirmation. |
+| \`rost_create_task\` | \`task.create\` | Create a task (a commitment between seats). | Seat or tenant-admin | \`none\` \u2014 created directly; the owning seat accepts or declines. |
 | \`rost_compile_sync_brief\` | \`sync.brief.compile\` | Compile the weekly Sync Brief (idempotent per period). | Tenant | Call with \`{}\`. |
 | \`rost_get_sync_brief\` | \`sync.brief.get\` | Read the latest or a specific Sync Brief and agenda. | Seat or tenant-admin | Call with \`{}\` or \`{"sync_brief_id":"<id>"}\`. |
 | \`rost_start_sync_run\` | \`sync.run.start\` | Ensure a Sync Brief exists so the meeting can begin. | Tenant | Call with \`{}\`. |
@@ -42852,7 +42861,7 @@ These rows are quick, at-a-glance triage. For deeper auth, tenant, scope, confir
     order: 49,
     title: "Agent reference map",
     summary: "Where CLI sessions, MCP clients, and in-app agents should retrieve {{brand}} guidance before recommending setup changes.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -42903,7 +42912,7 @@ Never guess a command's JSON shape. Before calling a command that changes state,
 - List every callable command: {{cli}} command list (CLI) or rost_list_commands (MCP)
 - Read one command's exact input/output schema, help pointer, and a worked example: {{cli}} command schema <id> (CLI) or rost_describe_command with {"command_id":"<id>"} (MCP)
 - List the tool catalog the agent builder reads (id, scope tiers, credential requirement, access policy \u2014 configuration only; the tools do not execute yet): {{cli}} tools list (CLI) or rost_list_tool_catalog (MCP)
-- Show a Compass, Charter, or agent setup as a markdown card to review with your human: {{cli}} compass show --markdown, {{cli}} charter show <seat> --markdown, {{cli}} agent show <seat> --markdown
+- Show a Compass, Charter, or agent setup as a markdown card to review with your human: {{cli}} compass show --markdown, {{cli}} charter show --seat-id <id> --markdown, {{cli}} agent show --seat-id <id> --markdown
 
 When a command fails, the error returns a machine-readable code, a message, and a help field naming the exact command to run next. Read the help field and run the command it points at \u2014 do not retry the same call blindly. A failed precondition (for example a manifest not yet signed, or a dry run that has not passed) returns COMMAND_PRECONDITION_FAILED with a help pointer, not an opaque internal error.
 
@@ -42971,7 +42980,7 @@ Retrieve the narrowest relevant guide before making a setup recommendation. Pref
     order: 60,
     title: "Cascade guide",
     summary: "How to connect company goals to seat-level work without turning {{brand}} into a project-management tool.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43025,7 +43034,7 @@ Do not put every task into Cascade. Small errands, private notes, and work with
 
 ## When to stop for confirmation
 
-\`goal.create\`, \`goal.set_status\`, \`goal.reparent\`, and \`goal.drop\` are \`human_required\`. Moving or dropping a goal changes how the company reads its own progress, so it returns a pending confirmation over MCP. An agent proposes the branch and surfaces the approve link; a human decides.
+\`goal.reparent\` and \`goal.drop\` are \`human_required\`; \`goal.create\`, \`goal.set_status\`, and \`goal.update\` are \`none\`, so a seat can add goals and update their status directly. Moving or dropping a goal changes how the company reads its own progress, so it returns a pending confirmation over MCP. An agent proposes the branch and surfaces the approve link; a human decides.
 
 ## Agent guidance
 
@@ -43036,7 +43045,7 @@ Agents can suggest commitments and report progress. They should not create a new
     order: 61,
     title: "Signal guide",
     summary: "How to define and read measurables so the company runs on evidence instead of status theater.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43086,7 +43095,7 @@ Avoid vanity numbers, manual-only status fields, and metrics nobody can act on.
 
 ## When to stop for confirmation
 
-\`signal.confirm_reading\` and \`signal.correct_reading\` are \`human_required\` \u2014 verifying or overwriting a measurable is a human judgment. An agent records readings with evidence; a human confirms or corrects.
+\`signal.correct_reading\` is \`human_required\`; overwriting a recorded measurable is a human judgment. \`signal.confirm_reading\` is \`none\`, so a seat can confirm its own readings directly. An agent records readings with evidence; a human corrects when a value is wrong.
 
 ## Agent guidance
 
@@ -43097,7 +43106,7 @@ Agents may record readings when the Charter allows it. Agent-reported readings s
     order: 62,
     title: "Friction guide",
     summary: "How to capture issues with evidence, rank them, and resolve them without losing ownership.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -43151,12 +43160,12 @@ Agents should file Friction when a measurable breaks, a tool fails, a repeated e
 Friction, tasks, and escalations are the issue-to-action loop. A seat files, a task carries the work, and an escalation routes a decision a seat cannot make alone.
 
 - File and triage: \`{{cli}} friction file ...\` / \`friction.file_issue\` (seat) / \`rost_file_issue\`; list with \`{{cli}} friction list --status open --json\` / \`friction.list\` / \`rost_list_friction_issues\`; move between open and diagnosing with \`friction.update_status\` / \`rost_update_friction_issue_status\`.
-- Carry the work as a task: \`task.create\` / \`rost_create_task\` (a commitment between seats; agent proposals land in draft for confirmation). A seat runs its queue with \`{{cli}} task list|accept|decline|complete\` (\`task.list\`, \`task.accept\`, \`task.decline\`, \`task.complete\`). Link a task to an issue with \`friction.link_task\` / \`rost_link_task_to_friction_issue\`.
+- Carry the work as a task: \`task.create\` / \`rost_create_task\` (a commitment between seats). \`task.create\` is \`none\` (no confirmation gate), so an agent can file one directly; an agent's task lands as a **draft** proposal (\`origin: agent_proposal\`) for a human to review and hand off \u2014 not a live offer in the owning seat's accept/decline queue. A seat runs its queue with \`{{cli}} task list|accept|decline|complete\` (\`task.list\`, \`task.accept\`, \`task.decline\`, \`task.complete\`). Link a task to an issue with \`friction.link_task\` / \`rost_link_task_to_friction_issue\`.
 - Route a decision: \`escalation.raise\` (seat) / \`rost_escalate\` sends approval-scope or must-escalate work to the Steward queue. Reads are \`escalation.list\` / \`escalation.get\`. See the steward queue guide for resolution.
 
 ## When to stop for confirmation
 
-\`friction.resolve\`, \`friction.link_task\`, \`task.create\`, \`task.accept\`, \`task.decline\`, and \`task.complete\` are \`human_required\`; \`friction.update_status\`, \`escalation.raise\`, \`friction.file_issue\`, and \`friction.list\` are not gated. Resolving an issue or creating a cross-seat commitment is a human decision. An agent files Friction, proposes the task, and escalates; a human resolves and accepts.
+\`friction.resolve\` is \`human_required\`; resolving an issue is a human decision. \`friction.link_task\`, \`task.create\`, \`task.accept\`, \`task.decline\`, and \`task.complete\` are \`none\`, so a seat files issues, creates commitments, and runs its own task queue directly. \`friction.update_status\`, \`escalation.raise\`, \`friction.file_issue\`, and \`friction.list\` are also not gated. An agent files Friction, proposes the task, and escalates; a human resolves.
 
 ## Resolution rule
 
@@ -43167,7 +43176,7 @@ Resolving Friction should produce one of four outcomes: a decision, a task, a Ch
     order: 70,
     title: "Steward queue guide",
     summary: "How Stewards review escalations, approve agent boundaries, and keep agents accountable.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43207,7 +43216,7 @@ Read the seat, Charter, evidence, and recommended action. Decide the narrow ques
 The Steward reads the queue from any surface but decides as a human.
 
 - Read: \`{{cli}} escalation list --json\` / \`escalation.list\` / \`rost_list_escalations\` (own steward chain for humans, own seat for agents). Read one with \`{{cli}} escalation get\` / \`escalation.get\` / \`rost_get_escalation\` \u2014 evidence, recommendation, and decision state.
-- Decide: \`{{cli}} escalation resolve\` / \`escalation.resolve\` and \`{{cli}} escalation reject\` / \`escalation.reject\`. These commands are \`human_required\` and are deliberately NOT exposed over MCP \u2014 \`decisions.decided_by\` must be a human, so there is no \`rost_resolve_escalation\` tool. The CLI runs them as the authenticated human; an agent session must hand the decision to a person.
+- Decide: \`{{cli}} escalation resolve\` / \`escalation.resolve\` and \`{{cli}} escalation reject\` / \`escalation.reject\`. \`escalation.resolve\` and \`escalation.reject\` are \`none\` at the confirmation layer, but they are deliberately NOT exposed over MCP \u2014 \`decisions.decided_by\` must be a human, so there is no \`rost_resolve_escalation\` tool. They are kept human-only by that MCP exclusion plus the human-only \`decided_by\`, not by a confirmation gate. The CLI runs them as the authenticated human; an agent session must hand the decision to a person.
 - Approve gated requests: when an escalation or Charter change produces a pending confirmation, the human approves with \`confirmation.approve\` (or rejects with \`confirmation.reject\`). Go-live runs through \`agent.go_live\`.
 
 ## When to stop for confirmation
@@ -43223,7 +43232,7 @@ Keep agent scope tight at first. Approve more autonomy only after evidence. Use
     order: 71,
     title: "Confirmations and human gates guide",
     summary: "How {{brand}} routes authority-changing work through human confirmation, and why agents never approve their own requests.",
-    version: "2026-06-15.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "charter_design", "staffing", "operating_rhythm"],
@@ -43247,10 +43256,12 @@ Keep agent scope tight at first. Approve more autonomy only after evidence. Use
 
 ## Confirmation levels
 
-- \`none\`: safe to run directly. Reads and reversible drafts (graph reads, \`charter.draft\`, \`status.record\`, \`sync.brief.compile\`).
-- \`human_required\`: a human must approve. Structural, staffing, resolution, and go-live commands (\`seat.create\`, \`charter.approve\`, \`goal.reparent\`, \`friction.resolve\`, \`agent.go_live\`, \`escalation.resolve\`).
-- \`dangerous\`: a human must approve and the request is flagged high-risk because it touches secrets or tokens (\`credential.ingress\`, \`mcp_token.create\`, \`tenant.anthropic_key.save\`, \`confirmation.approve\` itself).
-- \`credential_flow\`: routes through the vault-backed credential path so a secret is captured as a vault reference, never stored or logged in the clear.
+- \`none\`: no confirmation gate \u2014 the command never returns a pending confirmation. Most are reads or reversible drafts an agent can run directly, including over MCP (graph reads, \`charter.draft\`, \`status.record\`, \`sync.brief.compile\`, \`sync.run.start\`, \`task.complete\`). A few \`none\` commands still require a human actor or an interactive channel \u2014 \`confirmation.approve\` is \`none\` (approving a gate cannot itself be gated) yet runs only as a human in the UI or CLI \u2014 so \`none\` means "no confirmation gate", not always "agent-callable".
+- \`human_required\`: a human must approve. Structural, staffing, resolution, and go-live commands (\`seat.reparent\`, \`charter.approve\`, \`goal.reparent\`, \`friction.resolve\`, \`agent.go_live\`, \`mcp_token.create\`).
+- \`credential_flow\`: routes through the vault-backed credential path so a secret is captured as a vault reference, never stored or logged in the clear (\`credential.ingress\`, \`tenant.anthropic_key.save\`; \`agent.configure_tools\` is \`credential_flow\` too \u2014 it stages credential-ingress requests through the same path without ever taking raw secret material).
+- \`dangerous\`: the highest-risk human gate. Only two commands carry it \u2014 \`settings.update\` and \`agent.decommission\`.
+
+The \`dangerous\` confirmation **level** is rare and is not the same as the **risk badge** a pending confirmation can display. The badge shows "dangerous" whenever a command's confirmation level is \`dangerous\` **or** the command redacts secrets (its audit redaction is \`secret_strict\`), so a \`credential_flow\` command such as \`credential.ingress\` shows the dangerous badge while still gating through the credential path \u2014 not the \`dangerous\` level. Read the badge as "handle with care" and the confirmation level as "who must approve". \`confirmation.approve\` and \`confirmation.reject\` are themselves \`none\` \u2014 approving a gate cannot itself require approval.
 
 ## What a gated command returns over MCP
 
@@ -43389,7 +43400,7 @@ Every notification should include the seat, cause, evidence, and requested decis
     order: 75,
     title: "Local runner guide",
     summary: "How local agent sessions and runner surfaces should operate through {{brand}} without bypassing Charters or audit.",
-    version: "2026-06-13.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["staffing", "operating_rhythm"],
@@ -43424,7 +43435,7 @@ The local runner is for human-controlled local agent work. It should retrieve {{
 
 ## When to stop for confirmation
 
-\`runner.pairing.start\`, \`runner.revoke\`, \`work_order.enqueue\`, and \`work_order.cancel\` are \`human_required\`; list and status reads are not gated. Pairing, revoking, and queuing or cancelling work are human-approved. An agent inspects runner state and proposes the action.
+\`runner.revoke\` and \`work_order.cancel\` are \`human_required\`; \`runner.pairing.start\` and \`work_order.enqueue\` are \`none\`, so an operator can pair a runner and queue work directly. List and status reads are not gated. Revoking a runner or cancelling work is the human-approved act. An agent inspects runner state and proposes the action.
 
 ## Guardrails
 
@@ -43545,7 +43556,7 @@ Templates may draft. Humans approve. A stock agent should not go live until a hu
     order: 77,
     title: "Troubleshooting guide",
     summary: "How users and agents should diagnose common setup, tool, Signal, Friction, and MCP problems.",
-    version: "2026-06-18.3",
+    version: "2026-06-18.4",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing", "operating_rhythm"],
@@ -43604,7 +43615,7 @@ These are the common blockers when adding an agent (see the add-agents guide and
 
 ## When to stop for confirmation
 
-Most reads are safe to run while diagnosing. Any fix that changes authority, credentials, go-live state, or a durable decision is \`human_required\` or \`dangerous\` and routes through \`confirmation.approve\`. Diagnose freely; stop before approving.
+Most reads are safe to run while diagnosing. Any fix that changes authority, credentials, go-live state, or a durable decision is gated \u2014 \`human_required\`, \`credential_flow\`, or \`dangerous\` \u2014 and routes through a human confirmation (\`confirmation.approve\`). Diagnose freely; stop before approving.
 
 ## Agent guidance
 
@@ -43843,7 +43854,7 @@ A consultancy's purpose might be "Make expert tax guidance affordable for first-
     order: 31,
     title: "Charter authoring deep-dive",
     summary: "The full Charter document contract field by field \u2014 decision authority, escalation, measurables, budget, permissions \u2014 with worked examples for human, agent, and hybrid seats.",
-    version: "2026-06-16.1",
+    version: "2026-06-18.1",
     public: true,
     audiences: ["cli", "mcp", "in_app_agent"],
     stages: ["charter_design", "staffing"],
@@ -43887,7 +43898,7 @@ A Charter is a seat's executable operating contract. On the CLI and MCP path you
 - **decision_authority** \u2014 the heart of the contract, split three ways:
   - **autonomous** \u2014 what the seat may do without asking. Each item is \`{ action, condition, rationale, unanswered_boundary }\`. Only reversible, low-risk, in-scope actions belong here. An autonomous item must have \`unanswered_boundary: false\` \u2014 the schema rejects an autonomous item with an unanswered boundary (push it to escalate instead).
   - **approval** \u2014 the can-do-with-a-yes set: durable, money-moving, external-send, staffing, or policy actions that require explicit human approval. Name the **threshold** in the \`condition\` (e.g. "before posting or sending," "over $5,000").
-  - **escalate** (1+) \u2014 the must-ask set: ambiguous authority, irreversible actions, credentials, legal or financial exposure, customer-impacting exceptions. At least one escalate item must carry \`unanswered_boundary: true\` so unresolved boundaries default conservative.
+  - **escalate** (1+) \u2014 the must-ask set: ambiguous authority, irreversible actions, credentials, legal or financial exposure, customer-impacting exceptions. At least one escalate item should carry \`unanswered_boundary: true\` so unresolved boundaries default conservative. The submit schema does not strictly require it, but the direct submit path (\`charter.update_draft\` / \`charter.set\`) does not add one for you \u2014 it only records the boundaries you flag \u2014 so include one whenever a boundary is unresolved.
 - **escalation_rules** (1+) \u2014 plain-language rules that trigger escalation, beyond the structured authority items. "Escalate any invoice over $5,000 or from a vendor not already in the ledger."
 - **measurables** (1+) \u2014 each \`{ name, target, cadence, source }\`. A measurable must measure the accountability, not vanity. \`cadence\` is \`daily|weekly|monthly|quarterly\`; \`source\` is \`human|agent|integration\`. Agent-sourced readings are unconfirmed until a human confirms them.
 - **permission_manifest** \u2014 each \`{ tool, scope, granted, rationale }\`. Map each accountability to the narrowest tool scope that performs it. Prefer draft/read scopes; a send or spend scope is a deliberate, justified grant. The manifest is what the tool-guard enforces and what a human signs.
@@ -44268,9 +44279,14 @@ var mcpTokenListEntrySchema = external_exports.object({
 var mcpTokenListOutputSchema = external_exports.object({
   tokens: external_exports.array(mcpTokenListEntrySchema)
 }).passthrough();
+var approveViaSchema = external_exports.object({
+  webUrl: external_exports.string().min(1).optional(),
+  cliCommand: external_exports.string().min(1).optional()
+}).passthrough();
 var pendingConfirmationSchema = external_exports.object({
   confirmationId: external_exports.string().min(1),
-  commandId: external_exports.string().min(1)
+  commandId: external_exports.string().min(1),
+  approveVia: approveViaSchema.optional().catch(void 0)
 }).passthrough();
 var confirmationApprovalOutputSchema = external_exports.object({
   confirmation_id: external_exports.string().min(1),
@@ -44286,6 +44302,7 @@ function parseMcpInstallOptions(args) {
   let expiresInDays;
   let noExpiry = false;
   let rotateTokenId;
+  let skipPermissions = false;
   for (let index = 0; index < args.length; index += 1) {
     const arg = args[index];
     if (arg === "--client") {
@@ -44308,6 +44325,8 @@ function parseMcpInstallOptions(args) {
       index += 1;
     } else if (arg === "--json") {
       json2 = true;
+    } else if (arg === "--skip-permissions") {
+      skipPermissions = true;
     } else {
       throw new Error(`Unknown mcp install option: ${arg}`);
     }
@@ -44328,24 +44347,71 @@ function parseMcpInstallOptions(args) {
     ...seatId === void 0 ? {} : { seatId },
     json: json2,
     expiry,
-    ...rotateTokenId === void 0 ? {} : { rotateTokenId }
+    ...rotateTokenId === void 0 ? {} : { rotateTokenId },
+    skipPermissions
   };
 }
 var MISSING_SCOPE_MESSAGE = `${cliBrand.binName} mcp install requires an explicit --scope. Choose: --scope seat --seat-id <id> (narrower \u2014 limited to one seat's Charter and permission manifest; prefer this for day-to-day operation), or --scope tenant-admin (can administer the whole company \u2014 reserve it for initial setup). Find a seat id with: ${cliBrand.binName} command graph.get --json '{}'.`;
 var MCP_TOKEN_CAUTION = "Security: this minted MCP token is a live credential that lands in the client's plaintext config \u2014 prefer the narrowest scope (--scope seat --seat-id <id>) and revoke it immediately if it leaks.";
 var NO_EXPIRY_WARNING = "Warning: --no-expiry mints a token with no practical expiry (a ~100-year TTL). This is a long-lived credential by choice \u2014 rotate it deliberately and revoke immediately if it leaks.";
+var PendingConfirmationError = class extends Error {
+  confirmationId;
+  commandId;
+  approveCommand;
+  approveUrl;
+  constructor(input) {
+    super(`Pending human approval for ${input.commandId} (confirmation ${input.confirmationId}).`);
+    this.name = "PendingConfirmationError";
+    this.confirmationId = input.confirmationId;
+    this.commandId = input.commandId;
+    this.approveCommand = input.approveCommand;
+    if (input.approveUrl !== void 0) {
+      this.approveUrl = input.approveUrl;
+    }
+  }
+  // The multi-line human-handoff message rendered on stderr by the caller. It
+  // names the gated command, the confirmation id, the exact approve command, and
+  // the approveVia URL when the server provided one.
+  toHandoffMessage() {
+    const isRevoke = this.commandId === "mcp_token.revoke";
+    const lines = isRevoke ? [
+      `Pending human approval: revoking the old token (${this.commandId}) requires a human to approve confirmation ${this.confirmationId}.`,
+      "The new token was minted and registered, but the OLD token is still live until its revocation is approved.",
+      `Approve the revocation: ${this.approveCommand}`
+    ] : [
+      `Pending human approval: ${this.commandId} requires a human to approve confirmation ${this.confirmationId} before the MCP token is minted.`,
+      "This is a non-interactive session and --skip-permissions is not set, so nothing was minted yet.",
+      // confirmation.approve EXECUTES the deferred mint and returns the token in
+      // its own output (shown once) — it does not just unlock a re-run. So the
+      // approver registers the token from that output; re-running mcp install
+      // would start a SECOND mint and orphan the first.
+      `A human approves with: ${this.approveCommand} \u2014 this mints the token and returns it in that command's output (shown once). Register it with your client from there; do not re-run mcp install afterward (that starts a new mint).`
+    ];
+    if (this.approveUrl !== void 0) {
+      lines.push(`Or approve in a browser: ${this.approveUrl}`);
+    }
+    lines.push(
+      `To auto-approve inline in a headless session instead, pass --skip-permissions or set ${brandEnvKey3("CLI_SKIP_PERMISSIONS")}=1 (a deliberate loosening).`
+    );
+    return lines.join("\n");
+  }
+};
+function brandEnvKey3(suffix) {
+  return `${cliBrand.envPrefix}_${suffix}`;
+}
 async function renderMcpInstall(input) {
   const stderrLines = [];
+  const canAutoApprove = input.canAutoApprove ?? false;
   if (input.options.rotateTokenId === void 0 && input.options.scope === void 0) {
     throw new Error(MISSING_SCOPE_MESSAGE);
   }
-  const mintScope = input.options.rotateTokenId === void 0 ? { scope: input.options.scope, ...input.options.seatId === void 0 ? {} : { seatId: input.options.seatId } } : await resolveRotationScope(input.client, input.options);
-  const token = await createMcpToken(input.client, mcpTokenCreateBody(mintScope, input.options.expiry));
+  const mintScope = input.options.rotateTokenId === void 0 ? { scope: input.options.scope, ...input.options.seatId === void 0 ? {} : { seatId: input.options.seatId } } : await resolveRotationScope(input.client, input.options, canAutoApprove);
+  const token = await createMcpToken(input.client, mcpTokenCreateBody(mintScope, input.options.expiry), canAutoApprove);
   let rotationOldRevoked = null;
   if (input.options.rotateTokenId !== void 0) {
     const oldTokenId = input.options.rotateTokenId;
     try {
-      const output = await executeWithConfirmation(input.client, "mcp_token.revoke", { token_id: oldTokenId });
+      const output = await executeWithConfirmation(input.client, "mcp_token.revoke", { token_id: oldTokenId }, canAutoApprove);
       const revoke = mcpTokenRevokeOutputSchema.safeParse(output);
       rotationOldRevoked = revoke.success && revoke.data.revoked === true;
       if (!rotationOldRevoked) {
@@ -44355,6 +44421,9 @@ async function renderMcpInstall(input) {
         );
       }
     } catch (error51) {
+      if (error51 instanceof PendingConfirmationError) {
+        throw error51;
+      }
       rotationOldRevoked = false;
       stderrLines.push(
         `Warning: the new token (${token.token_id}) was minted, but revoking the old token (${oldTokenId}) failed: ${revokeFailureReason(error51)}. It is still live. Revoke it by hand: ${cliBrand.binName} command mcp_token.revoke --json '{"token_id":"${oldTokenId}"}'`
@@ -44423,9 +44492,9 @@ function mcpTokenCreateBody(mint, expiry) {
   }
   return base;
 }
-async function resolveRotationScope(client, options) {
+async function resolveRotationScope(client, options, canAutoApprove) {
   const oldTokenId = options.rotateTokenId;
-  const listOutput = await executeWithConfirmation(client, "mcp_token.list", { include_revoked: true });
+  const listOutput = await executeWithConfirmation(client, "mcp_token.list", { include_revoked: true }, canAutoApprove);
   const parsed = mcpTokenListOutputSchema.safeParse(listOutput);
   if (!parsed.success) {
     throw new Error("Could not read the token list to rotate \u2014 mcp_token.list returned an unexpected shape.");
@@ -44488,11 +44557,11 @@ function revokeFailureReason(error51) {
   }
   return "unknown error";
 }
-async function createMcpToken(client, body) {
-  const output = await executeWithConfirmation(client, "mcp_token.create", body);
+async function createMcpToken(client, body, canAutoApprove) {
+  const output = await executeWithConfirmation(client, "mcp_token.create", body, canAutoApprove);
   return mcpTokenOutputSchema.parse(output);
 }
-async function executeWithConfirmation(client, commandId, body) {
+async function executeWithConfirmation(client, commandId, body, canAutoApprove) {
   try {
     const result = await client.execute(commandId, body);
     return result.output;
@@ -44501,6 +44570,14 @@ async function executeWithConfirmation(client, commandId, body) {
     if (!pending) {
       throw error51;
     }
+    if (!canAutoApprove) {
+      throw new PendingConfirmationError({
+        confirmationId: pending.confirmationId,
+        commandId: pending.commandId,
+        approveCommand: `${cliBrand.binName} command confirmation.approve --json '{"confirmation_id":"${pending.confirmationId}"}'`,
+        ...pending.approveVia?.webUrl === void 0 ? {} : { approveUrl: pending.approveVia.webUrl }
+      });
+    }
     const approved = await client.execute("confirmation.approve", {
       confirmation_id: pending.confirmationId
     });
@@ -44873,6 +44950,20 @@ function field(record2, key) {
   }
   return String(value);
 }
+function formatDryRunTranscript(value) {
+  const transcript = asRecord(value);
+  const steps = asArray(transcript.steps);
+  if (steps.length === 0) {
+    return "";
+  }
+  const lines = steps.map((step) => {
+    const record2 = asRecord(step);
+    const kind = field(record2, "kind");
+    const guard = record2.guard === null || record2.guard === void 0 ? "" : ` [${field(record2, "guard")}]`;
+    return `  ${kind}: ${field(record2, "text")}${guard}`;
+  });
+  return ["rehearsal:", ...lines].join("\n");
+}
 function markdownLine(output) {
   const markdown = asRecord(output).markdown;
   return typeof markdown === "string" ? markdown : JSON.stringify(output, null, 2);
@@ -45590,8 +45681,9 @@ var agentWrapper = (context, args) => dispatch(context, "agent", args, {
     };
     return execute(ctx, parsed, "agent.run_dry_run", body, (output) => {
       const record2 = asRecord(output);
-      return `dry run for seat ${field(record2, "seat_id")} (charter ${field(record2, "charter_version_id")}): ${field(record2, "status")} (reused=${field(record2, "reused")})
+      const header = `dry run for seat ${field(record2, "seat_id")} (charter ${field(record2, "charter_version_id")}): ${field(record2, "status")} (reused=${field(record2, "reused")})
 ${field(record2, "summary")}`;
+      return [header, formatDryRunTranscript(record2.transcript)].filter((part) => part.length > 0).join("\n");
     });
   },
   "go-live": (ctx, rest) => {
@@ -45865,7 +45957,15 @@ function ensureTrailingSlash2(value) {
 
 // src/index.ts
 async function main(argv = process.argv.slice(2), options = {}) {
-  const io = options.io ?? { stdout: process.stdout, stderr: process.stderr };
+  const io = options.io ?? {
+    stdout: process.stdout,
+    stderr: process.stderr,
+    // DER-832: an interactive session is a human at a real terminal — BOTH stdin
+    // and stdout must be TTYs. A piped/headless/agent session fails this and so
+    // will not auto-approve its own mint/revoke confirmation unless skip-
+    // permissions is explicitly enabled.
+    interactive: process.stdin.isTTY === true && process.stdout.isTTY === true
+  };
   const login = options.login ?? loginWithBrowser;
   const deviceLogin = options.deviceLogin ?? loginWithDeviceCode;
   const [rawCommand, ...args] = argv;
@@ -46152,23 +46252,28 @@ async function executeOnboard(io, client, args) {
 `);
   return 1;
 }
-async function executeMcp(io, client, appUrl2, args) {
+async function executeMcp(io, client, appUrl2, args, env = process.env) {
   if (args[0] !== "install") {
     io.stderr.write(
       `Usage:
-  ${cliBrand.binName} mcp install --client claude-code|codex|cursor --scope tenant-admin|seat [--seat-id <id>] [--expires-in <days>|--no-expiry]
+  ${cliBrand.binName} mcp install --client claude-code|codex|cursor --scope tenant-admin|seat [--seat-id <id>] [--expires-in <days>|--no-expiry] [--skip-permissions]
     Direct install \u2014 --scope is required (seat is narrower; prefer it for day-to-day).
-  ${cliBrand.binName} mcp install --client claude-code|codex|cursor --rotate <old-token-id>
+  ${cliBrand.binName} mcp install --client claude-code|codex|cursor --rotate <old-token-id> [--skip-permissions]
     Rotate in place \u2014 inherits the old token's scope, so do not pass --scope.
+    --skip-permissions (or ${cliBrand.envPrefix}_CLI_SKIP_PERMISSIONS=1) auto-approves the token-mint confirmation in a non-interactive session.
 `
     );
     return 1;
   }
   try {
+    const options = parseMcpInstallOptions(args.slice(1));
+    const envSkipPermissions = env[`${cliBrand.envPrefix}_CLI_SKIP_PERMISSIONS`] === "1";
+    const canAutoApprove = io.interactive === true || options.skipPermissions || envSkipPermissions;
     const rendered = await renderMcpInstall({
       client,
       appUrl: appUrl2,
-      options: parseMcpInstallOptions(args.slice(1))
+      options,
+      canAutoApprove
     });
     io.stdout.write(rendered.stdout);
     if (rendered.stderr) {
@@ -46176,6 +46281,11 @@ async function executeMcp(io, client, appUrl2, args) {
     }
     return 0;
   } catch (error51) {
+    if (error51 instanceof PendingConfirmationError) {
+      io.stderr.write(`${redactForLog(error51.toHandoffMessage())}
+`);
+      return 1;
+    }
     if (error51 instanceof CommandClientError) {
       return printCommandError(io, error51);
     }
@@ -46289,8 +46399,9 @@ function printUsage(io) {
     ...operationUsageLines(cliBrand.binName),
     `${cliBrand.binName} onboard status`,
     `${cliBrand.binName} onboard run`,
-    `${cliBrand.binName} mcp install --client claude-code|codex|cursor --scope tenant-admin|seat [--seat-id <id>] [--expires-in <days>|--no-expiry]`,
+    `${cliBrand.binName} mcp install --client claude-code|codex|cursor --scope tenant-admin|seat [--seat-id <id>] [--expires-in <days>|--no-expiry] [--skip-permissions]`,
     `${cliBrand.binName} mcp install --client claude-code|codex|cursor --rotate <old-token-id>  (inherits the old token's scope; no --scope)`,
+    `${cliBrand.binName} mcp install ... --skip-permissions  (or ${cliBrand.envPrefix}_CLI_SKIP_PERMISSIONS=1 \u2014 auto-approves the token-mint confirmation in a non-interactive session)`,
     `${cliBrand.binName} init [--client claude-code|codex|cursor]  (defaults --scope tenant-admin)`,
     `${cliBrand.binName} docs`,
     `${cliBrand.binName} reference <list|search|get> [options]`,