pastilhasandClaude Opus 5
530e5880e1
Closed: - fleet/an-orchestrator-that-acts-on-every-server-at — built, and as none of the three shapes it proposed. Not a script, not a screen, not a chat capability: an agent handed a written procedure and a server list it has to read rather than one baked into it. All three verified facts in the item earned their place; two things it did not anticipate are now new items. - fleet/a-way-to-mark-a-commit-this-one-ships-so-a — built as a TAG, which the item explicitly ruled out. The owner reversed it, and the argument that changed his mind is recorded: a codeword can be written by accident, because every document about deploying contains it, so the trigger needs rules about where in a subject line it sits and a rule like that is one somebody eventually gets wrong. Opened, all from tonight and all with the evidence attached: - a deploy verifies pm2 and not that the app serves anything — the commander raised this against itself - the commander cannot finish its own host, so one machine is always a build behind - the watcher loop is rewritten by an agent every arming, so its correctness is re-rolled each time - plugins:update restarts every sidecar, so a report naming only officer understates what moved - an agent spawned by a background job is invisible in the UI while being perfectly readable - AskUserQuestion can fail to parse its own call - a commander opened from /chat loses its commander controls, because isCommander comes from the screen rather than the session Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.8 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| background-jobs/a-spawned-agent-is-invisible-in-the-interface | An agent spawned by a background job is invisible in the interface | background-jobs | open | 2026-08-21 | stated | 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.28for 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".