@staix/agent-hub 0.20.0 → 0.22.0

package/docs/security.md

@@ -7,23 +7,24 @@ agent-hub connects agents that can each run commands. This page says what the hu
 - **Other agents' text is untrusted.** Every message that crosses from one peer to another is framed as untrusted input: a channel tag with `meta.source` for Claude started with `ahub claude`; otherwise a fixed header line (`frame()`, `[agent-hub message from ...]`) with an instruction that says it is untrusted, the plugin's server instructions for a tools-only Claude reading `hub_inbox` and a standing instruction for the others. A message body cannot forge the hub's own headers: such lines are quoted (`sanitize`). Replies inherit a hop count capped at 3, so agents cannot ping-pong forever; neither a digest nor a steer can reset it.
 - **The control link is loopback plus a secret.** The daemon and the Codex proxy bind 127.0.0.1 only. The control WebSocket requires a per-run token (`.agenthub/state/control-token`, mode 600), and both servers refuse any request that carries an `Origin` header: any web page can open a WebSocket to localhost, and browsers always send `Origin`. The bearer header a Codex TUI sends to the proxy carries only the terminal launch id (#586): it binds terminal ownership and is not a credential. External clients cannot claim the console user's id or a hub-managed peer's id.
 - **Permission prompts stay on unless an operator selects a permission mode.** `ask` leaves native decisions unchanged. `ask-when-needed` grants scoped Claude file tools or Pi/local writes and edits, and a headless Claude implementer's proven shell commands through the host wrapper (#845, below); Kimi and Codex use their own native policies. `never-ask` requires explicit runtime confirmation or a person's console `y` for a config default at hub start. Until that config confirmation the peer runs in `ask`. Kimi's and `local`'s permission requests are relayed to the console and cancelled after `approvals.timeout_s` (default 120 s) of silence; the macOS notification for a waiting request carries the peer and the tool name only. The one exception is the hub's own tools (`hub_send` and the task tools, matched by exact name): Kimi's requests for them are approved once without a prompt and logged by name, the same trust Codex gets through `approval_mode` in the hub's config. They invoke hub-owned operations rather than arbitrary file or shell tools, and every call passes the hub's own checks. A call the always-ask policy classes (below) is never approved this way, whatever its title. Identity comes from the exact permission title, or from the earlier tool-call title bound to the same call id and resolved against the configured MCP servers when the permission title contains argument JSON (Qwen). Payload text and unrelated display titles never establish identity. Configured ACP kinds (#451) never get this exception: a request whose title spells a hub tool exactly still goes to the person approval path, and only a mapped native mode changes what the agent itself asks. For ACP agents, a payload longer than the console shows is marked as cut and never offers a session-wide grant. Pi's write, edit, shell and git write requests are relayed the same way and can be answered `Always allow <tool> until Pi restarts`: later calls of that tool by the same Pi start skip the prompt but stay inside the path guard and sandbox. The grant covers every later call of that tool whatever its payload, is kept in memory only, cannot be given from the dashboard, and each call it allows is logged by tool name. A Pi or `local` request whose call was cancelled or whose turn ended is withdrawn at once: a later answer is refused and grants nothing, an `Always allow` included. One shell command runs without a hub approval: the `!command` a person types in the managed Pi TUI. It stays inside the same sandbox and denylist, and the hub takes it only from the verified owner process of a Pi in TUI mode, while Pi is idle, on a reservation that is used once; a model's own bash call never takes that path (issue #253). `--unattended` turns prompts off, says so loudly, and is never the default; a classed call from a hub-owned ACP peer, the local worker or Pi still waits for a person under it.
-- **A committed config cannot choose launch commands, credential files, data endpoints, permission modes or a wider sandbox.** The machine-local fields (`kimi_cmd`, `permission_modes`, `codex_bin`, `pi.cmd`, `checks`, `mlx.bin`, `mlx.runtimeDir`, `mlx.modelPath`, `omniroute.urls`, `omniroute.access_hosts`, the `omniroute` key files, `memory.worker_url` (still accepted, ignored since 0.16.0), `local.read_allow`, `local.bash_network`, `local.network_allow`, `terminal.open`, `tasks.auto_pull`, `instances`, `action_policy`) apply only from a config file git confirms nobody committed (`instances` and `action_policy` are read only from an untracked `.agenthub/config.local.json`; in `config.json` they are ignored even when untracked): `.agenthub/config.json` or `.agenthub/config.local.json`, matched by file identity so no other spelling the file system accepts slips past, and `.agenthub` itself not a committed symlink or submodule. Without a repository, or when git fails, they keep their defaults; an empty value always means the default. "Untracked" is answered by the repository that contains the project: a checkout copied or extracted into an unrelated repository, or into an ignored directory of one, is trusted like your own files. So a cloned repository cannot choose a launch command, a completion check, a gateway to send a key file to, a memory endpoint, a permission mode, the command that opens a terminal, or a wider sandbox. A command in `checks` runs as you, outside the local worker's sandbox, like a git hook. So do the `setup` and `verify` commands of a benchmark suite (issue #251): `ahub bench run <suite.json>` is a person's command, refused from an agent session, and it resets the work tree for each attempt, so it runs only with `bench.enabled`, at the root of a clean repository that tracks nothing under `.agenthub/`. Nothing in `routing.toml` or in task text is ever run. `routing.toml` and the other shared fields still come from the checkout, and they matter: `routing.toml` picks the models the local worker and the hub's inference use at your gateway and can turn the PII constraint off, and roles and budget shape who does what. Review them in a repository you do not trust. The hub's own git calls outside the sandbox (snapshots, facts, config trust, project discovery, memory recall, the bench runner) all use the single hardened implementation in the exact-pinned first-party `@staix/agent-mem/platform` package, re-exported by `src/hub/git.ts`, which disables the programs a repository's configuration can name — the file-system monitor, hooks, external diff, the pager, and the credential and askpass helpers, with prompts failing closed — so a config that ever does get written cannot run code with the hub's rights. Of those, the monitor, hooks and external diff are reachable by commands the hub issues (the planted-program test exercises all three; a `diff --no-index` reads the repo's config, so that call also passes `--no-ext-diff` and `--no-textconv`); the pager is not (every call pipes stdout). Credential and askpass helpers are disabled for project repositories; memory sync alone may use credentials for its own memory repository, without prompts. The cost: `core.fsmonitor=false` also turns off a person's enabled built-in monitor for the hub's own calls, so the per-turn snapshot's `add -A` scans the whole tree (the snapshot Git calls of one burst share a 250 ms budget, each call at most 10 s; a boundary that runs out is recorded as unknown, never as a stale baseline) (#576). git has no global switch for filter drivers, and of the hub's commands only the snapshot's `add`/`restore` would run one (its driver command lives in the protected `.git/config`).
+- **A committed config cannot choose launch commands, credential files, data endpoints, permission modes or a wider sandbox.** The machine-local fields (`kimi_cmd`, `permission_modes`, `codex_bin`, `pi.cmd`, `checks`, `mlx.bin`, `mlx.runtimeDir`, `mlx.modelPath`, `omniroute.urls`, `omniroute.access_hosts`, the `omniroute` key files, `memory.worker_url` (still accepted, ignored since 0.16.0), `local.read_allow`, `local.bash_network`, `local.network_allow`, `local.doc_read`, `local.web_fetch`, `terminal.open`, `tasks.auto_pull`, `tasks.queue_backpressure`, `context.max_assignment_used`, `schedules`, `folder_triggers`, `corpus.paths`, `instances`, `action_policy`, `rooms`) apply only from a config file git confirms nobody committed (`instances`, `action_policy` and `rooms` are read only from an untracked `.agenthub/config.local.json`; in `config.json` they are ignored even when untracked): `.agenthub/config.json` or `.agenthub/config.local.json`, matched by file identity so no other spelling the file system accepts slips past, and `.agenthub` itself not a committed symlink or submodule. Without a repository, or when git fails, they keep their defaults; an empty value always means the default. "Untracked" is answered by the repository that contains the project: a checkout copied or extracted into an unrelated repository, or into an ignored directory of one, is trusted like your own files. So a cloned repository cannot choose a launch command, a completion check, a gateway to send a key file to, a memory endpoint, a permission mode, the command that opens a terminal, a folder the hub reads, work proposed on a timer, a host a model may fetch from, or a wider sandbox. A command in `checks` runs as you, outside the local worker's sandbox, like a git hook. So do the `setup` and `verify` commands of a benchmark suite (issue #251): `ahub bench run <suite.json>` is a person's command, refused from an agent session, and it resets the work tree for each attempt, so it runs only with `bench.enabled`, at the root of a clean repository that tracks nothing under `.agenthub/`. Nothing in `routing.toml` or in task text is ever run. `routing.toml` and the other shared fields still come from the checkout, and they matter: `routing.toml` picks the models the local worker and the hub's inference use at your gateway and can turn the PII constraint off, and roles and budget shape who does what. Review them in a repository you do not trust. The hub's own git calls outside the sandbox (snapshots, facts, config trust, project discovery, memory recall, the bench runner) all use the single hardened implementation in the exact-pinned first-party `@staix/agent-mem/platform` package, re-exported by `src/hub/git.ts`, which disables the programs a repository's configuration can name — the file-system monitor, hooks, external diff, the pager, and the credential and askpass helpers, with prompts failing closed — so a config that ever does get written cannot run code with the hub's rights. Of those, the monitor, hooks and external diff are reachable by commands the hub issues (the planted-program test exercises all three; a `diff --no-index` reads the repo's config, so that call also passes `--no-ext-diff` and `--no-textconv`); the pager is not (every call pipes stdout). Credential and askpass helpers are disabled for project repositories; memory sync alone may use credentials for its own memory repository, without prompts. The cost: `core.fsmonitor=false` also turns off a person's enabled built-in monitor for the hub's own calls, so the per-turn snapshot's `add -A` scans the whole tree (the snapshot Git calls of one burst share a 250 ms budget, each call at most 10 s; a boundary that runs out is recorded as unknown, never as a stale baseline) (#576). git has no global switch for filter drivers, and of the hub's commands only the snapshot's `add`/`restore` would run one (its driver command lives in the protected `.git/config`).
 - **Telemetry holds no bodies.** `.agenthub/state/events.jsonl` (issue #40) records envelope ids, routing and sizes, task ids and states, overlapping paths and token counts, and the task id (with a PII flag) that each usage and token record is attributed to. It never records a message body, a task title or detail, and marks private (PII) envelopes and tasks as such. Budget pauses, resumes and quota resets carry the peer, window, times and the hub's own reason text, and a person's release authorization its commit, version and docs digest. The usage roll-up (#683) folds the usage, token and limit records into `hub.db` and joins issue, PR and release from the board when read; `ahub usage` and the console's Usage panel answer only the console and a configured planner, and a planner not during a private turn. Kimi's token records (#285) are counted from its own session wire log under its home: only the four token integers, the model label and the row time are copied, and the record id is an opaque hash, never a path, session id or text. The log stays on the machine; `ahub export` only prints it. Two opt-in stores copy numbers from it into your home directory, shared by every project on the machine (directories mode 700, files 600): research records (issue #247, `research.enabled`) in `~/.agenthub/research/` hold per approved task the ids, states, counts, tokens, times and PII flag the events hold, a person's label from a closed list, and a hash in place of the project id; benchmark runs (issue #251) in `~/.agenthub/bench/` hold suite name and hash, arm label, the attached peers' ids, models and permission modes, task ids, outcomes, exit codes, counts, tokens and times, never suite text or a command's output.
 - **Snapshots stay in your repository.** Per-turn snapshots (issue #33) are git objects in the project's own object store, written through a temporary index; nothing is referenced, pushed or copied elsewhere, and `git gc` prunes them. They hold what the work tree held, including untracked files that are not ignored, so keep secrets in ignored files. They carry the repository's own permissions, and nothing caps their disk use but `git gc`. A turn of a peer holding an open PII task is not snapshotted; a PII file left in the project is snapshotted by later turns like any other file. `ahub undo` restores only files whose current content is exactly what the turn left.
 - **The edit hook reads, never decides.** `ahub check-path --hook` (issue #32) reads hub.db and returns context for Claude and a line for you; it sets no permission decision, so your permission rules stay in charge. It names other owners' task ids, titles and states, which then reach Claude's model; PII tasks are left out.
 - **The session record holds identities only.** `.agenthub/state/sessions.json` (issue #37, mode 600) keeps each attached peer's recovery metadata: launch options, session and thread ids, Pi's session file path. No message or task text; loss notices name deliveries by id, sender and public task title. The Pi continuity bookmark that recovery keeps across stop and archive (`.agenthub/state/recovery-continuity.json`, mode 600, at most 16 KiB) holds identities only too: operation and project ids, the project root, and Pi's session id, session file, backend and model name; a bookmark that is not a private regular file, is larger than that or names another project or operation reads as invalid, which is kept distinct from no bookmark.
 - **Context checkpoints have a separate text record.** Native occupancy readings carry numeric metadata only. An optional context checkpoint persists its summary in `.agenthub/state/context-checkpoint-<peer>.json` with mode 0600 and, when memory is enabled, proposes it as a machine-local memory candidate that only a person can accept. Completion requires the outstanding request id, current peer/native session and transport generation; new connection claims invalidate old requests. Private turns, every open PII task associated with the peer as owner or reviewer (including pending review), and PII-pattern summaries are refused before persistence or memory. Its text is never broadcast, and context pressure does not pause, reassign or replace the session.
-- **The local worker is boxed in.** Paths are resolved through symlinks and must stay inside the project; a secrets denylist (`.env*`, keys, credential files, the hub's own state and the state archives `ahub reset --all` leaves) applies to its file tools, its git arguments and its memory capture alike; `.git` and `.agenthub` are not writable. Writes, edits, shell commands and mutating git wait for approval unless the operator's permission mode grants them (writes and edits inside the grant filter in `ask-when-needed`, all four in `never-ask`; see below), and the approver sees what will be written or run, with control characters escaped. Everything it executes runs under the macOS sandbox, attended or not. Since 0.10 the profile starts from deny default (issue #39): commands run and read only the system, toolchain and project directories (and the project's git dir and the selected developer dir; with network on, the public CA bundles); no writes outside the project, its git dir and a temp dir of its own (`TMPDIR`, made for each command and removed when it ends; issue #63); no `.git` name at any depth, closing the creation, rename, symlink and gitfile routes to a planted repository, no `config`, `config.worktree` or `hooks` directly under one, nor in any submodule git directory (every modules tree the project can reach is covered: the common dir's, each linked worktree's own under `<common>/worktrees/<wt>/modules/`, matched by pattern so a tree or worktree that does not exist yet is covered too, and each discovered submodule git directory's own `modules/`, nested submodules and a submodule's own linked worktrees included; under a modules tree every write that is not inside a discovered submodule git directory is refused, whatever its name, so a fake git directory cannot be planted for a later unsandboxed `git submodule update --init` to reuse; inside each discovered one its own `config`, `config.worktree` and `hooks` and its linked worktrees' `config.worktree` are refused, while refs, logs, objects, the index and `HEAD` stay writable, so commit, branch, tag, gc and rebase work; a linked worktree's git directory under `<common>/worktrees/` gets the same `config`, `config.worktree` and `hooks` refusal; every term is anchored at the discovered path, `hooks` by depth, so a directory named `config` or `hooks` above the project neither disables the rule nor trips it; the discovered git directories, the modules roots, the worktrees container, each worktree git directory and every component in between are also refused as targets, closing the rename, replace and symlink routes to the same files), no `commondir` at any depth below one, with every such name matched folded against the code points HFS+ ignores (the fold covers the security-relevant names; on a volume that folds names, folded spellings of the components between `.git` and a submodule's git directory are not matched — the 1024-byte SBPL literal cannot hold a folded path — the same residual the external git dir rules carry since #270), and no `.agenthub` anywhere in the project (in an external git dir the `config`/`config.worktree`/`hooks` rules cover only its own children and the hooks directory's contents, so refs named `config` or `hooks` still work); a nested repository in bare layout stays open — the directory is the git dir, with no `.git` name to anchor a rule on, and the hub never runs git there, whatever the project root is: its calls are all `-C <project root>` or `--no-index` on temp files, and none descends into a nested directory's git layout, so a planted hook fires only if a person or another tool runs git in that directory themselves; the rules are probed on HFS+, which folds the 16 code points the patterns tolerate, and on a case-sensitive APFS image, which folds nothing (a folded spelling is an inert new file there and the real names stay refused); the shared object store takes only new loose objects (#864): `objects/info` (alternates, http-alternates, commit-graph) and `objects/pack` are refused, and so are the `objects`, `objects/info` and `objects/pack` entries, moving a fan-out directory, and changing, removing or replacing an existing loose object, because git reads packs first and never rehashes what it reads, so a planted pack or alternate would change what every checkout and the implementer's host add, commit and push (#845) see; a hardlink to an existing object is refused as well; an object id that does not exist yet can still be planted before git writes it (its exact content must be predicted), which a local checkout then shows, while a push of it is rejected by the receiving side's rehash; the cost is that `git init`, `git clone` and `git worktree add` do not run inside the sandbox (add, commit, stash and checkout still do; `git gc`, `repack`, `fetch` and `maintenance` run outside it, #864), `git submodule update --init` does not either (its git directory's `config` write is refused), and neither do `git worktree remove`, `git worktree prune` of a stale record, `git clean -ffd` in a project with a nested repository, or `rm -rf` of a directory that holds a `.git` (refusing the unlink is what stops the rename-out route); no network, loopback included, unless `local.bash_network`; with it, only through the hub's egress proxy to the hosts in `local.network_allow` (issue #65), which refuses names that resolve to internal addresses (behind NAT64 with the well-known prefix, by the IPv4 address the answer carries; a network-specific prefix is not recognised), so claude-mem and the Codex app-server stay out of reach (`"direct"` opens everything, until 0.13.0). One channel stays open: `trustd`, which TLS clients need, can fetch a certificate's AIA or OCSP URL on a command's behalf, outside the proxy. The allow-default profile of 0.9 and earlier was removed in 0.12.0 (issue #83); a `local.sandbox` setting is ignored with a note. The shared temp dirs (the user's and `/private/tmp`) are closed. Without the sandbox there is no `bash` tool.
+- **The local worker is boxed in.** Paths are resolved through symlinks and must stay inside the project, and name-based refusals (the denylist, `.git`, `.agenthub`) judge both the resolved name and the name typed inside the project, because Bun's realpath can name another hardlink of the same file (#541; facts, deliverables and `ahub source add` too, #552); a secrets denylist (`.env*`, keys, credential files, the hub's own state and the state archives `ahub reset --all` leaves) applies to its file tools, its git arguments and its memory capture alike; `.git` and `.agenthub` are not writable. Writes, edits, shell commands and mutating git wait for approval unless the operator's permission mode grants them (writes and edits inside the grant filter in `ask-when-needed`, all four in `never-ask`; see below), and the approver sees what will be written or run, with control characters escaped. Everything it executes runs under the macOS sandbox, attended or not. Since 0.10 the profile starts from deny default (issue #39): commands run and read only the system, toolchain and project directories (and the project's git dir and the selected developer dir; with network on, the public CA bundles); no writes outside the project, its git dir and a temp dir of its own (`TMPDIR`, made for each command and removed when it ends; issue #63); no `.git` name at any depth, closing the creation, rename, symlink and gitfile routes to a planted repository, no `config`, `config.worktree` or `hooks` directly under one, nor in any submodule git directory (every modules tree the project can reach is covered: the common dir's, each linked worktree's own under `<common>/worktrees/<wt>/modules/`, matched by pattern so a tree or worktree that does not exist yet is covered too, and each discovered submodule git directory's own `modules/`, nested submodules and a submodule's own linked worktrees included; under a modules tree every write that is not inside a discovered submodule git directory is refused, whatever its name, so a fake git directory cannot be planted for a later unsandboxed `git submodule update --init` to reuse; inside each discovered one its own `config`, `config.worktree` and `hooks` and its linked worktrees' `config.worktree` are refused, while refs, logs, objects, the index and `HEAD` stay writable, so commit, branch, tag, gc and rebase work; a linked worktree's git directory under `<common>/worktrees/` gets the same `config`, `config.worktree` and `hooks` refusal; every term is anchored at the discovered path, `hooks` by depth, so a directory named `config` or `hooks` above the project neither disables the rule nor trips it; the discovered git directories, the modules roots, the worktrees container, each worktree git directory and every component in between are also refused as targets, closing the rename, replace and symlink routes to the same files), no `commondir` at any depth below one, with every such name matched folded against the code points HFS+ ignores (the fold covers the security-relevant names; on a volume that folds names, folded spellings of the components between `.git` and a submodule's git directory are not matched — the 1024-byte SBPL literal cannot hold a folded path — the same residual the external git dir rules carry since #270), and no `.agenthub` anywhere in the project (in an external git dir the `config`/`config.worktree`/`hooks` rules cover only its own children and the hooks directory's contents, so refs named `config` or `hooks` still work); a nested repository in bare layout stays open — the directory is the git dir, with no `.git` name to anchor a rule on, and the hub never runs git there, whatever the project root is: its calls are all `-C <project root>` or `--no-index` on temp files, and none descends into a nested directory's git layout, so a planted hook fires only if a person or another tool runs git in that directory themselves; the rules are probed on HFS+, which folds the 16 code points the patterns tolerate, and on a case-sensitive APFS image, which folds nothing (a folded spelling is an inert new file there and the real names stay refused); the shared object store takes only new loose objects (#864): `objects/info` (alternates, http-alternates, commit-graph) and `objects/pack` are refused, and so are the `objects`, `objects/info` and `objects/pack` entries, moving a fan-out directory, and changing, removing or replacing an existing loose object, because git reads packs first and never rehashes what it reads, so a planted pack or alternate would change what every checkout and the implementer's host add, commit and push (#845) see; a hardlink to an existing object is refused as well; an object id that does not exist yet can still be planted before git writes it (its exact content must be predicted), which a local checkout then shows, while a push of it is rejected by the receiving side's rehash; the cost is that `git init`, `git clone` and `git worktree add` do not run inside the sandbox (add, commit, stash and checkout still do; `git gc`, `repack`, `fetch` and `maintenance` run outside it, #864), `git submodule update --init` does not either (its git directory's `config` write is refused), and neither do `git worktree remove`, `git worktree prune` of a stale record, `git clean -ffd` in a project with a nested repository, or `rm -rf` of a directory that holds a `.git` (refusing the unlink is what stops the rename-out route); no network, loopback included, unless `local.bash_network`; with it, only through the hub's egress proxy to the hosts in `local.network_allow` (issue #65), which refuses names that resolve to internal addresses (behind NAT64 with the well-known prefix, by the IPv4 address the answer carries; a network-specific prefix is not recognised), so claude-mem and the Codex app-server stay out of reach (`"direct"` opens everything, until 0.13.0). One channel stays open: `trustd`, which TLS clients need, can fetch a certificate's AIA or OCSP URL on a command's behalf, outside the proxy. The allow-default profile of 0.9 and earlier was removed in 0.12.0 (issue #83); a `local.sandbox` setting is ignored with a note. The shared temp dirs (the user's and `/private/tmp`) are closed. Without the sandbox there is no `bash` tool. Two opt-in tools, both machine-local and off by default, work outside the command sandbox: `doc_read` (`local.doc_read`) reads a PDF, DOCX or HWPX file through the path guard and the `pii.paths` screen, converts it with the person's `text_projection` and screens the text before the model sees it; `web_fetch` (`local.web_fetch.allow`) sends a bare https GET only to the listed hosts, through its own egress proxy (never the shell's), re-checking every redirect, and is refused for the whole turn of a PII task. Neither result is captured to memory.
 - **Capabilities are enforced, not suggested.** `capabilities` (issue #39) is checked by the daemon where task operations and messages arrive, so a peer cannot get round it by phrasing. A peer can never answer a permission request: the control link takes `permit` from the console role only, and a message that quotes a permit command is just text. Both bind the hub's own tool paths: a vendor agent with its own shell in the project (Codex, Claude, Kimi) can read `.agenthub/state/control-token` and connect as the console, which only the local worker's and Pi's sandbox prevents.
 - **PII has an enforced path.** A task matching `signals.pii_patterns` goes to `local` or to nobody; its text is absent from other peers' envelopes, the console stream, the log and the board listing; the console user reviews it; `local` answers such a turn to the console only, keeps it out of its history, refuses it when the only gateway is off campus, and may not save notes or spin off tasks during it. Nothing about it enters hub-managed memory; local storage does not relax this privacy fence.
-- **A model screen can add to the patterns (issue #198).** With `signals.pii_screen = "local"` in `routing.toml` (default `off`; it applies while `constraints.pii = "local_only"`), a newly proposed task is read by a model before the hub does anything else with it: until the verdict it is on no board, in no envelope, before no triage model, and the hub makes no brief or note call for it. The local worker's amem capture leaves its hub tool calls out (issue #230), so a proposal it makes in an ordinary turn cannot reach shared memory ahead of the verdict that way. The screen runs on the model on this machine (MLX or Ollama, loopback only) or, without one, on the gateway only while `onCampus()` holds, and the gateway call is refused once more right before transport if the gateway is behind Access; task text never goes off campus to be screened. When the on-device generation slot is taken (Pi generating, another screen), the screen goes to the campus gateway instead of waiting, and on campus a device that fails or is still loading after 60% of the deadline hands over to the gateway too; off campus it waits for the slot and the device within the deadline. With the legacy MLX provider the screen may start an `mlx_lm.server`, as Pi's relay does, and it stays running until `ahub models stop`. Its answer is `pii` or `clear` plus a category from a closed list (name, student id, phone, address, grade, health, other). Anything else, a timeout (8 s, one call and one generation slot per item), a missing or off-campus model, or text longer than 6000 UTF-8 bytes (about 2000 Hangul syllables) is `unknown`, and an unknown task is a PII task: this is the hub's one model call that fails closed, so with the screener down every new task waits for `local`. An unknown verdict has the costs of any PII task, even when a second look clears it later: opening it lifts every silent turn-free cohort for good and turns facts off while it is open, and off campus a proposal without a class is refused (triage is not asked for a PII task there), with an error that says so. Off campus with the on-device slot taken, a task stays `unknown` until it is screened again: while it is still proposed and no peer ever owned it, the hub's release timer (every 60 s, one task at a time, the least tried first, at most 10 times per task in a hub run; never text too long to read) asks again, and `clear` lifts its `pii` signal and routes it through the class peers (a named owner is not remembered; a reserved one is offered first, as always). A task `local` took keeps its PII path, also once it is declined back to nobody. A pattern match is PII without a call. The task's history records the source of its `pii` signal (`regex`, `screen` with the category, or `unknown` with the reason), an unknown verdict is a console line naming the task id only, and `events.jsonl` gets a `pii_screen` record with the item kind, label, source, category, reason and latency, never the text. A routing explanation of a draft does not call the screen and says so.
+- **A model screen can add to the patterns (issue #198).** With `signals.pii_screen = "local"` in `routing.toml` (default `off`; it applies while `constraints.pii = "local_only"`), a newly proposed task is read by a model before the hub does anything else with it: until the verdict it is on no board, in no envelope, before no triage model, and the hub makes no brief or note call for it. The local worker's amem capture leaves its hub tool calls out (issue #230), so a proposal it makes in an ordinary turn cannot reach shared memory ahead of the verdict that way. The screen runs on the model on this machine (MLX or Ollama, loopback only) or, without one, on the gateway only while `onCampus()` holds, and the gateway call is refused once more right before transport if the gateway is behind Access; task text never goes off campus to be screened. When the on-device generation slot is taken (Pi generating, another screen), the screen goes to the campus gateway instead of waiting, and on campus a device that fails or is still loading after 60% of the deadline hands over to the gateway too; off campus it waits for the slot and the device within the deadline. With the legacy MLX provider the screen may start an `mlx_lm.server`, as Pi's relay does, and it stays running until `ahub models stop`. Its answer is `pii` or `clear` plus a category from a closed list (name, student id, phone, address, grade, health, other). Anything else, a timeout (8 s, one call and one generation slot per item), a missing or off-campus model, or text longer than 6000 UTF-8 bytes (about 2000 Hangul syllables) is `unknown`, and an unknown task is a PII task: this is the hub's one model call that fails closed, so with the screener down every new task waits for `local`. An unknown verdict has the costs of any PII task, even when a second look clears it later: opening it lifts every silent turn-free cohort for good and turns facts off while it is open, and off campus a proposal without a class is refused (triage is not asked for a PII task there), with an error that says so. Off campus with the on-device slot taken, a task stays `unknown` until it is screened again: while it is still proposed and no peer ever owned it, the hub's release timer (every 60 s, one task at a time, the least tried first, at most `tasks.rescreen_max` (default 10) times per task in a hub run; never text too long to read) asks again, and `clear` lifts its `pii` signal and routes it through the class peers (a named owner is not remembered; a reserved one is offered first, as always). A task `local` took keeps its PII path, also once it is declined back to nobody. A pattern match is PII without a call. The task's history records the source of its `pii` signal (`regex`, `screen` with the category, or `unknown` with the reason), an unknown verdict is a console line naming the task id only, and `events.jsonl` gets a `pii_screen` record with the item kind, label, source, category, reason and latency, never the text. A routing explanation of a draft does not call the screen and says so.
 - **Free text is screened too.** On an ordinary task, a done summary (with its check output: a match withholds the whole note), a review note, an unmet item or a budget handoff that matches a PII pattern (issue #69) is not saved to hub-managed memory, and every peer, `local` included, gets a stub naming `ahub task show <id>`; the board keeps the text, `hub.log` notes the withholding by task id only, and `ahub ask` shows such a note only when its model is reached on campus. `hub_remember` refuses a match; what a vendor agent writes to its own memory is not screened. With the model screen on, the same items (and `hub_remember` notes) go through it as well, one call each and only after the call's own checks (owner, state, verdict, a running check, memory enabled) pass: a `pii` or `unknown` verdict withholds the item exactly like a pattern match, and the board marks the history entry (`withheld`) so later views (task lists, completed-change notices, `ahub ask`, a reviewer replaced after a restart) keep withholding it. A budget hand-off is screened once per hand-off, whatever the number of tasks it moves; an escalation's reason is the hub's own text and is not screened. Pattern-only, without the model: the check output tail in a done note (only the summary is screened), a plan given with `hub_task_accept`, a decline reason, a task's refs (paths, branch), and context checkpoint summaries. Ordinary-turn amem capture uses deterministic secret, routing-pattern and private-path screening of complete input/output before bounding; it makes no model classification or network call. Private turns remain excluded before capture. Raw capture is machine-local and never curated evidence. Tools are identified by host session/turn/step/invocation rather than trusting provider ids to be unique. Its hub tool calls (`hub_send`, the task tools, the conductor tools) are not captured (issue #230), so a title, detail, done summary, review note or `hub_remember` text it writes reaches shared memory only through the screened paths above.
+- **Sources and the notes corpus are read through screens.** Registered sources (`ahub source add`, a person's command, #508) are screened by `pii.paths` and the PII patterns when added and again, with the model screen when it is on, each time `hub_source_read` reads one; a failed or unavailable screen counts as private, a private verdict is never downgraded, and private text goes only to the in-process local worker during a PII task turn with a confirmed on-campus gateway. The notes corpus (`corpus.paths`, machine-local, #510) refuses a folder that is, sits in or holds an Obsidian vault, a protected folder or anything it cannot read, indexes structure but not text, and rereads and screens a note before an excerpt reaches `ahub ask` or a task brief; a PII question or private task context never queries it. `hub_source_read` calls and results are never captured to memory.
 - **Secrets stay where they are read.** The gateway key and Cloudflare Access values are read inside the gateway client and go only into request headers: never into logs, errors, envelopes, tool output, memory. Subscription logins of Claude, Codex and Kimi are never proxied or pooled.
-- **The hub's own model calls are fenced.** Digest condensation, task triage and the PII screen read agent-written text as data; their output is capped text framed as untrusted, or a value checked against a closed list. It is never used as a route, a peer id, a tool call or an instruction.
+- **The hub's own model calls are fenced.** Digest condensation, task triage and the PII screen read agent-written text as data; their output is capped text framed as untrusted, or a value checked against a closed list. It is never used as a route, a peer id, a tool call or an instruction. The hub model's intake split (#511) is JSON that must pass the same parts schema a planner's `hub_backlog_split` takes and may name only the request's own sources; it only writes draft backlog cards that wait for a person's or the conductor's `intake approve`, and a PII request goes only to a model reached on campus, else stays unsplit.
 
 ## Native memory authority and profile selection
 
-The portable core is the exact-pinned first-party `@staix/agent-mem` 0.11.0 package; it does not replace the hub's caller identity, PII policy or task-write authority. Deny, hardened git, real paths and process identity are single-sourced in its Node-safe platform entry. Current project privacy is applied by the hub before promotion and again before model-facing reads. Standalone person reads are unscreened, and the standalone `--policy-free` acknowledgement grants no hub or peer authority.
+The portable core is the exact-pinned first-party `@staix/agent-mem` 0.13.0 package; it does not replace the hub's caller identity, PII policy or task-write authority. Deny, hardened git, real paths and process identity are single-sourced in its Node-safe platform entry. Current project privacy is applied by the hub before promotion and again before model-facing reads. Standalone person reads are unscreened, and the standalone `--policy-free` acknowledgement grants no hub or peer authority.
 
 `hub_memory_search`, `hub_memory_show` and `hub_memory_graph` take the project from the daemon, require `memory_read`, refuse private turns and validate UTF-8 input before logs or storage work. Complete records and graph metadata are screened before counts and truncation. Search is at most 20 lines/4 KiB (default 8); show accepts at most 8 ids and returns at most 8 KiB; graph is at most 120 nodes/240 edges/6 KiB (default 60 nodes), with no edge lacking an endpoint. Unknown, ambiguous and withheld ids share one neutral refusal. Arguments and results are excluded from hub-managed capture; this does not govern a vendor's independent transcript or memory hooks.
 
@@ -37,6 +38,131 @@ Before migrating any real home, every hub sharing it must first be on 0.12.30 or
 
 On a home split by `amem migrate --shards`, the hub opens only its own project's shard, with the user shard as overlay, under the alias-resolved project key (#534, #537); other projects' private notes are not in that store. Each memory entry rechecks the shard identity, and an alias that later remaps the key latches the binding unavailable. A split that is not active refuses and is never read as an empty or legacy store. A hub on 0.12.36 or earlier does not detect a split and keeps writing the old layout, so every hub on the home must run 0.12.37 or later, or be stopped, before splitting. `ahub memory profile-check` is split-aware (#536): it compares each running hub with its own project's shard and reports an inactive split with the resume remedy.
 
+## Headless Claude failure diagnostics (#845)
+
+A failed owned Claude print result can carry the last observed failure stage:
+`pre_permission`, `invalid_permission_request`, `wrapper_refused`,
+`manual_queue_expired` or `native_error`. `pre_permission` means only that no
+host permission observation was recorded; it does not diagnose an unseen native
+MCP or provider failure. Wrapper refusal requires a matched host ticket refused
+before spawn. Target timeouts, disconnects, surviving descendants, output failures
+and a target's nonzero exit are not wrapper refusal. Ordinary proof fallback to
+person approval is not a failed execution.
+
+Evidence contains only the daemon's actual permission id when known, the daemon
+instance UUID and the parsed native version from its binary-fenced proof. It
+contains no command, input, prompt, native `tool_use_id`, wrapper ticket,
+launch/session id or native diagnostic prose. PII or unreadable privacy emits
+only `Claude implementer turn failed (details withheld)`, or the fixed host fact
+`Claude implementer cleanup incomplete; details withheld` when cleanup is
+incomplete. Native stderr remains
+ignored. The original task 544 incident and real-account approval behavior are
+not established by these diagnostic fixtures.
+
+The host trace belongs to an exact owner, launch, generation and signal. It is
+sealed before child authority is revoked and consumed once after exit; success
+and cancellation discard it. Later permission attempts, expiry and stale or
+foreign launch traffic cannot rewrite the sealed result.
+The MCP wire cannot authenticate whether the native dispatcher or the model sent
+a permission call: the stage describes the last request observed on that wire.
+A probe starts a new diagnostic observation, so a pending older manual request's
+later expiry cannot overwrite it in the failure trace.
+
+Approval keeps the existing required-value checks and accepts extra argument
+fields. Diagnostic shape validation is separate.
+
+`permission_failure_probe` is a separate validation-only control operation. Its
+temporary finite JSON input is capped before send at 4,096 UTF-8 bytes, depth
+eight and 256 nodes, and limited to four attempts per owned launch by both client
+and daemon. The daemon validates then drops the payload, retaining only a fixed
+stage. It never invokes approval or execution, echoes input, or accepts a caller
+stage enum. Every request id gets a reply. An old daemon's unknown-op reply,
+an unavailable probe, or even a response claiming allow cannot change the
+channel's fixed denial of the malformed native request. Skipped oversized probes
+make no invalid-stage claim.
+
+## Encrypted rooms (#446 X1)
+
+X1 is the crypto and wire layer the later room slices build on: the blind broker
+(X2), outbound membership and enrollment (X3), screened application traffic (X4)
+and the metadata views and person inbox (X5) are described below. The [X1 protocol
+contract](specs/2026-09-19-agent-hub-design.md#encrypted-rooms-x1-crypto-and-wire-contract-446)
+fixes algorithms, canonical transcripts, limits and the required durable host ports.
+Bun 1.4.2 is the minimum; room operations await a cached built-in WebCrypto
+known-answer/negative self-test, which the broker's startup and every wire operation
+await before effects.
+
+The intended broker is untrusted: it may drop, reorder, replay or replace packets.
+Owner-signed membership and key wraps, member signatures, authenticated encryption
+and invitation HMAC protect the accepted content/key bindings. Labels, exposed
+local peer ids and body/addressing metadata are encrypted. Room ids, hub public
+keys/fingerprints, epochs, recipient hub sets, packet sizes, timing and network
+endpoints remain visible. Encryption cannot ensure availability or hide traffic
+analysis. Members holding an epoch root can read that epoch's recorded traffic;
+recipient lists enforce delivery policy, not secrecy from other room members.
+Long-term key theft plus recorded wraps defeats past confidentiality; this is not
+a forward-secret group protocol. A revoked member retains old plaintext and keys
+but receives no new epoch wrap. Current membership must refuse its traffic even
+within the previous epoch's 60-second grace.
+
+Private key export is explicit machine-local storage, not a transport format.
+X3 must enforce 0700 directories/0600 files, durable room/sender counters, atomic
+replay/inbox acceptance, one-time invite enrollment, persisted owner/epoch pins,
+and non-extending grace deadlines derived from local rotation installation time
+plus 60,000 ms. Frame nonces are random 96-bit values, independent of sequence;
+counter rollback therefore does not deterministically reuse an encryption nonce.
+Lost or rolled-back state still compromises replay freshness and ordering. X3
+must reconcile that state before delivery; fresh enrollment is a defence-in-depth
+recovery option, not a confidentiality prerequisite for nonce uniqueness. The X1 tests use memory state ports; they do not prove crash safety,
+filesystem permissions or publication races. A same-user malicious process and
+member key theft are outside this protection. Later X4 framing/PII/role boundaries
+must hold before decrypted bytes reach the local bus; crypto alone grants no tool,
+board, task, approval or memory authority. Native and two-machine use remain
+unverified until their named person legs are run.
+
+## Standalone blind broker (#446 X2)
+
+`ahub broker serve` is a separate person-started process, default loopback, with an
+explicit WSS audience behind operator TLS termination. Agent markers and
+`--live-test` delegation refuse before startup. No daemon listener, remote local
+peer, board/role authority or local room delivery is added by this slice.
+
+The broker receives public owner-signed rosters, challenge signatures and sealed
+X1 frames, never epoch roots, private hub keys or OOB invite secrets. It neither
+unwraps keys nor opens bodies. Immutable public proof products defensively copy
+bytes, Buffer included. One-use socket challenges bind broker audience, room,
+expiry, member and roster digest. Any Origin header refuses. Pinned owner/epoch/
+digest and installation + 60,000 ms grace survive restart. Removed members cannot
+authenticate or receive queued traffic; awaited work rechecks membership/generation
+before effects. Exact roster replays never refresh grace.
+
+Initial roster creation is restricted by a repeatable exact owner-fingerprint
+allowlist, mandatory for WSS public audiences and non-loopback binds. Open loopback
+mode is explicitly development-only and must not be proxied publicly. Authenticated
+but unapproved throwaway owners consume no room slots. Existing membership stays
+owner-signed; the creation allowlist alone is not a revocation mechanism.
+
+Count/byte/TTL-bounded private SQLite storage holds original encrypted packets.
+Exclusive kernel ownership prevents competing writers without stale-lock takeover;
+unknown/corrupt state fails closed. Populated unrelated or non-private directories
+refuse without chmod. An offline, person-only `broker room drop <room> --yes`
+reclaims one room under exclusive ownership, deleting its pins/floors/queue without
+resetting other rooms. Clients keep their own pins; remove an unwanted creator
+from the allowlist before restart. Indexed epoch/expiry maintenance avoids parsing
+all queued packets on ordinary reads, and a 4 MiB per-room byte share bounds one
+room's new admissions. Each recipient ACK affects only its own queue
+entry. Broker storage/queue ACKs never mean application completion. Logs/stats are
+fixed codes plus public ids/counts only; see the [X2 protocol and limits](specs/2026-09-19-agent-hub-design.md#encrypted-rooms-x2-blind-broker-446).
+
+Fixtures keep the encrypting client in a different process and check the broker's
+inputs, persisted data and logs for a unique plaintext canary. They do not establish
+live TLS, full heap forensics or two-machine delivery. A malicious peer can send
+its own plaintext; rejected networking bytes do not cease to exist in buffers.
+The confidentiality claim covers the sealed-client path. X3 host authorization/
+enrollment and X4 privacy/framing/role boundaries are in their own sections below;
+traffic metadata, availability, malicious owners and same-user compromise remain
+outside the encryption boundary.
+
 ## What is not defended
 
 - **A malicious local process running as you.** It can read the control token, `hub.db`, the project and your home directory without the hub's help. The token keeps web pages and other users out, not your own processes.
@@ -168,9 +294,9 @@ as that peer in tools mode. Messages and task changes retain that actor;
 `say` defaults to status priority and important messages still require the peer's
 capability. Conflicting or malformed markers fail closed. Refusals name only the marker variable names actually present, never their values. There is no `--as-user`.
 By default, console operations are refused before connecting, including permission answers
-and permission modes, queue resolution and bulk discard, agent version trust, budget overrides, benchmark runs, research
-backfill and task labels, stopping a peer (`ahub stop`), lifecycle and recovery
-operations, and `ask`.
+and permission modes, agent version trust, budget overrides, role assignment, `--as-user`, recovery
+operations, the interactive terminals (`watch`, `pet --window`, a launcher's person-only flags), and `ask`
+(#933 keeps the person's class to trust, money, attribution and interactive terminals).
 For live verification explicitly authorized by the user, an agent may invoke
 `ahub --live-test [--project <path|id>] <command> [args...]`. The flag delegates
 the existing console authority for console-class operations and conductor-class peer starts/holds, including approvals,
@@ -236,25 +362,92 @@ only with `assign` when its capabilities are listed).
 A conductor may inspect public state, assign or escalate work, start a peer in
 the start mode a person set (it cannot choose the mode) and place its own
 delivery holds. Through the `ahub` CLI under its own peer identity it may also
-run the closed operational family of #812: `roster add|remove`, `stop <peer>`,
-`queue show|resolve|discard`, `task cancel`, `doctor --orphans --kill`, `logs`,
-`export` and `settings set` on twelve named live keys. Each is admitted by the
-daemon after a recheck of the conductor role, and bounded; the effectful ones and
-the history reads are audited as a closed label with no argument text (`queue show`
-and a settings preview recheck the role without an audit record), a refusal of
-that authority is audited as refused, and an ordinary operation failure keeps its
-own cause rather than being reported as missing authority (#839): logs and export are public projections of the last
-100 lines and 1000 events, orphan cleanup signals only a positively identified
-hub-owned process of the selected project, and a stop keeps the existing
-ownership and recovery guards (`peer_stop` from a non-console connection is
-admitted only through this conductor check; no hub tool sends it). It still cannot answer
-approvals, override budget pauses, release a human hold, trust an agent version,
-authorize a release or run recovery resume, abort and reattach: those stay with
-the person. Other agents may run only the read-only forms of #812 (`doctor`,
-`projects`, `models status`, `recovery status`, `queue list`, `roster`,
-`settings` reads, `sdlc status|explain|queue|release`, `release show` and the
-`--dry-run` upgrade and restart previews) through the public views, never the
-console identity.
+run the closed operational family of #812 and #933: `roster add|remove`,
+`stop <peer>`, `queue show|resolve|discard`, `doctor --orphans --kill`, `logs`,
+`export`, `settings set` on thirteen named live keys, `board import`,
+`intake approve`, `schedule run|pause|resume`, `research backfill`, `bench run`,
+`source add`, `goal link` and starting a launcher-only peer the conductor may
+start (Jcode). Memory changes and the other `goal` changes stay the person's
+while amem records their actor as the user. `task unassign` is a conductor form;
+it keeps the conductor as the board actor. `task cancel` remains separately
+available through `hub_task_cancel` only on the caller's own eligible task
+(#933), not as a conductor operation; `task role`, `task label` and
+`ahub deliverables` retain their own-task checks. `models start|stop` and
+`pet --window` remain Console. `restart --yes`,
+`upgrade --yes --to <exact-version>` and `recovery resume|abort` have the
+separate continuity proof described below. Each conductor operation is admitted
+after a recheck of role and project membership; effectful operations and history
+reads are audited as closed labels without argument text (`queue show` and a
+settings preview recheck authority without an admission record), refusals are
+audited as refused, and ordinary operation failures keep their own cause (#839).
+Logs and export are bounded public projections; orphan cleanup signals only a
+positively identified hub-owned process in the selected project, and stop keeps
+its ownership and recovery guards. Other agents may run only the read-only
+forms of #812 (`doctor`, `projects`, `models status`, `recovery status`, `queue
+list`, `roster`, `settings` reads, `sdlc status|explain|queue|release`,
+`release show` and `--dry-run` upgrade/restart previews) through public views,
+never console identity. `backlog list`, `release list` and `sdlc costs|metrics`
+remain Console for ordinary agents.
+
+The recovery continuation is a separate, narrow capability, not a generic
+console command. Only the configured conductor currently connected to the source
+hub may receive a proof while creating that project's restart or authorized
+upgrade. The source stores a bounded, fixed-shape private operation record sealed by its host HMAC
+key, separate from public recovery JSON and actor/audit fields. It binds the
+initiating peer, operation, canonical project root/id, source instance, target
+root and package digest, plan fingerprint, and a version-neutral digest of
+bounded source inputs plus fresh actor/privacy evidence. The digest covers raw
+config-layer and routing-file texts, and the source-resolved public routing
+template bytes only when the project has no routing file. It does not hash
+expanded defaults, default roles or parsed routing. The public
+`conductorRoutingDefaults` map is advisory; the target inherits the sealed
+source fallback. The private record stores digests, not raw config, routing
+contents or the HMAC key. Every planned project's source capability and authority are
+preflighted before staging. An upgrade then stages and verifies its exact
+target; restart has no package stage. The source issues the HMAC record after
+target bytes and feature support are verified, before the public operation
+receipt, lock or runtime holds. A source preflight refusal prevents staging; a
+target mismatch or failed proof prevents the public operation and its holds. A
+target requiring a newer-coordinator handoff is person-only.
+
+Recovery cannot apply an unpublished protected configuration or routing edit.
+The source compares the fresh candidate and raw source inputs with its accepted
+running config/routing inputs. A conductor bootstrap verifies those same inputs
+against the private grant before module imports and uses the sealed source
+fallback when the project had no routing file; a later file edit cannot replace
+it. A person may explicitly take over recovery to adopt a changed policy.
+
+The coordinator must match the source-start package digest or the same
+authorized, verified upgrade target. Upgrade identity includes the exact
+hoisted `@staix/agent-mem` package; restart verifies the source package's own
+dependency. Another source tree or an invalid target version cannot obtain a
+continuation.
+
+Target compatibility labels are read from the sealed target bytes; a tools request or public receipt cannot waive a target feature floor. Computed or unreadable feature metadata remains person-only.
+
+Captured TUI terminal restoration remains person-only: a delayed native
+launcher cannot re-prove the conductor at its eventual spawn. Headless
+restoration uses the target-owned snapshot through a tools connection.
+
+An unmanaged reconnect-only Claude channel may reattach itself without a native launch. The source keeps a SHA-256 fingerprint of its observed session identity separate from restoration metadata (the raw unmanaged session id is omitted from the plan) and verifies the exact peer, kind and attachment against the live channel. This exception requires no terminal or restoration arguments, no managed launch proof, and an absent or confirmed-ended launcher; unknown launcher evidence refuses. Other peer identities still compare exactly.
+
+
+Before each effect and after awaits, the host rechecks the same initiating
+conductor's current role, roster membership, project and writable-instance
+authority, and non-PII/privacy policy. Offline checks are limited to bounded
+current actor and privacy evidence; unrelated public task writes do not revoke
+the proof. The same conductor may resume or abort only its own restart/upgrade
+operation. A different conductor or a person-created operation cannot be taken
+over with this proof; the person retains the normal recovery path. The detached
+`recovery-run` and launcher continuation accept only the captured operation and
+target arguments, never arbitrary CLI commands. Loss, replacement or unreadable
+proof refuses the next effect. This host HMAC record is not an OS boundary: a
+same-user process able to replace both the mode-0600 private key and record can
+replace the proof. The existing `--live-test` path is separate and does not mint
+this record or widen it into generic console authority. Fixture tests do not
+establish native-account or real-account evidence.
+
+Pending approval summaries exclude titles; PII tasks remain public stubs.
 Pending approval summaries exclude titles; PII tasks remain public stubs.
 Conduct events contain ids only. Supervision feeds use structured reasons and
 never carry check output or approval bodies.
@@ -270,7 +463,7 @@ Please report vulnerabilities privately through GitHub's "Report a vulnerability
 - The exchange creates a separate random session, valid for one hour without renewal, in an `HttpOnly; SameSite=Strict; Path=/` cookie named for this listener's port. Sessions and tickets live only in memory and die with the daemon. The page itself keeps one more cookie, `agent-hub-theme` (issue #246): script-set, `SameSite=Strict`, kept for a year for the whole `127.0.0.1` host, and read back only as one of `system`, `light` or `dark`. A second script-set cookie, `agent-hub-office` (issue #264), keeps the Office view choice under the same attributes and is read back only as `off`, `flat` or `isometric`. The #391 view split adds two more script-set cookies under the same attributes: `agent-hub-view`, read back only as one of the seven view names, and `agent-hub-column-focus`, read back only as one of the five board columns or empty. HTTP is loopback-only; the cookie is not a substitute for the origin checks.
 - Every request must have the exact listener Host. Every data or action request, including the ticket exchange and snapshot polling, must be POST with the exact listener Origin and JSON content type. Foreign and missing origins, missing or expired sessions, oversized bodies and unknown actions are rejected. There is no CORS support. The only unauthenticated GET is the fixed, data-free HTML shell. No files or paths are served dynamically.
 - Responses are non-cacheable, cannot be framed, suppress referrers, and use a content security policy restricting scripts/styles to the shipped inline content and connections to this origin. Browser text is rendered with textContent, never interpreted as HTML.
-- The browser receives a bounded redacted event stream, peer states and queue counts, public task views (with a task's screened changed-symbol observation, #684: ids, paths, names and kinds, never source or line spans, and its Code group, #684 phase 2c: those symbols marked against the plan's names, each name re-screened by the public metadata screen; a private task has no group and its plan names never enter the snapshot), budget windows, pending approvals, the settings rows (closed values and ids, the file each comes from) and each startable peer's start plan (issue #269), benchmark run summaries (issue #251): the newest runs in `~/.agenthub/bench/`, whichever project on this machine ran them, by suite name, arm label, state, the task id in progress, counts, tokens and times, never suite text, the Usage view (#683 U4), computed only while the Agents view is open: peer ids, UTC days and token counts with their source, budget pause, resume and reset events without their reason text, and per-task rows of the task id, a PII flag and token counts, never a title, and the office view's optional fields (issue #264): each peer's open turn (start time, attributed task id, attribution kind), a `checking` flag on tasks whose check is running, and warning `links` of overlapping, conflicting or cohort tasks (task and peer ids only, never paths, symbols or reasons; a PII task never joins a link, and a private or PII-attributed turn exposes no task id). Private envelope bodies and PII task text never cross this endpoint. Local-worker and Pi approval titles can contain PII, so their details remain terminal-only; the dashboard identifies the request and directs the operator to `ahub tail` before allowing it. Budget checkpoint summaries are also omitted.
+- The browser receives a bounded redacted event stream, peer states and queue counts, public task views (with a task's screened changed-symbol observation, #684: ids, paths, names and kinds, never source or line spans, and its Code group, #684 phase 2c: those symbols marked against the plan's names, each name re-screened by the public metadata screen; a private task has no group and its plan names never enter the snapshot), budget windows, each peer's DOING line (#878: a native session title or current plan item, at most 120 characters, kept in daemon memory only and screened when observed and again when shown; a failed screen, a private turn or the peer's open PII task shows `[private]`), pending approvals, the settings rows (closed values and ids, the file each comes from) and each startable peer's start plan (issue #269), benchmark run summaries (issue #251): the newest runs in `~/.agenthub/bench/`, whichever project on this machine ran them, by suite name, arm label, state, the task id in progress, counts, tokens and times, never suite text, the Usage view (#683 U4), computed only while the Agents view is open: peer ids, UTC days and token counts with their source, budget pause, resume and reset events without their reason text, and per-task rows of the task id, a PII flag and token counts, never a title, and the office view's optional fields (issue #264): each peer's open turn (start time, attributed task id, attribution kind), a `checking` flag on tasks whose check is running, and warning `links` of overlapping, conflicting or cohort tasks (task and peer ids only, never paths, symbols or reasons; a PII task never joins a link, and a private or PII-attributed turn exposes no task id). Private envelope bodies and PII task text never cross this endpoint. Local-worker and Pi approval titles can contain PII, so their details remain terminal-only; the dashboard identifies the request and directs the operator to `ahub tail` before allowing it. Budget checkpoint summaries are also omitted.
 - The closed action list includes permission response, peer pause/resume, console message, task proposal/assignment and the settings actions below (set, undo, preview, reload, and the structural edit preview and apply of a settings session). Project-board actions add revision-fenced planning, Backlog pull/return/split/undo and release planning/state changes through Tasks; they do not tag, publish or write GitHub state. These use the existing daemon/task paths and budget pause rules. `start_peer` (issue #269) starts a peer from a closed list in the mode a person set, with a command the hub assembles: the request carries a peer id and nothing else. There is no generic control proxy, task-detail read, shell, file access, free-form configuration edit, budget override, launch of a caller-chosen command or daemon shutdown API.
 - The listener stops with the daemon. Expired sessions must be reopened with `ahub ui`; the page does not silently obtain new credentials.
 
@@ -357,13 +550,13 @@ never-ask still requires the person's confirmation. qwen_cmd is machine-local an
 never editable through settings. Legacy benchmark adapters remain unmanaged by
 this production table. Startup diagnostics withhold native host/payload details.
 
-Jcode is optional, source/version-fenced and runs native tools without a hub sandbox or hub permission-mode mapping. .jcode joins the scoped-grant exclusion, including lexical/resolved aliases. Only a person writes its unique project MCP entry; foreign/override/symlink entries refuse. The hub owns a private daemon/socket and ACP group, never the global daemon, and copies no credentials. It accepts a plain jcode release from 0.98.0 up to, not including, 1.0.0 (#529; only 0.98.1, 0.99.0 and 0.99.1 are verified, and another version in that line starts with a note), or an exact version the person trusts (#691), and runs every owned jcode process (probe, serve, ACP and TUI) with `JCODE_NO_TELEMETRY=1`, because jcode's telemetry can report the provider account's email. Native diagnostics withhold payloads/hosts. Hub tools are bound to an owned launch (#368): the shared project entry names no peer, each owned Jcode process carries its own peer id and launch id, the daemon admits a hub-tools connection for a Jcode peer only with the id of that peer's current owned launch, and a tools-mode server started without a peer id refuses every tool. Extra Jcode instances (#685, at most 8) are declared only through `instances` in an untracked `.agenthub/config.local.json`, start headless, and each needs its own `jcode_home`, which may not be the base home or another instance's, nor nested in or around one, however it is spelled. Unproved conversation loads refuse; no fresh replacement is called a restore. A finished task's advisory about the project root checkout names the branch only after the hub's whole public-text screen (`Tasks.publicMetadataText`: a PII pattern, a secret shape and a project-private path) passes it and it is a plain ref name; otherwise a generic sentence carries no part of it (#572). Native TUI launch exposes its private socket/session tuple only to the authenticated console, bound to the same live owned socket and session after read-only native persistence proof. Tools/status do not receive it. The TUI has no single-writer guard: person input may interleave with ACP. Native policy remains unmanaged and closing the frontend does not stop ACP. An `important` message reaches a busy Jcode as a soft interrupt written to the hub's own private server socket for the owned session (#572); the hub never cancels a turn to deliver, and a steer that was sent but not acknowledged, or whose turn ended first, is held as `needs_review`, never replayed. Jcode has no switch to choose its MCP servers, so the owned serve and ACP processes load every server named in `<JCODE_HOME>/mcp.json` and the project's `.jcode/mcp.json`, `.mcp.json` and `.claude/mcp.json`, besides the hub's own; `ahub doctor` lists their names only. Point `jcode_home` at a separate home, or remove a server from those files, to keep it out.
+Jcode is optional, source/version-fenced and runs native tools without a hub sandbox or hub permission-mode mapping. .jcode joins the scoped-grant exclusion, including lexical/resolved aliases. Only a person writes its unique project MCP entry; foreign/override/symlink entries refuse. The hub owns a private daemon/socket and ACP group, never the global daemon, and copies no credentials. It accepts a plain jcode release from 0.98.0 up to, not including, 1.0.0 (#529; only 0.98.1, 0.99.0 and 0.99.1 are verified, and another version in that line starts with a note), or an exact version the person trusts (#691), and runs every owned jcode process (probe, serve, ACP and TUI) with `JCODE_NO_TELEMETRY=1`, because jcode's telemetry can report the provider account's email. Native diagnostics withhold payloads/hosts. Hub tools are bound to an owned launch (task 368): the shared project entry names no peer, each owned Jcode process carries its own peer id and launch id, the daemon admits a hub-tools connection for a Jcode peer only with the id of that peer's current owned launch, and a tools-mode server started without a peer id refuses every tool. Extra Jcode instances (#685, at most 8) are declared only through `instances` in an untracked `.agenthub/config.local.json`, start headless, and each needs its own `jcode_home`, which may not be the base home or another instance's, nor nested in or around one, however it is spelled. Unproved conversation loads refuse; no fresh replacement is called a restore. A finished task's advisory about the project root checkout names the branch only after the hub's whole public-text screen (`Tasks.publicMetadataText`: a PII pattern, a secret shape and a project-private path) passes it and it is a plain ref name; otherwise a generic sentence carries no part of it (#572). Native TUI launch exposes its private socket/session tuple only to the authenticated console, bound to the same live owned socket and session after read-only native persistence proof. Tools/status do not receive it. The TUI has no single-writer guard: person input may interleave with ACP. Native policy remains unmanaged and closing the frontend does not stop ACP. An `important` message reaches a busy Jcode as a soft interrupt written to the hub's own private server socket for the owned session (#572); the hub never cancels a turn to deliver, and a steer that was sent but not acknowledged, or whose turn ended first, is held as `needs_review`, never replayed. Jcode has no switch to choose its MCP servers, so the owned serve and ACP processes load every server named in `<JCODE_HOME>/mcp.json` and the project's `.jcode/mcp.json`, `.mcp.json` and `.claude/mcp.json`, besides the hub's own; `ahub doctor` lists their names only. Point `jcode_home` at a separate home, or remove a server from those files, to keep it out.
 
 Antigravity (`agy`, #485) is optional, cloud and off roster by default. The launcher accepts the Antigravity CLI 1.4.x line; only 1.4.2 and 1.4.7 have a native receipt ([1.4.7](verification/2026-10-26-agy-1.4.7.md)), so another 1.4.x patch launches with a warning that it is unverified, and every other version is refused before a hub connection or plugin write (#589) unless the person trusts that exact version (#691). It runs native tools under its own unmanaged permissions, without a hub sandbox or hub permission-mode mapping; headless, resume, unattended and native permission flags are refused. Its roles are capped at implementer and verifier, so it never plans, reviews or receives PII work. Only the person's `ahub agy` launcher writes its three plugin files in `.agents/plugins/agent-hub/` (`plugin.json`, `mcp_config.json`, `hooks.json`): linked or foreign entries refuse before any write, cleanup removes only that launch's matching files, and it never writes project-level `.agents/hooks.json` or the person's `~/.gemini` settings. Conductor starts are refused, and a declared agy extra instance is refused at config load (#625). Hook authority (`native_hook_launch`) comes only from that launcher, belongs to the console socket that began it and ends when that socket closes; hook input over 1 MiB is refused, and observations are bound to the daemon, launch, native session and project.
 
 Configured ACP adapters (#451 A3) are declared only by the person, in a Git-confirmed untracked `.agenthub/config.local.json`. The whole declaration (command, argv, identity, roles and mode maps) is machine-local authority: a shared or tracked declaration is ignored with a notice, settings never edit it, and changes need a hub restart. The hub runs only the declared argv, never a module or callback. Argv that selects a leader, attach, connect or remote mode is refused, and a Grok declaration needs `--no-leader`. Each start requires the pinned native identity, an exact `session/load` echo on resume, and positive ownership of the spawned process and its original process group; unknown ownership refuses, and stop signals only that verified group. An agent that hands its work to a process outside that group is outside this boundary. Without a mode map native policy is unmanaged, and there is no hub sandbox either way. Configured kinds are cloud peers (never PII), headless only and off roster by default, and the hub makes no quota, context or controlled-recovery claims for them. A read-only instance needs the native read-only mode acknowledged before a prompt and is limited to read and review hub tools, both in the published MCP list and at the host; its native non-read tool requests are rejected, and no setting or runtime change can raise it. These agents' stderr and error text are withheld from logs, and previews redact the executable, argv and session id.
 
-External adapter modules (#451 A4) are the one way to run adapter code that ships outside the hub, and the pin is code authorization, not a sandbox. `adapter_modules` is read only from a Git-confirmed untracked `.agenthub/config.local.json` (never from a shared, tracked or cloned config, and never written by settings or a hub tool). Only daemon startup imports a module, from the captured bytes that matched the `sha256` pin, not by reopening the path; the file must sit inside the project with no symlinked component and not be world-writable. Its imports are bound to the running hub's own `@staix/agent-hub/adapter` and builtins (`bun:ffi` and `bun:test` excluded), and dynamic imports, `require`, `eval` and `Function` are refused by a conservative scan. Once imported, the module runs with the daemon's privileges: the 2 s import deadline stops waiting but does not cancel its code or undo side effects, and the host's default against hub-tool title auto-approval holds only while the module keeps the factory options it is given. Inspect the whole bundle before recording its hash. Refusal reasons withhold source and module error text. A loaded kind keeps its own family, cloud trust (never PII), headless start and off-roster default, and fixed-builtin capabilities are refused. The daemon reads a native proof port (a status notice, the Codex frontend proxy, a native turn revert, a Claude launch proof) only from a fixed builtin definition, so a module product that carries one gains nothing (#790).
+External adapter modules (#451 A4) are the one way to run adapter code that ships outside the hub, and the pin is code authorization, not a sandbox. `adapter_modules` is read only from a Git-confirmed untracked `.agenthub/config.local.json` (never from a shared, tracked or cloned config, and never written by settings or a hub tool). Only daemon startup imports a module, from the captured bytes that matched the `sha256` pin, not by reopening the path; the file must sit inside the project with no symlinked component and not be world-writable. Its imports are bound to the running hub's own `@staix/agent-hub/adapter` and builtins (`bun:ffi` and `bun:test` excluded), and dynamic imports, `require`, `eval` and `Function` are refused by a conservative scan. Once imported, the module runs with the daemon's privileges: the 2 s import deadline stops waiting but does not cancel its code or undo side effects, and the host's default against hub-tool title auto-approval holds only while the module keeps the factory options it is given. Inspect the whole bundle before recording its hash. Refusal reasons withhold source and module error text. A loaded kind keeps its own family, cloud trust (never PII), headless start and off-roster default, and fixed-builtin capabilities are refused. The daemon reads a native proof port (a status notice, the Codex frontend proxy, a native turn revert, a Claude launch proof) only from a fixed builtin definition, so a module product that carries one gains nothing (#790). Extra instances of a module kind (#754) exist only when the module opts in (`headlessInstances`: headless, implementer, verifier or continuing reviewer) and the person declares them in `instances`. Each needs its own managed worktree, on an attached branch unless it is read-only, and is bound to what startup verified (module pin, API, capability and policy digests, execution root): a changed binding, a replaced worktree, a branch switch or a lost owned process revokes its authority, and a recorded native session resumes only under the exact same binding.
 
 # Transient ACP activity (#286)
 
@@ -476,9 +669,11 @@ Stall causes are persisted and deduplicated by cause and replanning revision. Pl
 
 `hub_delivery_retry` grants an eligible recipient one retry of its own `needs_review` work, never completion/discard authority or pause removal. Durable per-original evidence survives journal pruning; unknown retry history or a used retry requires the person. Hub presence prefaces are excluded from attempted-work identity, so a shared context preface does not consume an unrelated message's retry. Delivery-only local and ACP peers (including Jcode) cannot invoke recipient retry; tool exposure hints do not replace the daemon's actual-adapter guard. Their held work requires person resolution. Before transport handoff, storage failure preserves the queue and preface; after handoff an uncertain effect is never automatically replayed.
 
-A declared instance whose only role is reviewer gets review requests, task messages addressed to it and the person's messages; agent chat, digests and presence are discarded and journaled, and it gets no memory recall (#223). The headless Claude reviewer runs one new `claude -p` per review with `--setting-sources ""`, `--strict-mcp-config`, `--no-session-persistence`, tools limited to Read, Grep, Glob, `hub_review` and `hub_task_show`, and `dontAsk`. Its prompt holds hub facts and a bounded diff, never the builder's summary, and its `hub_task_show` drops the builder's notes. Changes touching `local.deny` or `pii.paths` are withheld and passed as `Read` deny rules, which Claude enforces, not the hub. Private tasks are never given to it. Its `hub_review` counts only while the child started for that task still runs; a stop or exit revokes it first, and surviving processes hold the delivery as `needs_review` and keep the reviewer busy.
+A declared instance whose only role is reviewer gets review requests, task messages addressed to it and the person's messages; agent chat, digests and presence are discarded and journaled, and it gets no memory recall (task 223). The headless Claude reviewer runs one new `claude -p` per review with `--setting-sources ""`, `--strict-mcp-config`, `--no-session-persistence`, tools limited to Read, Grep, Glob, `hub_review` and `hub_task_show`, and `dontAsk`. Its prompt holds hub facts and a bounded diff, never the builder's summary, and its `hub_task_show` drops the builder's notes. Changes touching `local.deny` or `pii.paths` are withheld and passed as `Read` deny rules, which Claude enforces, not the hub. Private tasks are never given to it. Its `hub_review` counts only while the child started for that task still runs; a stop or exit revokes it first, and surviving processes hold the delivery as `needs_review` and keep the reviewer busy.
 
-A terminal Claude implementer or verifier instance (#525-5) owns write-class tasks only after the daemon proves its execution root: the current launch id, a private single-link launch record naming the root, the cwd the channel's MCP server reports (verified model-free on Claude Code 2.1.309) and the daemon's own validation of the declared non-canonical branch worktree must all agree, and the proof belongs to the attached claim generation and socket. A detach, a replacement claim or a changed launch record revokes it. Missing, legacy or mismatched evidence still attaches the channel, but write-owner routing is refused and facts grants give nothing, never a fall-back to the canonical tree; terminal recovery revalidates the recorded root against the current declaration. This is same-user launch evidence, not filesystem isolation: Claude can still write wherever its own permissions allow.
+A terminal Claude implementer or verifier instance (#525-5) owns write-class tasks only after the daemon proves its execution root: the current launch id, a private single-link launch record naming the root, the cwd the channel's MCP server reports (verified model-free on Claude Code 2.1.309) and the daemon's own validation of the declared non-canonical branch worktree must all agree, and the proof belongs to the attached claim generation and socket. A detach or a replacement claim revokes it; a changed launch record, worktree or branch is caught and revoked at the next routing admission, facts permission reply or recovery owner proof, before any effect (status shows the last verified binding and grants nothing). Missing, legacy or mismatched evidence still attaches the channel, but write-owner routing is refused and facts grants give nothing, never a fall-back to the canonical tree; terminal recovery revalidates the recorded root against the current declaration. This is same-user launch evidence, not filesystem isolation: Claude can still write wherever its own permissions allow.
+
+A planner-only instance (#525-6: `planner` without `implementer` or `verifier`) plans on the project checkout, so a declared `worktree` is refused. A Codex planner's `thread/start` and `thread/resume` are requested read-only, and a thread is adopted only when Codex's reply positively confirms a read-only sandbox; an unconfirmed or malformed reply refuses that RPC and closes the link before the hub adopts the thread or delivers work, and the current roles are rechecked before each injection. This is an initial ceiling, not confinement of the person's attached TUI, which can change its native sandbox later. A declared planner-only Claude channel instance gets no automatic grant from its facts hook for any tool but Read, LS, Glob and Grep, whatever the permission mode.
 
 The headless Claude implementer (#525-4) runs one owned `claude -p` child per turn in its declared worktree, with `--setting-sources ""`, `--strict-mcp-config`, native permission mode `default`, the hub's managed PreToolUse hook and `--permission-prompt-tool mcp__agent-hub__hub_permission_request`; never `--bare`, `acceptEdits`, `dontAsk` or `bypassPermissions`, and `never-ask` is refused. Each task keeps its own persisted session; unscoped chat reuses one only while exactly one task is in progress, and a `hub_inbox` read refuses a batch attributed to another task. The approval path fails closed: `hub_permission_request` is accepted only from the current child's launch and generation, goes to the console's existing approval queue and `approvals.timeout_s`, and offers allow-once and deny only, with no allow-always or session grant. A timeout, a prompt failure, a disconnect, a hub that is down or refusing, or a stale child binding answers deny; a failed hook decides nothing, so the call still waits for a person. The approval title is the tool name and a JSON rendering of the arguments passed through `sanitize()` and the public-text screen (any PII, secret or private-path match withholds the whole value as `[withheld]`, before any cut), never task text, cut at 600 characters with a `[cut, N chars]` marker; the original arguments stay with the child and are not logged. The MCP wire cannot tell a native permission dispatch from a call the model makes itself; a person allow still refers only to its original arguments. Automatic Bash authorization uses the separate single-use host wrapper contract below, never a caller-supplied tool id as native provenance. A stop holds an uncertain delivery until the owned process group is confirmed gone. The [native permission receipt](verification/2026-10-23-headless-claude-permissions.md) is model-free on Claude Code 2.1.309, [repeated on 2.1.310](verification/2026-10-26-claude-implementer-2.1.310.md); it is not sandbox proof, and a real account, model and person interaction remains a live leg.
 
@@ -494,9 +689,9 @@ The fresh Kimi reviewer (#533) needs `review_mode: "fresh"` and a compat-admitte
 
 The review brief (#520) withholds private changes whole (both sides of a move) and counts them; a rule file that fails the private-data screen is named, not shown. Attributes and rules are read at the merge base, so a change cannot loosen its own review. Optional changed symbols (#684) come from ripwire 0.6.7 on the daemon's host PATH, run as an owned process on a disposable snapshot of the task's commit; each path, name and kind passes the hub's public metadata screen before the brief, the console's task detail or the dashboard shows it, a private task stores and shows none, and a failed or missing read is `unknown`, never a gate. Spec acceptance, plan review, plan conformance, premature-review, cost, test-integrity (#481 S4), issue and PR identity linking (#694) and dogfood scorecard (#687) reads fetch GitHub metadata only (edit times, check states, thread authorship and resolution, changed file names, open PR heads, workflow run conclusions), never issue bodies, comments or patches. Issue identity linking at propose and accept (#723) parses the task's title and refs locally, reads nothing from GitHub and skips PII tasks. The CI workflow keeps `contents: read` and `actions: read`.
 
-Deliverable records (#509a). `hub_task_done` and `hub_sdlc_record` name files as `{path, format, version?}`; the hub hashes them itself and refuses a claimed `sha256`, `hash` or `bytes` and any field it does not own. Paths resolve under the owner's execution root with `realPath` and `guardPath` in read mode: outside the project, the secrets denylist, the hub's own state (`.git`, `.agenthub`), a dangling link, a non-regular file and more than 256 MiB each or 512 MiB together are refused, with the path as given and never a resolved one. The file is opened without following a final link and its device, inode, size and time are compared with what was checked, before and after the read, so a swapped or changing file is refused rather than recorded half-read; a bad call writes nothing. A declared worktree instance whose root is not proven refuses, and a later read of it reports `unknown`. No hash of hub state is ever taken, and a file the hub cannot read or vouch for is `unknown`, never `unchanged`. A reviewer's approval re-hashes the files and is refused when one changed, went missing or is unknown; only the person may approve the current bytes, which are then measured and bound. For a PII task, a file under `pii.paths` or a path matching a PII pattern, `publicDeliverables` is the one projection every peer view, review request, status and log uses: id, hash and size only. The board keeps the path, as it keeps a PII task's text. `ahub deliverables` (#509b) is the person's: an agent shell is refused and `--live-test` cannot delegate it. It lists the board's records through `publicDeliverables` and opens a file only with `--check`, through the same reader and limits. The dashboard's Deliverables chip and task group use the same projection of the same records and never read a file on the poll; a `changed` mark there is only as fresh as the last live read in this daemon.
+Deliverable records (#509a). `hub_task_done` and `hub_sdlc_record` name files as `{path, format, version?}`; the hub hashes them itself and refuses a claimed `sha256`, `hash` or `bytes` and any field it does not own. Paths resolve under the owner's execution root with `realPath` and `guardPath` in read mode: outside the project, the secrets denylist, the hub's own state (`.git`, `.agenthub`), a dangling link, a non-regular file and more than 256 MiB each or 512 MiB together are refused, with the path as given and never a resolved one. The file is opened without following a final link and its device, inode, size and time are compared with what was checked, before and after the read, so a swapped or changing file is refused rather than recorded half-read; a bad call writes nothing. A declared worktree instance whose root is not proven refuses, and a later read of it reports `unknown`. No hash of hub state is ever taken, and a file the hub cannot read or vouch for is `unknown`, never `unchanged`. A reviewer's approval re-hashes the files and is refused when one changed, went missing or is unknown; only the person may approve the current bytes, which are then measured and bound. For a PII task, a file under `pii.paths` or a path matching a PII pattern, `publicDeliverables` is the one projection every peer view, review request, status and log uses: id, hash and size only. The board keeps the path, as it keeps a PII task's text. `ahub deliverables` (#509b) from an agent shell lists only the tasks `hub_task_show` would show that agent (#933), and `--live-test` cannot delegate it. It lists the board's records through `publicDeliverables` and opens a file only with `--check`, through the same reader and limits. The dashboard's Deliverables chip and task group use the same projection of the same records and never read a file on the poll; a `changed` mark there is only as fresh as the last live read in this daemon.
 
-Person release authorization (#481 S6). `ahub sdlc authorize-release <version>` is taken from the console role only and refused under `--live-test`. It binds the daemon checkout's commit, package version, push remote identity and a fresh-docs verdict, lives only in daemon memory (a restart revokes it) and is logged with its commit, version and docs digest. `ahub sdlc release-guard -- <argv>` is a read-only preflight that agents may run, except during a private or PII turn; it never executes the command and refuses ambient target selectors (`GIT_DIR`, `GH_REPO`, npm prefix and registry settings and the like). The pre-push hook that `ahub init --release-guard` installs refuses an unauthorized or unknown `v*` tag push, also with the daemon down, and passes other pushes through. It and the release block in `AGENTS.md` are a cooperative guard, not an operating-system boundary: `git push --no-verify`, a custom `core.hooksPath` or another Git invocation bypasses the hook, and `gh release create` and `npm publish` are checked only when the preflight is run (#312, #313).
+Person release authorization (#481 S6). `ahub sdlc authorize-release <version>` is taken from the console role only and refused under `--live-test`. It binds the daemon checkout's commit, package version, push remote identity and a fresh-docs verdict, lives only in daemon memory (a restart revokes it) and is logged with its commit, version and docs digest. `ahub sdlc release-guard -- <argv>` is a read-only preflight that agents may run, except during a private or PII turn; it never executes the command and refuses ambient target selectors (`GIT_DIR`, `GH_REPO`, npm prefix and registry settings and the like). The pre-push hook that `ahub init --release-guard` installs refuses an unauthorized or unknown `v*` tag push, also with the daemon down, and passes other pushes through. It and the release block in `AGENTS.md` are a cooperative guard, not an operating-system boundary: `git push --no-verify`, a custom `core.hooksPath` or another Git invocation bypasses the hook, and `gh release create` and `npm publish` are checked only when the preflight is run (tasks 312 and 313).
 
 SDLC metrics and control bands (#481 S7). `ahub sdlc metrics` and `hub_sdlc_metrics` are planner or person only, read-only, and refused during a private or PII turn. A private task is counted as withheld and read for nothing else; the report calls no model and makes no GitHub read. Band breaches are written only by the daemon's evaluator through Tasks, never while it is stopping, recovering or has a storage error. A `diagnose` or `propose` card is a backlog task (`triage` or `plan`) whose text is fixed words, numbers and task ids, never task text; it passes the PII signal check and the candidate-text screen before it is written, and no GitHub issue is created. A `log` breach is one hub notice, remembered in the board's `band_notices` table as a marker (`<metric>:#<task>:log`, checked against a fixed pattern) and a time, nothing else.
 
@@ -528,3 +723,170 @@ Routing receives capability availability and its reason as pure inputs. Capabili
 ## Structured capture write screening
 
 The amem host screens the actual data that may persist, including literal keys/values and its JSON form. It decodes authoritative tool argument/result JSON once before any excerpt cap, so escaping cannot hide whitespace-matching PII, a private data path or a structured secret key/value. It does not recursively interpret arbitrary embedded encodings. Non-persisted host locators (cwd and transport/session identifiers) are kept outside text-policy content; current project/profile authority is checked separately. Ordinary events with a valid private-path policy still capture public data. Private turns remain excluded before this code runs.
+
+
+### X3 outbound room administration
+
+Room mutations require a person console and refuse agent markers and `--live-test`.
+One-use connection tickets let the CLI print both fingerprints before any room
+install or invitation consumption. Execution then requires an explicit TTY y/N
+(default No), or a matching 16..64 lowercase-hex member fingerprint prefix through
+`--confirm`; the daemon verifies that confirmation against the ticket. Abort, EOF
+and missing/mismatched confirmation install and consume nothing. Joining pins the owner from a private OOB
+invitation; a broker-provided key or roster cannot establish that pin. The
+invitation secret is sent only to the joining person, never to the broker. The
+HMAC'd request and signed roster omit it and every private key.
+
+Room identity, consumed invitations, owner/epoch pins and sequence/replay records
+are machine-local in a private SQLite store (0700 directory/0600 database), under
+exclusive process ownership. Restart never resets counters or extends the persisted
+60-second adjacent-epoch grace. Clock rollback, unknown schema and corrupt state
+refuse. This is not protection against another process running as the same user.
+Machine-local exposure policy and the signed roster must both permit a presence id.
+Status/read output has ids, epochs and link states only. Presence contains no task
+text, titles or credentials; no chat or remote tool effect is enabled by X3.
+
+Local leave retains pins and replay records; actual member revocation is the owner's
+signed epoch rotation. Broker storage ACKs never assert application completion.
+The live TLS/proxy/two-machine receipt and X4 envelope privacy boundary are separate
+obligations, not proved by the fake broker/hub integration tests.
+
+Canonical refused or stale room frames are durably recorded as digest/fixed-reason/
+timestamp diagnostics before a broker transport retirement ACK. This drops a
+poison queue head without accepting its body, advancing replay state or issuing
+an application-completion receipt. Unproven session/recipient authority or failed
+durable storage receives no ACK. Only bounded diagnostic records may be evicted;
+sequence/replay records retain their existing rules.
+
+
+## Screened room application traffic (#446 X4)
+
+Room encryption authenticates a hub, not local role authority. Remote ids contain
+`@` and cannot connect to local control, own tasks, review, plan, conduct, start a
+native runtime or become a recovery session. Incoming chat is explicitly directed
+to a current exposed local native peer, framed as untrusted, and capped at status.
+The same live sender-exposure check applies to restored inboxes. A removed
+sender's registered pending application is quarantined before its plaintext is
+retired, so it remains available for person disposition.
+
+`roomBoundary` is the outbound privacy owner. It snapshots inputs, drops refs,
+refuses private/PII/unknown-authority contexts and rechecks after awaits. Host
+private-turn provenance is retained at enqueue, so waiting offline cannot wash
+it away. Screen failure sends only a fixed stub with a public application id.
+Optional model screening uses the existing local/campus-only rule; unknown
+never permits the body. Patterns/models do not prove that paraphrased text is
+free of private meaning. Remote bodies enter no digest model, memory observation,
+public event payload or hub log; the local delivery journal retains the evidence.
+The local worker disables Capture and tool-body observation for an entire mixed
+or remote-origin turn, and does not commit that transcript to reusable local
+history. A later local-only turn therefore cannot capture the retained remote
+input through that history. Single Claude channel pushes sanitize bodies just
+as digests do.
+
+Recipient room/fingerprint bindings survive queued, active and uncertain journal
+work. Label reuse cannot retarget old text, including an explicit retry after
+restart. X4 permits one remote destination per send and refuses multiple remote
+targets before any local effect; implicit broadcast never crosses the boundary.
+
+Signed completion proves remote durable queue admission only and is displayed as
+completed (admitted). Crypto inbox, application claim and Bus publication use
+separate durable stages; a cross-DB failure is uncertainty, never an exactly-once
+or native-execution claim. Late proof cannot auto-settle uncertainty. Person
+accept/discard is local disposed metadata and never a signed application receipt.
+
+Schema3 reserves a separate durable lane for at most eight canonical receipt
+payloads per room, at most 1,024 bytes each and 512 KiB extra globally. A receipt
+can take a reserved slot only after its authenticated sender and exact
+frame/application/peer match this hub's outstanding outgoing row. Authenticated
+junk cannot consume the reserve. Normal chat retains its 200-row/16 MiB ceiling;
+presence, signatures and replay floors are unchanged. Settlement frees the slot,
+and reopen validates the marker, payload and bounds, refusing an over-cap store.
+Legacy rows migrate as ordinary rows, never with inferred receipt authority.
+Only at the physical cap, a current authenticated member's non-matching receipt
+is durably refused with `invalid_frame` and transport-ACKed without advancing
+the floor. A matching receipt with a full reserve remains unACKed until a slot
+frees. Neither path invents admission or a signed application outcome.
+Fully validated presence at the ordinary cap is durably refused with
+`invalid_presence` and transport-ACKed without a floor or state observation.
+Capacity recovery requests fresh presence once per transition; runtime and
+other storage errors stay unACKed.
+Fresh, fully authenticated chat at the ordinary cap is likewise durably refused
+and transport-ACKed without admission, floor advance or signed receipt. Its
+sender remains uncertain until the application ACK deadline; the refused chat
+cannot hold matching receipt traffic behind it in the broker FIFO.
+
+Permanent signed sequence floors survive all application retention/eviction.
+Application-id and trace guards retain 30 days/10,000 rows per room, settled first;
+outside that retention they make no historical claim. MAX_HOP 3 remains absolute.
+All-unsettled capacity refuses with ids/counts, and person disposition releases
+settled capacity. This state protects against other users, not hostile code
+running as the same user with access to the private room keys. Native/account,
+live TLS/proxy forwarding and X7 two-machine behavior remain unverified here.
+
+An X4-only receiver is a one-way room endpoint for a person. Replies to
+`user@label` receive an authenticated unsupported-person-inbox NACK, retained as a known terminal
+`failed_safe` outcome, never silently retried or claimed as person admission.
+X5b adds the separate durable inbox boundary below.
+
+### X5 metadata views
+
+The console Rooms panel (`8`) and dashboard Agents > Rooms use only the canonical
+room metadata projection: local name/id, epoch, owner/self fingerprints, member
+count, link state and exposed peer ids/states. No body, title, reason, broker URL,
+key material or delivery history enters this projection. Reading it creates no
+room storage or keys; missing rooms stay hidden and unavailable metadata stays
+explicitly unknown.
+
+Relay counts are daemon-session observations, reset at restart: successful
+outbound handoffs, confirmed inbound admissions and withheld handoffs as a subset
+of outbound. Missing values remain `null`/unknown rather than zero. They neither
+certify native completion nor reconstruct historical traffic. This display adds
+no body delivery or authority and never reads X5b inbox bodies.
+
+### X5b person inbox
+
+The only inbox-body output is the person's `ahub room inbox show <id>`, one
+untrusted frame with hub-header sanitization and terminal controls stripped.
+Inbox list is metadata-only, including `--json`; show/done/discard accept no JSON
+output or fingerprint-confirmation flag. The RPC checks the console role; as
+with X3, agent/conductor and `--live-test` refusal occurs at the CLI before it
+connects. Console hello has no delegation marker, so the RPC does not separately
+identify a raw console connection as live-test. Dashboard/status projections, logs,
+memory, models and observers receive no body or title. Reads and dispositions
+also refuse during recovery or a Bus hold in this first slice.
+
+`completed/inbox_admitted` is an immutable receipt of durable inbox admission,
+not a person-read or work-completion receipt. Done/discard/expiry purge the body
+locally and retain only metadata; they neither resend nor revise admission.
+Duplicate delivery cannot re-admit or increment inbound counts twice.
+
+The private local store uses the existing protected directory/file modes, with
+plaintext bodies and no added at-rest encryption or secure-erasure claim. Caps
+are 100 unread messages per room, 64 KiB decoded body each and 4 MiB stored
+canonical payload bytes globally, counting JSON overhead and escaping; metadata
+`bytes` still means decoded UTF-8 body size; the unchanged entire-wire cap further limits sendable
+content. Schema 4 binds the 30-day TTL to the first durable local crypto arrival.
+Unknown-age legacy person traffic fails safely with `inbox_age_unavailable`,
+without changing native peer admission. Settled stubs retain at most 1,000 per
+room for 30 days after settlement, oldest first; unread rows and their admission
+identities, and shared-cap unsettled identities, are protected. The loaded-state
+30-second expiry hook covers left rooms without creating a store or keys.
+
+Metadata list replies cap at 1,100 complete rows; larger global lists explicitly
+refuse and ask for a room filter, rather than truncating. Older X4 codecs reject
+the new fixed inbox receipt reasons, leaving uncertainty rather than claiming
+mixed-version delivery success. Live two-machine/account evidence remains
+separate.
+
+Person disposition and actual TTL purge can wake existing X4 deferred traffic
+once, without a new outcome or receipt for the purged entry. Idle expiry ticks
+never poll plaintext; all resumed traffic retains the existing trust and role
+checks.
+
+Indirect TTL cleanup retains one committed wake signal until the host consumes
+it; a rolled-back cleanup cannot create a signal. This adds no body to the wake
+path and no polling when no real cleanup occurred.
+
+Done/discard acknowledgement precedes the background room retry. A network retry
+failure or socket loss during that later work cannot report a committed local
+disposition as failed.