--- 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/` 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".