Detached sub-agent runs show "Done (0s | 0 tokens)" while running, never correct, and the Background panel lists no agent row

Summary

A detached (background) sub-agent is reported as finished the moment it is dispatched. Its card in the chat log reads Done (0s | 0 tokens) while the run is live, and never corrects — a run that consumed 6,690,434 tokens over 6m 55s still read 0s | 0 tokens minutes after it finished. The Background panel (Ctrl+B / the N shell… indicator) never shows the agent at all, only shell tasks, so the one surface a user would open to inspect background work omits it entirely. Nothing is delivered to the session when a run completes, so the only way to learn an outcome is to poll agent_output — which is accurate, and disagrees with both other surfaces.

Reproduced twice, in two separate sessions, across four detached runs.

Impact

• A 6,690,434-token, 6m 55s run was reported as 0s | 0 tokens; the work was very nearly discarded as a no-op because the only visible telemetry said nothing had happened.
• Recovering outcomes required a hand-rolled stack — disk-mtime monitors, a shell task watcher, a periodic poll loop and a completion webhook — standing in for a missing event.
• The same blind spot caused a mis-diagnosis in the other direction: a read-only (diagnosis) task writes no files while working, so a write-based watchdog cannot see it and it was killed as "stalled" on no evidence.

Expected Behavior

1. A detached run's card reflects reality — live duration/tokens while running, or in-progress, and correct figures on completion.
2. The Background panel lists detached agent runs, not just shell tasks.
3. A truncated or limited run is distinguishable from a successful one.
4. A detached run's completion is delivered to the session, rather than requiring a poll.
5. Dispatched ids stay resolvable for the life of the run.
6. A run is identifiable: its agent_id (and a trace id) surfaced on the card and in agent_output, so a wrong card can be tied to the run it describes.
7. If a caller requests a foreground run while the agent definition sets background: true, that is stated in the output rather than silently detaching.

Actual Behavior

1. The chat-log card reports a finished, zero-cost run for a live one

While a run was live — agent_output {action:"status"} reporting running for 144587ms, elapsed climbing across successive calls (5016 → 144587 → 209064 ms) — its card read:

EXTRA-REVIEWER  [independent round-3 diff review]
 └  Done  (0s | 0 tokens)

Reproduced immediately with two concurrent runs, both live at ~8s elapsed, both cards reading Done (0s | 0 tokens). In the clean re-test, the card read:

EXPLORE  [Sequential file summaries]
 └  Done  (0s | 0 tokens)

for a run that was status: running at the same moment.

This is not a stale launch stub — a stub would not say Done.

2. It never corrects

run	real outcome (via agent_output)	card
bg-1-c84b102b	completed · 414,925 ms · 6,690,434 tokens · 100 turns	Done (0s | 0 tokens)
bg-1-5b52abc5	completed · 176,921 ms · 805,826 tokens · 16 turns	Done (0s | 0 tokens)
bg-2-c52cde0d	completed · 56,049 ms · 525,726 tokens · 13 turns	Done (0s | 0 tokens)
bg-3-1a202d0f	completed · 47,177 ms · 332,615 tokens · 9 turns	Done (0s | 0 tokens)

Minutes after completion the card was still there, still reading 0s | 0 tokens ("I am pretty sure it won't [disappear]… It's been minutes"). So the telemetry is permanently wrong, not delayed.

3. The Background panel lists no agent row

In the controlled re-test a shell probe ran alongside three detached agents. The panel showed only the shell — 1 active shell … (running), rendering correctly throughout — and at the end: "there's nothing in the background panel". No agent row appeared there, live or completed, for any of the runs. The frozen card is not a panel row; it is in the chat log ("not in the agent chrome at all").

Related: Ctrl+B did nothing in a session that had a detached agent running but no shell task, and worked once a shell existed — so the panel's keyboard route appears gated on a shell task, which is exactly the case where you would want to inspect an agent-only session.

4. Completion is never signalled to the session

Across every run above, nothing arrived unprompted on completion — no event, no message, no wake. Each finish was discovered only by an explicit agent_output {action:"status"} pull or by reading the no-id inventory.

Tested deliberately: one detached run was left with no polling and no timer attached. It completed (414,925 ms / 6,690,434 tokens) and the session was told nothing; the result existed only inside agent_output. The run was read-only, so there was not even a file mtime to notice.

5. A truncated run reports completed

The same run hit a 100-turn cap and stopped mid-sentence — its entire output a narration line ("…next I'll inspect the feed removal, the channel-log opt-in, leftover producers, and the migrated wait signals") with no findings. status reported completed, indistinguishable from a successful review. An orchestrator that did not go and read the output would count a lost deliverable as a done task.

6. Ids intermittently unresolvable

Two dispatched runs returned Unknown background agent: bg-2-b19561c4 and Unknown background agent: bg-3-45814fc7 while still in flight, so the documented collection path could not be used for them. (Not seen in the clean re-test, where ids stayed resolvable and two concurrent runs worked correctly.)

7. No per-run identifier, and no trace id

The dispatched-run card shows the agent name and task description but no run id; the only card carrying an id is the sibling AGENT(output) [<agent_id>] card. There is no per-run trace id anywhere either — scanning the session transcript for trace/request ids returns nothing, and agent_id is the sole identifier recorded. A misreported card therefore cannot be tied to the run it describes, even after the fact. (/trace copies a session-level trace id.)

Steps to reproduce the issue

1. Create an agent definition carrying background: true, or dispatch with run_in_background: true.
2. Dispatch it for a read-only task that will run for a couple of minutes.
3. Start a long shell task as a control, then open the Background panel (the N shell… indicator — down-arrow, or Ctrl+B). The panel lists only the shell row; no agent row appears, live or completed.
4. Look at the chat log while the run is live: the card for the run reads Done (0s | 0 tokens). Compare agent_output {agent_id, action:"status"}, which reports running for <ms> for the same run at the same moment.
5. After completion the card still reads Done (0s | 0 tokens), and is not removed.
6. Note that no completion event is delivered; the only reliable signals are external — watch a file the agent writes, or poll agent_output on a timer.

What does work (useful for triage)

• agent_output with no agent_id lists background agents with status, type and description — a genuine inventory (though entries do age out over a long session).
• agent_output {agent_id, action:"status"} reports live elapsed time (running for 144587ms). This is the only reliable liveness signal, and it is correct throughout.
• agent_output {agent_id, action:"wait"} returns on completion — a true completion edge, but nothing invokes it: it must be called, and the wait is cancelled outright if the user sends a message.
• task_list / /todos only reflect what the orchestrator put in the task ledger; here it was empty, so it is not a view of what a sub-agent is doing.

Command Code Version

1.54.2

Operating System

Linux

Terminal/IDE

Unknown

Shell

zsh

Session file (optional)

command-code-session-65f49d3b.truncated.json

(not the file type is .jsonl, the drag drop doesn't let me use that filename)

Fix prompt (optional)

No response

Additional context

No response

Reproduce ejecuciones desacopladas mediante el flujo de dispatch documentado y compara después la tarjeta de chat-log y el panel Background con el estado y la espera de agent_output; usa la tarea de shell como control. Se considera terminado cuando la telemetría en vivo y final es precisa, las filas de agentes y los identificadores son visibles, las ejecuciones truncadas se pueden distinguir, la finalización llega a la sesión y los ids enviados siguen pudiéndose resolver.