--- id: background-jobs/a-spawned-agent-is-invisible-in-the-interface title: 'An agent spawned by a background job is invisible in the interface' theme: background-jobs status: done created: 2026-08-21 date_source: stated order: 1 --- **An agent spawned by a background job is invisible in the interface, even though it is fully readable.** A watcher loop that fires spawns `claude -p`, and that child writes an ordinary transcript under the project directory for its cwd. So it opens in `/chat/` like any other session — verified on 2026-08-21 while the deploy was mid-flight: fourteen messages, the right cwd, rendered live in the normal chat view with no work needed. Nothing in the UI tells you that id exists. The parent's job panel shows the child's `stream-json` piped through `jq`, which is genuinely good — you see its tool calls as they happen — but it is a text stream in a small box, and there is no link. You can only find the session by knowing to look for it. Two fixes, and the small one is most of the value: - **Have the loop print the transcript id as its first line.** One `echo`, no platform change, and the id becomes clickable-by-copy in the panel the owner is already watching. - **A real row for it.** The child is a genuine session with a genuine cost; Command HQ could file it against the commander that spawned it, which would also fix cost attribution — today the child's tokens land nowhere, so a commander's cost line reads `$0.28` for a night that spent several dollars. The second one needs a decision about what the child _is_. A commander is defined by its directory (`isCommandersDir`), and the child runs in the platform checkout, so it does not qualify — deliberately. Making it visible probably means a different relationship than "another commander". --- **Closed 2026-08-23.** The commander's pane lists its spawned agents, each a link to `/chat/`, with a dot on the ones still running. Worth recording what the work actually turned out to be. The endpoint (`GET /command-hq/commanders/:id/children`), the `command_hq_spawned` table and the ingest were all built earlier the same night — and **nothing had ever called them**, so the table read empty and the feature looked unbuilt. Ingest happens on read rather than on a timer, which means the table being empty was itself the symptom: nobody had looked. The second fix this file proposed — the loop echoing the transcript id — was not needed in the end. The ids are already in the loop's `spawned` record, which the endpoint ingests, so the id reaches the UI without the loop having to narrate it. Cost attribution is partly addressed and honestly so: the pane shows a floor (`$1.20+`) with a count of children that reported no cost, never a confident total. The remaining gap is that a child's spend does not flow back to the commander's own cost line — that is cost accounting, deferred by the owner, and not this.