Subagent results never returned to the main conversation (Agent tool); result unrecoverable

Status Open
Reported on v2.1.238
Maintainer reply None cached
Activity 0 comments · opened Aug 20, 2026

Summary

Results returned by subagents spawned with the Agent tool never reach the main
conversation. The subagent runs to completion and its side effects are real, but
its final message is never delivered as a tool result. The main loop receives only
a bare {"type":"idle_notification","idleReason":"available"} with no payload.

The result is then unrecoverable: it is not delivered on request via SendMessage,
and it is not persisted anywhere on disk.

Environment

  • Claude Code 2.1.238
  • Linux 6.18.35.2-microsoft-standard-WSL2 (WSL2)
  • Node v24.18.0

Reproduction

Spawn one subagent ("controller") and instruct it to spawn two subagents of its
own. Each of the two must write a file with the Bash tool and return a line of
text. The controller must combine both returned lines and return them.

Having the workers write files matters: filesystem side effects are the only
independent evidence of what actually ran, since the returned text never arrives.

Expected

The controller's final message is delivered to the main conversation as the
Agent tool's result.

Actual

The controller completes, then emits only an idle notification with no content.
No tool result is delivered.

Where the fault is

Everything except the last hop works:

  • Spawning subagents works.
  • Nested spawning works — a subagent can spawn its own subagents.
  • Subagents execute tools correctly. In the repro both workers wrote byte-exact

files 0.5 s apart, confirming genuine concurrent execution.

  • Worker -> controller return works. The controller could not have completed

otherwise.

  • Controller -> main conversation return fails. This hop only.

Not recoverable after the fact

  • SendMessage to the idle subagent asking for its result: sometimes returns the

report after a delay of several minutes, but frequently returns nothing at all.
In the minimal repro above it produced only a second bare idle notification.

  • Session transcript at ~/.claude/projects/<project>/<session>.jsonl contains

zero isSidechain entries. The subagent's conversation is not persisted, so
there is nothing to harvest.

Impact

Any multi-agent workflow silently loses work. In one real case, six subagents were
dispatched to perform an analysis; four returned nothing, two returned only after
being individually prodded, and the four lost reports could not be recovered. The
failure is silent — from the main loop it is indistinguishable from a subagent
still working.

Additional observations

  • ListAgents never lists in-process subagents, before or after a restart. It

shows only unrelated peer sessions. This makes the stall harder to diagnose,
since there is no way to confirm the subagent is alive. TaskStop by agent name
does work, and reported all of them as live in_process_teammate tasks, so they
were running the whole time.

  • Restarting the CLI does not clear the condition.
  • Observed three times in one day across different workloads.

Workaround

Instruct every subagent to write its report to a file as its final action, and read
the files from the main loop instead of relying on the return value. Filesystem
side effects survive the broken hop; return values do not.

View original on GitHub ↗