Files
platform/todo/background-jobs/a-spawned-agent-is-invisible-in-the-interface.md
T
pastilhasandClaude Opus 5 7ce5af88aa todo: close the invisible spawned agent
The endpoint, table and ingest all existed and nothing called them, so the table
read empty and the feature looked unbuilt. Ingest on read means an empty table was
itself the symptom: nobody had looked.

The proposed second fix — the loop echoing the transcript id — turned out
unnecessary. The ids are already in the loop's spawned record, which the endpoint
ingests, so they reach the UI without the loop narrating anything.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 04:55:11 +00:00

52 lines
2.9 KiB
Markdown

---
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/<its-id>` 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/<id>`, 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.