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

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

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