Background subagent's final report arrives empty (0 bytes) when 5+ background agents run concurrently

Status Fixed / completed

Maintainer reply None cached

Activity 4 comments · opened Jul 14, 2026 · closed Jul 14, 2026

Environment

Claude Code desktop app (Windows), auto-updated, as of 2026-07-14
OS: Windows 11 Pro (10.0.26200)
Session model: claude-fable-5 (subagents on opus/sonnet)

Bug description

When several background agents (spawned via the Agent tool with run_in_background) run concurrently — observed with 6–7 at once — the agents complete their work successfully (all files they were asked to write appear on disk, correct and complete), but the final report/transcript returned to the orchestrating session is EMPTY. The task output file is 0 bytes.

With 1–2 concurrent background agents the reports arrive normally, so this looks load-related (a race or dropped write in transcript/report persistence under concurrent completion), not an agent failure.

Steps to reproduce

In one session, spawn 6–7 background agents at roughly the same time, each with a long task (several minutes, producing large text output and writing files).
Wait for completion notifications.
Check the returned reports / task output.

Expected

Each background agent's final message is delivered to the parent session.

Actual

Work is done (files on disk are fine, e.g. a 36 KB generated text was written perfectly), but the final report arrives empty / output file is 0 bytes. Reproduced in two separate sessions on different tasks.

Impact / workaround

No work is actually lost if agents are instructed to write results to files. Workarounds we use: (a) always have subagents persist results to a file instead of relying on the final message, (b) verify by reading the target files, (c) cap concurrent background agents at 3–4. Still, silent empty reports are confusing — the orchestrator can misread a successful run as a failure.

View original on GitHub ↗

4 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

kcarriedo · 3 months ago

The workaround you landed on (have subagents persist results to files and verify by reading them directly) is the right call for now, and it's a useful pattern more broadly - writing to a named output file in the worktree before the subagent exits means the orchestrator has something to read even if the transcript channel drops the ball.

A few things that might help while this is being tracked:

Set a post-task assertion in the orchestrator prompt: after each background agent reports, immediately check for the expected output file existence before treating the task as done. If the file is missing, you know the agent silently failed vs. just having an empty report.
Cap concurrent agents at 3-4 as you mentioned, but also stagger launches with a short delay (a few seconds) between each. A pure race condition at the persistence layer often breaks only when multiple completions arrive simultaneously.
Log the agent task ID alongside every file write inside each subagent prompt, so you can correlate which agent produced which output file if the transcript is empty.

The 5+ concurrency threshold you observed is a useful data point. If you can reliably reproduce at exactly 5 concurrent agents (not 4), that would narrow whether it's a per-process descriptor limit or something in the report aggregation path.

23ssuss · 3 months ago

Closing as duplicate of #74113 (final report undelivered while work is complete) / #20754 (drops on simultaneous completion). Added our concurrency data point (empty 0-byte report at 5+ concurrent background agents, files on disk intact) to #74113.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.