@astralyn/pi 0.87.5 → 0.99.0

package/docs/bundled/extensions/background.md

@@ -1,132 +0,0 @@
-# Background tasks and groups
-
-The `background` extension provides the `bg` management tool and `/bg` panel. The session's core Background service owns execution, cancellation, output, history and completion delivery. The extension does not launch commands or run a second task registry.
-
-## Start or detach work
-
-Start Bash through the native `bash` tool (the optional native Windows `powershell` tool accepts the same fields and follows the same lifecycle):
-
-```json
-{ "command": "npm run build", "timeout": 120, "background": true }
-```
-
-Start a whole Subagent invocation through its native tool:
-
-```json
-{
-  "background": true,
-  "tasks": [{ "agent": "explorer", "prompt": "Inspect the build configuration and report findings." }]
-}
-```
-
-Omitting `background` keeps the normal foreground wait. A background submission returns an execution reference, not a successful final outcome. `bg create` has been removed; old stored create results and background notifications still render in transcripts.
-
-In interactive mode, **Ctrl+B** moves all eligible foreground shell tasks and Subagent invocations to the background. It works even when `/bg` owns focus. The same execution continues: no cancellation, restart, new worker or timeout reset. It does not detach individual workers, ordinary file tools, or user `!` shell commands.
-
-When nothing is eligible, the key is not consumed: it falls through to other bindings instead of reporting a no-op.
-
-Configure `app.backgroundTasks.detach` in `keybindings.json` to change or disable the shortcut. The default `tui.editor.cursorLeft` is now `left`, freeing Ctrl+B. To restore Emacs cursor behavior, disable or rebind detach before assigning Ctrl+B to cursor-left.
-
-Workers cannot start background work themselves. Their system prompt forbids it and the host-assigned worker role rejects `background: true` before command startup; the shared schema remains unchanged. Foreground commands still work. Workers have no `bg` tool and must not bypass the restriction with shell detachment. Only the parent agent or user can background the whole Subagent invocation.
-
-## Management tool
-
-`bg` observes existing Bash tasks and whole Subagent groups:
-
-| Action | Parameters | Behavior |
-|---|---|---|
-| `list` | — | Lists active and up to five retained finished records, at most 100 rows; foreground executions are omitted with a count (they deliver inline in the transcript) |
-| `read` | `taskId`, optional `mode`, `bytes` | Reads bounded output/report while running or after completion |
-| `wait` | `taskId`, optional `waitMs`, `sinceBytes` | Waits within a deadline and returns status plus bounded output/report |
-| `kill` | `taskId` | Requests cancellation of the Bash task or entire Subagent group |
-
-Use the execution ID returned by the native tool or `bg list`. Worker IDs are display identities, not independent management targets. An unknown or stale `taskId` fails with the session's current tasks listed inline (active first, then recent finishes), so the next call can use a real ID without a separate list call; an ambiguous prefix lists exactly the tasks it matched.
-
-```json
-{ "action": "read", "taskId": "<execution-id>", "mode": "tail", "bytes": 8192 }
-```
-
-Reads default to an 8KB tail. `bytes` clamps between 256 bytes and 50KB at the tool boundary (the core currently limits the actual slice to 48KB); `mode` can be `head` or `tail`. A Bash output path is included when available. Subagent reads use the authoritative bounded report rather than raw worker transcripts.
-
-```json
-{ "action": "wait", "taskId": "<execution-id>", "waitMs": 20000, "sinceBytes": 4096 }
-```
-
-`waitMs` defaults to 20 seconds and clamps between 1 and 60 seconds. Wait output is limited to 32KB, optionally starting after `sinceBytes`. Expiry or cancellation ends only the wait, not execution. Continue independent work instead of sleep-polling or repeatedly reading; wait when the next step genuinely depends on the result.
-
-```json
-{ "action": "kill", "taskId": "<execution-id>" }
-```
-
-A cancellation request is not proof that execution has stopped. The task can remain `stopping` during cleanup. Read its later terminal status for the outcome. Partial, failed, cancelled and timeout outcomes are not displayed as successful completion.
-
-All model-facing management responses, including listings and error messages, are bounded to 50KB and 2,000 lines overall. Repeated reads do not add usage or restart execution. Completion delivery and usage accounting belong to the host, not panel refreshes.
-
-## `/bg` panel
-
-The panel opens as a fullscreen overlay framed by horizontal rules, matching Pi's other selectors. Terminals at least 100 columns wide show the task list beside a detail pane; narrower terminals stack the list, a compressed status summary, and the output region vertically.
-
-The list groups executions into **Running** (newest started first) and **Finished** (newest ended first). A row shows the shared status marker, the task label, and a right-aligned runtime or finish age; running rows animate the spinner on the one-second refresh. Ids, modes, and log paths live in the detail pane, not the list. Worker rows nest indented under their Subagent group. Status glyphs and colors come from the shared status-marker vocabulary — spinner/`›` running, `✓` completed, red `×` failed, yellow `×` timeout, yellow `○` cancelled/stopping/partial, muted `○` queued, `!` waiting on input — which transcript notifications, completion cards and Subagent results also use.
-
-**Running** also lists live foreground executions so the currently running command or group can be watched or stopped. **Finished** holds background shell tasks and all Subagent groups, including groups that ran in the foreground. Foreground rows carry an `fg` tag in either section. Settled foreground shell commands deliver inline in the transcript, leave the panel, and are counted in the title as `N foreground shells hidden`. A selected shell row is the exception — it never disappears mid-watch when its execution settles, and leaves once the selection moves away.
-
-The detail pane shows an aligned field table — status with mode and runtime, full execution id, highlighted command, directory, log path, and diagnostics — above a scrollable output region. Subagent groups list one compact line per worker — marker, label, status and task description — as an index into the worker rows; worker views render **Prompt** and **Outcome** as Markdown around a plain **Activity** section.
-
-- Bash rows and Subagent group/worker rows retain stable selection as status and ordering change.
-- Foreground rows carry an `fg` tag; foreground/background mode is explicit in the detail status line.
-- Worker detail shows identity/profile, group, model and usage on separate rows that wrap rather than truncate, plus Prompt, Activity and Outcome from the public projection.
-- Opening a view does not reattach the parent wait. Closing it never kills execution.
-- Selected groups are pinned against history eviction until selection changes or the panel closes.
-- Completed detail stays open. The panel releases its subscriptions, pin and timers on close or session shutdown.
-
-| Default key | Action |
-|---|---|
-| Left / Right | Focus the list / selected preview (also on narrow terminals) |
-| Up / Down | Select a row in the list; scroll the focused preview |
-| Enter | Focus/open preview |
-| Page Up / Page Down | Page the focused list or preview independently |
-| `k`, then `y` | Request cancellation of the selected task or whole group (confirmed with `y`; any other key cancels), including when a worker is selected |
-| Escape | Return from detail, then close |
-| Ctrl+B | Detach eligible foreground executions through the host |
-
-Preview positions are retained per row while the panel is open, including across focus changes, updates and resizes. Worker previews start at the top. Shell previews initially follow the tail; scrolling up switches to **browsing**, which keeps that row's current bounded output snapshot while task status continues updating. Explicit downward scrolling to the bottom resumes **following** and reads the latest tail. Neither mode pauses execution. The range counter on the output divider describes the visible lines within the bounded preview, not the entire log. The detail table stays above the scrolling content; on very short terminals, status and diagnostics take priority.
-
-Controls follow `app.backgroundTasks.focusList`, `app.backgroundTasks.focusPreview`, `tui.select.*`, `app.backgroundTasks.kill`, and `app.backgroundTasks.detach`. List paging uses `tui.select.pageUp`/`pageDown`; preview paging uses `tui.editor.pageUp`/`pageDown`, so the two can be rebound independently. Theme colors are semantic. Only visible selected output is read, at most once per second and within a 128KB request budget (the service may impose a smaller bound), with at most 2,000 viewport lines. Settled output is read once. Unselected work continues collecting progress independently of the panel.
-
-Outside TUI mode, `/bg` sends a bounded summary through the host notification UI rather than mounting a component (print/JSON notification UI is a no-op). Whether background startup is supported is an explicit host capability; a panel is never required for execution.
-
-## Completion notifications
-
-Interactive `background-completion` messages have a compact collapsed summary: outcome, execution kind, short ID, and a command or group brief. Failures retain a short reason; log paths, output and worker reports stay out of the collapsed view. In fullscreen mode, left-click the notification to expand or collapse that message independently. The blank spacer above it is not a click target. The configured tool-output expansion binding (default Ctrl+O) remains available for toggling output expansion across the transcript.
-
-Expanded shell notifications separate **Command**, **Directory**, **Result** or **Error**, a bounded plain-text **Output** tail, **Log** and the full execution ID. Expanded Subagent completions show numbered worker profiles and observed statuses, task descriptions, and Markdown **Report** sections; failures keep their reason separate from any partial report. Each saved output/report carries an explicit truncation flag. Screen line limits are independent of source truncation, and every worker retains a report allowance. These are previews of the saved bounded completion.
-
-Rendering reads the self-contained `BackgroundCompletionSnapshot` in message `details`, so `/reload`, history eviction, expired logs and restart do not require a live task lookup. The session generates model-facing `content` from the same facts; `details` never enters model context or usage accounting. Commands containing `Output:`, worker reports containing headings or error-wrapper examples, and literal truncation notices remain ordinary data. See the [snapshot contract](../../session-format.md#background-records).
-
-Only the current structured completion format is specialized. Older text-only completions and malformed details receive a bounded plain **Details** view; no text reconstruction or migration is performed. Legacy `background-task` notifications keep their existing renderer. HTML export and `/tree` selector labels continue to display the saved message content.
-
-## Lifetime
-
-Background execution belongs to the current session runtime, not a daemon. Parent-turn cancellation still cancels foreground-owned work; after detach it does not cancel background work. Shutdown, `/reload`, `/new`, `/resume`, and `/fork` close admission, stop delivery, cancel work and perform bounded cleanup. `/tree` cancels executions whose launch anchor is absent from the destination branch and suppresses their completion delivery there; navigating back to a branch revives its undelivered completions, and ordinary conversation progress along the same branch does not cancel them. A completion already handed to the prompt queue when its run was aborted is not recalled — the next run delivers it, like any other queued message. Active processes and workers are not reattached across process restart or copied into a fork.
-
-The panel is an observer, not a cleanup engine. Admission, bounded history/output retention, completion delivery and headless exit policy are enforced by the core service and hosting mode.
-
-Interactive mode enables Background. Built-in print, JSON, and RPC modes and ordinary SDK sessions leave it disabled and reject `background: true`; normal foreground execution remains available. An SDK embedding can explicitly enable it via `session.bindExtensions({ backgroundEnabled: true })`, but must own cancellation, bounded draining, result-driven turns, and shutdown. See [SDK Background execution](../../sdk.md#background-execution).
-
-Managed shell output is collected continuously from startup, including before detach. Background shell output is capped at 20 MiB; crossing the cap fails and stops the command. Foreground output retains its existing uncapped log behavior: detaching a command already over the background budget stops it without deleting the prior bytes. No timeout is supplied by default, and a supplied timeout remains measured from command startup, in seconds, across detach.
-
-Managed logs are ephemeral: they are retained with the runtime record and cleaned up when that record is evicted or the runtime shuts down. Save needed output elsewhere before then. The core defaults to eight active managed executions and two independent terminal histories: 32 background shell tasks/Subagent groups, plus 32 foreground shell records. Each Subagent invocation counts as one group, whether it ran in the foreground or background. Foreground shell traffic can only evict older foreground shell records. Pending delivery, pins, active reads and cleanup use a separate allowance within the bounded total; pins temporarily defer history eviction, not runtime shutdown. These are service limits, not new user settings.
-
-Terminal snapshots persist as version-2 `background-task-result` custom entries, including the structured presentation projection; usage remains in independent version-1 `background-usage` entries. `/bg` restores only version-2 terminal history from the selected branch, selecting the newest records independently for each history. Older result records are left in the session file and are not migrated or restored. This is observation only: live execution never resumes after restart, and restoration does not replay accounting or completion events. A saved log path is not a durable attachment. See [session format](../../session-format.md#background-records).
-
-Delivered history outside the selected branch can be released and restored on return, so it does not fill the new branch's history budget. Undelivered completions stay protected while their branch is hidden. Pending delivery, pins and active reads use a separate allowance within the total runtime retention cap; restoration respects the same cap.
-
-Completion delivery follows the same queueing path as interactive input. While the agent is running, a completion is steered into that run, so it lands right after the current tool batch — exactly like a message the user types mid-run, and behind any already queued steering. An idle session starts a completion turn instead. User preflight (input hooks, model and authentication checks, compaction) still holds delivery, so a user message is always the first thing a new run sees. One bounded completion is in flight at a time. A Subagent group produces one summary, not a separate wake-up per worker. A terminal `bg wait` coordinates with automatic delivery only after its tool result is persisted: while a `bg wait`, `bg read` or a watched `/bg` row holds a task pinned, that task is not announced, and aborting during output reading does not lose the pending completion. Direct SDK waits remain observational until explicitly acknowledged. Progress and repeated reads do not inject messages or add usage. `agent_settled` still describes the main agent, not the end of all background executions.
-
-Failed completion delivery leaves the terminal result available for inspection rather than silently discarding it, and warns through the extension error channel. The next user prompt retries delivery automatically; SDK hosts can also call `session.retryBackgroundNotifications()` explicitly after resolving the failure. There is no infinite timer retry loop. A completion that a run emitted but never persisted, and a completion dropped by clearing the queue, fail the same way; one still sitting in the queue when its run ends stays claimed, because the next run delivers that same message.
-
-Queued extension `nextTurn` context accompanies completion turns and stays queued until each message is persisted. A failed or partially persisted turn therefore retries only the context that has not been saved.
-
-If an executor ignores cancellation and settles after bounded cleanup has retired its runtime or branch, the old session quarantines its bounded result and reported usage: the latest 32 records remain in memory, and persisted sessions also append `<session-file>.background-late.jsonl`. These audit records are excluded from active totals and are not automatically reconciled. A completed cleanup grace period is not proof that an uncooperative executor stopped.
-
-The previous extension-owned interactive-prompt stall watchdog was not ported. Pi no longer automatically flags a prompt-looking shell tail as `waiting for input` or sends stall remediation notifications. Use non-interactive commands and inspect/stop stalled work manually; legacy stall notifications still render from saved transcripts.

package/docs/bundled/extensions/subagent.md

@@ -1,148 +0,0 @@
-# subagent — isolated delegation
-
-Adds the `subagent` tool and `/agents` settings command. It delegates bounded work to isolated in-process `AgentSession` workers; the parent can wait in the foreground or hand the entire invocation to the session-owned [Background service](background.md). This is not a persistent fleet-management system.
-
-## Tool contract
-
-Every call supplies one ordered `tasks` array with 1–8 items and an optional top-level `background` flag:
-
-```json
-{
-  "background": true,
-  "tasks": [
-    {
-      "prompt": "Locate the provider retry implementation and report exact symbols.",
-      "description": "Find provider retry code",
-      "agent": "explorer",
-      "cwd": "src/core"
-    }
-  ]
-}
-```
-
-`background: true` hands off the whole group after successful preflight. Omit it, or use `false` or `null`, to wait in the foreground. It is not a `tasks[]` field; individual workers cannot be detached. A handoff returns a group reference, not a completed report.
-
-Each item has:
-
-```text
-prompt       Required self-contained worker briefing
-description? Short task label for the /bg list, live rows, and report headings; derived from the prompt when omitted
-agent?       explorer or general; defaults to explorer
-cwd?         Worker directory; relative paths resolve against the parent working directory
-```
-
-A `cwd` inside the parent working directory runs with the parent session's project trust. A `cwd` outside it is allowed but runs untrusted: the worker never loads that directory's `.pi` project settings under the parent's trust conclusion. A missing or non-directory `cwd` fails the call and names the nearest existing parent directory.
-
-There is no separate single-task or parallel mode. One item launches one worker; multiple items launch concurrent workers. A session-scoped gate permits at most six active workers across all sibling `subagent` calls, so additional items wait for a slot. Results always follow input order, regardless of completion order.
-
-All tasks are preflighted before any worker starts. Profile, working-directory, model, thinking-level, or authentication failure in one item rejects the entire call without launching the other workers. Once execution begins, one worker failing does not cancel independent siblings.
-
-Sequential work uses another `subagent` call after the parent has read the previous report and written the next briefing.
-
-## Built-in profiles
-
-There are exactly two profiles:
-
-- **Explorer** (`explorer`, default): read-only investigation with `read`, `grep`, `find`, `ls`, and `bash`. Bash remains available for Git history and inspection commands such as `git log`, `git diff`, `git blame`, `git show`, `git status`, `wc`, `head`, and `tail`. Its system prompt forbids redirects, heredoc writes, temporary files, state-changing Git commands, installs, and network access.
-- **General** (`general`): implementation, file changes, and stateful verification with `read`, `bash`, `edit`, and `write`.
-
-There are no user or project profile files. Child sessions load no extensions, skills, prompt templates, or themes, so workers cannot recursively call `subagent` or inherit unrelated extension capabilities. Both profiles load the applicable repository instructions for their working directory, including layered `AGENTS.md` or `CLAUDE.md` files. Explorer's tool set and system prompt remain strictly read-only.
-
-Workers are told not to set `background: true` or bypass the restriction through shell detachment. Their trusted host-assigned execution role also rejects background requests before starting a command or allocating execution resources; the shared shell schema is not dynamically trimmed, and requests are not silently downgraded. Foreground Bash remains available. Workers have no `bg` tool and must report long-lived service requirements to the parent. This is a prompt/execution capability boundary, not an OS sandbox.
-
-Worker contexts are isolated, but workers share the parent's checkout. Concurrent tasks therefore must be independent and must not perform overlapping writes.
-
-## Model and thinking selection
-
-Model and thinking resolution has two layers:
-
-```text
-saved /agents override > current parent session
-```
-
-Callers cannot select model or thinking per task. Run `/agents` to configure Explorer or General:
-
-1. Select **Explorer** or **General**.
-2. Select **Model** or **Thinking**.
-3. Choose a concrete value or **inherit**.
-
-Each confirmed choice is saved immediately; there is no draft, Apply, or Save step. Choosing **inherit** immediately removes that override. Escape only navigates back and never rolls back choices already confirmed.
-
-The TUI model picker supports search, scoped/all models, unavailable saved models, and catalog refresh. Thinking choices are limited to levels supported by the effective model.
-
-Overrides are saved atomically in:
-
-```text
-~/.pi/agent/subagent.json
-```
-
-Only `explorer` and `general` keys are valid. A malformed, unsupported, unreadable, or future-version `subagent.json` is never rewritten during load: workers temporarily inherit the parent settings and the UI reports the problem. On the first actual settings change, Pi backs up the original bytes to a collision-safe `.invalid-<timestamp>-<pid>.bak` file before writing a valid replacement; if the backup fails, the save is cancelled. Concurrent Pi processes lock, re-read, and merge profile changes before an atomic write, and no-op changes leave the file and its timestamp untouched. Overrides affect future workers and never change the parent session's model or thinking level.
-
-## Lifecycle and retry
-
-- By default, the parent call waits until every worker reaches a terminal state. In interactive mode, Ctrl+B hands all eligible foreground invocations to Background without restarting workers or releasing occupied gate slots.
-- Parent abort cancels foreground-owned work, but detached work continues. `bg kill` stops an entire group, including queued workers.
-- `/reload`, `/new`, `/resume`, `/fork`, and session shutdown cancel and clean up owned active and queued workers; forks never copy live execution handles. `/tree` cancels work whose launch anchor is outside the destination branch.
-- Provider auto-retry remains visible under the expanded task Outcome as `Retrying (n/m) in Xs`.
-- A retryable failure that produced no turns or tool use may be retried at task level up to two more times. Runs with partial work are never restarted.
-- Retry backoff does not hold a concurrency slot; another queued worker can run while the failed task waits.
-- Cancellation of the owning execution interrupts queued and retrying workers immediately.
-- Background completion is delivered as one bounded group summary, with reports in input order, through the host's normal prompt queueing: steered into a running turn right after its current tool batch, or as its own turn when the session is idle. Its saved card has independent profile/status/report/error fields and explicit report-truncation flags; report text is never reparsed as worker metadata. Every worker gets a bounded report share. `bg wait` can deliver the terminal result instead; repeated `bg read` calls do not trigger notifications or billing.
-- Managed worker usage settles through an independent persisted ledger, not through panel visits or result reads. Accrued usage from retries, failures, cancellations, and provider-supplied worker compaction is retained; missing provider usage is not fabricated. Worker tokens do not count as parent context occupancy.
-
-Child sessions share the parent's canonical model/authentication runtime, so extension-registered providers and current credentials do not need to be mirrored into a second runtime.
-
-Background support is enabled by interactive mode. Built-in print, JSON, and RPC hosts reject background startup; SDK embeddings must explicitly enable it and own the host lifetime. See [SDK](../../sdk.md#background-execution). No daemon, restart recovery of live workers, or Subagent wall-clock timeout parameter is provided.
-
-## Transcript UI
-
-After handoff, the transcript row is a settled submission snapshot, not a still-pending worker view. Use `/bg` for live group/worker progress and outcomes: wide terminals show list and detail side by side, narrow terminals enter detail from the list. Worker display numbers there are stable within the extension runtime; transcript ordinals below remain local input positions. Opening detail only observes work and does not make the parent wait again.
-
-Completed groups remain in `/bg` under **Finished** whether they ran in the foreground or background; foreground groups keep an `fg` tag. Subagent groups share a bounded history with background shell tasks, separate from foreground shell logs, so ordinary shell commands cannot evict their reports. The same independent histories restore from the selected session branch after reload or restart.
-
-Pi's native tool chrome owns the aggregate `● Subagent` call marker and the dim continuation rail. The collapsed view is a compact flow containing one cell per task:
-
-```text
-● Subagent
-│ ✼ #1 Explorer · ○ #2 Explorer · ✓ #3 General · × #4 General
-```
-
-`#N` is the task's stable one-based input position. Cells always remain in `#1` through `#N` order and contain only the task marker, ordinal, and profile. Running cells use the breathing dot-to-star bloom, queued cells use `○`, and completed, failed, or aborted cells use `✓`, `×`, or `○` (yellow for aborted). Wide batches wrap at cell boundaries with uniform columns. If the terminal is narrower than one complete cell, every task receives its own width-truncated row so all ordinals remain visible. Collapsed cards never expose prompts, activities, timings, token totals, costs, or failure text. Live repainting runs at 120ms only for visible collapsed blooms and at one second for expanded running durations or retry countdowns; queued, static, settled, and disposed rows keep no refresh timer.
-
-Expanding removes aggregate Batch chrome and gives every task the same four-part layout:
-
-```text
-● Subagent
-│ #1 Explorer · anthropic/claude-opus-5 · max · 99.9k tok · 60 tool calls · 12m 47s
-│
-│ Prompt
-│   Inspect the renderer and report the exact data flow.
-│
-│ Activity · last 3 of 60 tool calls
-│   Read(src/extensions/subagent/render.ts)
-│   Grep(src/extensions/subagent)
-│   Run(npm test -- test/subagent-render.test.ts)
-│
-│ Outcome
-│   Still running...
-```
-
-The single-line task header always shows the profile, exact `provider/model` ID, raw thinking level (including `off`), cumulative provider-reported token usage, tool-call count, and task duration. Tokens use compact `k`/`M` notation with at most one decimal. The header omits working directory, turns, per-run cost, and aggregate Batch timing or cost, and truncates rather than wraps when the terminal is narrow.
-
-Prompt contains the complete original task briefing and remains visible in every state. Prompt, Activity, and Outcome bodies use a two-column inset under their section labels.
-
-Activity retains only the latest three actual tool calls, in execution order. Its denominator is the run's total tool-call count; small histories use `Activity · N tool calls`, and an empty history says `No tool calls yet.` Calls use compact `Read(path)`, `Grep(path)`, `Find(pattern)`, `List(path)`, `Run(command)`, `Edit(path)`, or `Write(path)` presentation. Synthetic compaction entries do not increment or occupy the tool-call history.
-
-Outcome stays in the same position throughout the task lifecycle:
-
-- queued or running: `Still running...`, followed by a retry countdown or active compaction state when applicable;
-- completed: the worker's final Markdown report, or `No outcome returned.`;
-- failed or aborted: the terminal reason, followed by `Partial outcome:` and the bounded report when useful output survived.
-
-A terminal task exposes its Outcome immediately even while sibling tasks remain active. Profile identity, section headings, activity state markers, and outcomes use semantic theme colors; report Markdown keeps its normal Markdown palette instead of inheriting a blanket success or error color.
-
-Full child transcripts are not stored separately. Activity, errors, reports, usage, and model-facing output remain bounded, and completed calls restore through the parent session tree.
-
-## Deliberate non-features
-
-There are no custom profiles, independently backgrounded workers, cross-session persistent worker identities, unread state, fleet panel, per-worker send/stop/resume control plane, chain mode, swarm/coordinator, worktree isolation, nested agents, MCP, hooks, or agent memory. The shared `/bg` panel and whole-group cancellation/completion summaries are the supported background controls.