Agent tool: run_in_background: false is not honoured — subagents complete but never deliver their output as the tool result

Summary

When the Agent tool is called with run_in_background: false, the call does not block and the agent's final report is not returned as the tool result. The agent runs, completes its work correctly, and then goes idle-but-resident. Its output arrives later as a teammate message — or, frequently, never arrives as text at all.

The work itself is fine every time. Only delivery fails. That distinction is what makes this hard to notice: nothing errors, and the agent believes it has reported.

Environment

• Claude Code 2.1.233, Windows 11
• Agent tool, multiple subagent types, both haiku and inherited models
• Observed repeatedly over ~5 days across unrelated task types

Reproduction

1. Call the Agent tool with run_in_background: false and a trivial task (e.g. a single git log call).
2. Observe the tool result:

> Spawned successfully. … The agent is now running and will receive instructions via mailbox.

This is byte-identical to what a background spawn returns. The call does not block.

1. Observe that the agent's output arrives later as a teammate message, followed by an idleReason: "available" notification — not as a task completion, and not as the tool result.

Expected: with run_in_background: false, the call blocks and the agent's final report is the tool result.

Three findings, descending confidence

1. run_in_background: false is not honoured

Established with a dedicated control probe whose task took a few seconds. The call returned immediately with the background-spawn message. This is the finding that matters most, because it removes the obvious workaround — "just run it in the foreground" is unavailable.

2. Agents go idle-but-resident rather than terminating, and believe they already reported

Agents emit {"type":"idle_notification", "idleReason":"available"}. Several stated explicitly that they had already delivered:

• "Done — I sent the full table already (msg before this one), no error. Resending here as final output in case it didn't land."
• "Already sent full findings in my previous message (msg_id …)."
• "Research is complete (not partial) — re-sending in full, in case the earlier message didn't land."

In one batch, 3 of 11 agents never returned content at all — only idle notifications. Their work was abandoned and redone inline.

3. Delivery appears to land on turn boundaries, not on task completion

The control probe is the cleanest evidence. Its work took seconds, but it surfaced only after the main thread had spent a full turn on unrelated output — and it surfaced without being pinged.

This reframes the pattern: the agents are not hanging and the results are not lost. They are waiting on the main thread to take another turn. A SendMessage ping appears to help, but only because the ping is itself a turn, not because it repairs anything.

Frequency

Five separate occurrences over 2026-08-13 → 2026-08-17, across unrelated pipelines. The starkest: a batch of 13 subagents where all 13 completed and zero delivered any text. A single round trip asking each to write its result to disk recovered 13 of 13 — confirming the work existed and only transport had failed.

Impact

Two costs, and the second is worse than the first.

Latency. Collection lags 10–20 minutes per dispatch round. On a pipeline with two dispatch rounds inside a 2.5-hour window, that is most of the window.

Silent quality loss. When a dispatched agent does not return, the natural response is to redo its work inline on the main thread. In two separate measured cases the delegated returns arrived after the inline fallback had run and were materially better — on one occasion better on 4 of 4 items. So the failure mode is not "slower"; it is "quietly worse output, with no signal that anything was lost."

Workaround

Instruct every subagent, in its original prompt, to write its result to an exact absolute path with the Write tool first, and return the same content as its final text. Then poll for the file rather than for a reply.

This works reliably — a file landing is observable without any delivery guarantee. Measured on a 4-agent batch: all 4 files landed, all 4 agents subsequently went idle having delivered zero text, and the run cost nothing.

It is a workaround, not a fix. It requires every dispatch site to know about the defect, it does not help with agents whose prompts you do not control, and polling for files introduces a stale-file hazard that the blocking contract would not have.