[Feature] Local browser dashboard for daemon-backed sessions and subagent trees

[mahmutkaya]

Area

Coding agent and CLI

Problem

Prime Agent's only interface is the TUI, but the runtime underneath it stopped being single-session a while ago. A supervisor routes many resident workers, each owning a root session tree with RLM descendants, schedules, heartbeats, and goals that keep running after the terminal detaches (docs/daemon.md, docs/long-running-agents.md). There is no way to survey that state.

Concretely, today:

• prime-agent agents is the only cross-session view, and it is TTY-only. It occupies a terminal, shows one pane, and cannot sit on a second screen while I work in the first.
• Watching a detached agent means attaching to it, which occupies a terminal and bumps attachedClients. Watching three means three terminals.
• Reviewing a long session means /export to HTML, which is a dead snapshot. Re-exporting to see progress is not a workflow.
• Subagent trees are the main thing I want to see at a glance during recursive work, and they are the hardest thing to inspect. Their transcripts are not even in sessions/ — they live under session-artifacts/<root>/sub-<childId>/<uuid>.jsonl.
• Reading a wide diff, a rendered image, or a long tool result inside a terminal viewport is the weakest part of an otherwise good UI.

The docs already point at a browser client as the answer and then stop short of one. docs/sdk.md lists "Build a custom UI (web, desktop, mobile)" as its first use case, docs/rpc.md says RPC exists for "custom UIs", and docs/agent-connection.md states the invariant such a client must respect: "the UI can be rich and client-specific, but it cannot own agent execution." Nothing in the repo takes that offer up, and I could not find an existing Discussion, Issue, PR, or branch on the topic.

Proposed direction

A local browser dashboard for observing and managing daemon-backed sessions. Read-only first, interactive later.

The framing I would like to check with you before anything else: this is core/export-html/ made live, not a new design language. template.css and template.js are already a complete session renderer with a tree sidebar, search, the default/no-tools/user-only/labeled-only/all filters, diff rendering, ANSI conversion, and an image modal. generateThemeVars() already projects every theme token into --<token> CSS vars, and prime.json already fixes the palette. A live UI should reuse that renderer and those tokens verbatim so the browser and the TUI cannot visually drift.

Shape:

packages/web-bridge/   new Node package, deps: @earendil-works/pi-coding-agent
                       DaemonClient(defaultDaemonSocketPath()) for read fan-out
                       DaemonAgentConnection per opened session for live parity
                       relays DaemonOutbound to the browser over SSE
                       owns 127.0.0.1 bind, bearer token, Origin check, command allowlist
web/                   browser bundle, renderer forked from export-html/template.{css,js}

Three invariants keep it additive:

1. No daemon protocol change. Existing commands and events only, so none of the version-bump, schema-revision, compatibility-map, or cross-version test requirements in AGENTS.md are triggered.
2. No edits to packages/agent, ai, coding-agent, or tui. The packages/* workspace glob, the root tsconfig.json include, and the biome.json includes pick a new package up on their own. The one optional exception is appending a segment to the root build script.
3. The UI never owns execution. Every mutation goes through the daemon; the browser holds no session state that the daemon is not already the source of truth for.

Phasing, each a separate reviewable unit:

1. Read-only. Session list from list, classified with the already-exported buildAgentsViewRows / classifyAgentsViewSession / filterUnifiedSessions so it matches prime-agent agents exactly rather than reimplementing the rules. Transcript from get_messages + get_session_tree. Subagent tree. Live updates relayed from session_event / session_status. Theme switching from the existing theme JSON.
2. Interactive. prompt / steer / follow_up / abort, queue view, model and thinking controls, compact, refine, and the extension UI request/response round trip.
3. Management. Goals, heartbeats, cron, and the agent-messaging graph.

The security model is the part I would most like reviewed, because the bridge is the entire boundary. daemon-supervisor.ts marks every accepted socket authenticated: true before reading anything, so the filesystem is the only gate on the daemon socket today. That is fine for a Unix socket at 0600 in a 0700 directory and wrong the moment a browser page can reach it. My assumption is: loopback bind only, a bearer token minted per bridge start and printed once, an Origin/Host allowlist, READ_ONLY_DAEMON_COMMANDS as the default allowlist with writes behind an explicit opt-in flag, and browser-facing DTOs versioned at the bridge edge rather than passing AgentMessage / AgentEvent through raw, since daemon-protocol.ts and agent-connection/types.ts are explicit that those are local TypeScript contracts and not a stable network schema.

Alternatives considered

• ACP mode. The right answer for driving Prime Agent from an editor, and I am not proposing to replace it. It is one session per connection with a fixed cwd, so it cannot express a dashboard over the sessions that are already running.
• RPC mode. Full command surface, but a client spawns its own process. It cannot observe the resident workers a user already has, which is the entire point here.
• /export HTML. Already the visual baseline I want to build on, but a static snapshot.
• Reading sessions/*.jsonl directly. Works with no daemon and is the most stable schema in the repo, but gives no live events, cannot mutate, and silently misses every subagent unless the reader also walks session-artifacts/. Useful as a degraded fallback, not as the design.
• Building it out-of-tree against the published SDK. Entirely viable, since DaemonClient, defaultDaemonSocketPath, DaemonAgentConnection, the AgentConnection interface, and the agents-view helpers are all already exported. This is my open question below.

Additional context

I am not a vouched contributor, so I am not asking to open a pull request. I am asking whether this direction is wanted at all, and in which of two forms:

1. In-tree as packages/web-bridge plus a web/ bundle, or
2. Out-of-tree as a separate package consuming @earendil-works/pi-coding-agent.

If the answer is (2), or if you would rather see it before deciding, I will build it out-of-tree and come back to this Discussion with a working read-only dashboard and screenshots, so there is something concrete to judge instead of a proposal.

Two implementation notes from reading the source, in case they are useful independent of this request:

• docs/daemon.md and docs/agent-connection.md both state protocol v4. The source is DAEMON_PROTOCOL_VERSION = 7 with DAEMON_SCHEMA_REVISION = 16 (packages/coding-agent/src/modes/daemon/daemon-protocol.ts:53-63). Happy to send that doc correction on its own if you want it.
• A dashboard should poll list + get_state and attach only to the session actually being viewed, since attach bumps attachedClients and feeds worker residency and idle eviction. Observing should not change scheduling behavior.

One constraint I would want confirmed either way: if a browser client is unwanted in this repo for reasons beyond scope, say so plainly and I will keep it out-of-tree. It is more useful to know that now than after the code exists.