Bug description
When Claude Code is waiting for asynchronously launched Agent subagents, abtop reports the parent session as Waiting even though the subagents are still actively working and updating their transcripts.
This makes the top-level status misleading when monitoring multiple long-running Claude Code sessions: ◌ Wait normally means the session needs user input, but in this case no input is needed and work is still in progress.
Steps to reproduce
- Start a Claude Code session.
- Ask Claude to launch one or more
Agent subagents.
- With current Claude Code, observe that the
Agent tool receives an immediate tool_result saying that an async/background agent was launched, including an agentId and output file.
- Let the parent emit a text-only assistant message while it waits for the subagent results.
- Open abtop (optionally enable the subagent tree with
T).
Expected behavior
The parent session should remain active, preferably Executing, while any of its subagents is still working.
Actual behavior
The parent session changes to Waiting while its subagent transcripts continue to update. The subagent tree may simultaneously show working subagents under a parent marked Wait.
Reproduction evidence
I reproduced this from a real session with two anonymized subagents:
- The first
Agent tool received its async result about 176 ms after launch, but its subagent continued writing for another 14m 59s.
- The second received its async result about 61 ms after launch, but continued writing for another 13m 40s.
- After the parent's later text-only assistant message, the two subagents remained active for about 14m 02s and 13m 08s respectively, during which the parent could be classified as
Waiting.
A minimal regression fixture using this transcript sequence also reproduces it:
user prompt
assistant Agent tool_use
user tool_result: async agent launched, running in background
assistant text-only message: waiting for research result
subagent JSONL still recently updated
The expected parent status was Executing, but the result was:
left: Waiting
right: Executing
Root cause analysis
The Claude collector currently determines parent status using only:
- active descendant CPU,
- a non-empty
current_task (pending tool), or
- a trailing real user message (
last_user_ts_ms).
Relevant code:
For an async Agent call, Claude Code writes the tool result immediately. A subsequent text-only assistant entry clears current_task, and the subagent may not appear as a CPU-active descendant process. The status therefore falls through to Waiting even though collect_subagents() can see a recently active subagent.
PRs #84 and #101 fixed a closely related case where a normal tool_use remains pending, and their existing regression test passes. However, async Agent calls return their tool_result immediately, so that pending-tool signal cannot represent the remaining subagent lifetime.
Possible fix
As a minimal fix, collect subagents before calculating parent status and classify the parent as Executing when any subagent is working.
The existing 30-second transcript-mtime heuristic may still flicker during a long subagent model generation. A more robust implementation could track the async lifecycle by linking the toolUseId in *.meta.json with the agentId returned by the parent Agent tool result.
Environment
- abtop:
0.5.3
- abtop commit:
a3328db20fe189887986e0147080954bc07178a1 (current main and v0.5.3)
- Claude Code:
2.1.212
- OS: Ubuntu 24.04, Linux 6.8.0-117-generic x86_64
Bug description
When Claude Code is waiting for asynchronously launched
Agentsubagents, abtop reports the parent session asWaitingeven though the subagents are still actively working and updating their transcripts.This makes the top-level status misleading when monitoring multiple long-running Claude Code sessions:
◌ Waitnormally means the session needs user input, but in this case no input is needed and work is still in progress.Steps to reproduce
Agentsubagents.Agenttool receives an immediatetool_resultsaying that an async/background agent was launched, including anagentIdand output file.T).Expected behavior
The parent session should remain active, preferably
Executing, while any of its subagents is stillworking.Actual behavior
The parent session changes to
Waitingwhile its subagent transcripts continue to update. The subagent tree may simultaneously show working subagents under a parent markedWait.Reproduction evidence
I reproduced this from a real session with two anonymized subagents:
Agenttool received its async result about 176 ms after launch, but its subagent continued writing for another 14m 59s.Waiting.A minimal regression fixture using this transcript sequence also reproduces it:
The expected parent status was
Executing, but the result was:Root cause analysis
The Claude collector currently determines parent status using only:
current_task(pending tool), orlast_user_ts_ms).Relevant code:
current_taskis cleared on every assistant entrycollect_subagentsalready derivesworking/doneFor an async
Agentcall, Claude Code writes the tool result immediately. A subsequent text-only assistant entry clearscurrent_task, and the subagent may not appear as a CPU-active descendant process. The status therefore falls through toWaitingeven thoughcollect_subagents()can see a recently active subagent.PRs #84 and #101 fixed a closely related case where a normal
tool_useremains pending, and their existing regression test passes. However, asyncAgentcalls return theirtool_resultimmediately, so that pending-tool signal cannot represent the remaining subagent lifetime.Possible fix
As a minimal fix, collect subagents before calculating parent status and classify the parent as
Executingwhen any subagent isworking.The existing 30-second transcript-mtime heuristic may still flicker during a long subagent model generation. A more robust implementation could track the async lifecycle by linking the
toolUseIdin*.meta.jsonwith theagentIdreturned by the parentAgenttool result.Environment
0.5.3a3328db20fe189887986e0147080954bc07178a1(currentmainandv0.5.3)2.1.212