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>
33 lines
1.8 KiB
Markdown
33 lines
1.8 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: open
|
|
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".
|