[BUG] Background agents frequently go idle without delivering their final SendMessage report (re-ping recovers it)

Data point from #77514 (closing it as a duplicate of this): on Windows 11 (desktop app), with 6-7 background agents running concurrently, the final report arrives EMPTY (task output file 0 bytes) while every file the agents wrote on disk is complete and correct (e.g. a 36 KB generated text intact). With 1-2 concurrent agents reports deliver normally - the threshold we observed is around 5+. This looks like the same simultaneous-completion race as #20754. Workarounds that hold up in daily use: (a) subagents always persist results to a named output file, (b) orchestrator checks file existence after each completion instead of trusting the report, (c) cap concurrency at 3-4 and stagger launches by a few seconds.

Data point from a live test today (Claude Code CLI, Windows, agent-teams experimental mode via CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, not the desktop app): reproduced this with only 2 concurrent teammates, which is below the ~5+ threshold noted in the comment above — worth revisiting that as the trigger condition.

Setup: two named teammates (teamtest-alpha, teamtest-beta) each spawned via the Agent tool under agent-teams mode, instructed to message each other directly and both report status back to the lead.

Symptom variant: not a bare empty report, but a stale one. teamtest-beta sent the lead a status report saying "I did NOT receive any message from teamtest-alpha; file unchanged" — accurate at the moment it was composed. But that report was only delivered to the lead after beta had already received alpha's message in a later turn and correctly appended the shared file. So the lead received a truthful-when-written but false-by-delivery-time report, alongside a real completion notification, with no indication the underlying state had moved on since the report was drafted.

Confirmed by reading the actual file on disk directly rather than trusting the delivered report — matches the workaround already noted here (verify ground truth, don't trust the narrated report). Filesystem side effects (the file append) were always correct and immediate; only the report describing them was delayed/stale.

Corroborating from heavy multi-agent use on Linux, Claude Code 2.1.2xx (currently 2.1.212): same shape — named background Agent spawns given an explicit "report your result via SendMessage to main before finishing" contract complete their work, then the parent receives only {"type":"idle_notification","idleReason":"available"}.

One harsher variant worth noting for anyone triaging: in some instances the re-ping does NOT recover the report — the nudge itself yields another bare idle_notification, and the deliverable was recoverable only because the agent had also written it to a file on disk. That variant matches defect 2 of #76500 (report lost entirely; teammate transcript shows the SendMessage tool call succeeding).

Our standing mitigation: require agents to persist deliverables to files and treat messages as notification-only, then check the filesystem on any bare idle notification before assuming "nothing to deliver."

Adding a concrete repro + a related root cause I hit under CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, v2.1.220 macOS:

Feedback ID: 3bc81afb-e9e6-45c1-a04b-735b4a7872b5

Spawned a teammate (advocate-009-b, general-purpose) for a review task. It produced two full reports as plain assistant text (5,761 and 5,116 chars, visible in its own session .jsonl) and made zero SendMessage calls. Lead received only:

{"type":"idle_notification","from":"advocate-009-b","idleReason":"available"}

No content, no way to know work was even done short of grepping the raw transcript file directly.

Nothing in the Agent/spawn flow forces or even nudges the teammate to call SendMessage before stopping — it behaves exactly like a normal subagent (which returns its final text as the tool result), so models default to printing the report and stopping, which for teammates is silent data loss.

Related, compounding issue: the team inspector (~/.claude/teams/session-*/config.json) only stores the static spawn prompt, never the teammate's live output, and inboxes/<agent>.json drains to [] once delivered — so there's currently no way to inspect a teammate's actual progress/output short of manually finding its separate session .jsonl (see #75190, which would fix the transcript-mapping half of this).

Another instance today (macOS, Claude Code, Opus 5 session), plus a possible root-cause link.

What happened: spawned a general-purpose research agent via the Agent tool, backgrounded, with a name parameter. It did the work but delivered only a bare idle_notification (idleReason: "available") with no report content. A single SendMessage re-ping is the recovery path, as described here.

The link: this may be #71723 rather than an independent delivery drop. My spawn returned the teammate-path result verbatim:

Spawned successfully.
agent_id: <name>@session-<id>
name: <name>
The agent is now running and will receive instructions via mailbox.

That is exactly the signature #71723 describes for the name parameter silently switching the spawn from the background-agent path to the teammate protocol — after which results arrive as inbox idle_notifications instead of a task-notification, which is precisely the symptom reported in this issue.

Why that matters for triage: if the two are the same bug, fixing #71723 may close this one. The cheap discriminator is whether reporters here were passing name to the Agent tool. Reports of a dropped final report from an agent spawned without name would confirm the two are genuinely distinct; if every instance turns out to involve name, this is a duplicate with a known cause.

Anecdotally the workaround is consistent with that reading: omitting name and addressing the agent by its returned id has not reproduced the dropped report for me, though I have not run enough trials to call that conclusive.

I am seriously fixing so many problems with a pty-proxy and an attempt to work with their undocumented and volatile... innovative, fast-paced, forward-oriented style. I would stay on old versions or stable, if they were workable.

I think it might be approaching a point where I'd better get Claude to write a custom TUI from scratch.

I want to run teams, please let me!

Agents don't really know they need to SendMessage, and in team mode their last message isn't forwarded. And, cherry on top. claude-code-guide does not even have access to SendMessage, and intercepting the teammate spawn command and specifying --tools, --allowedTools and other stuff just doesn't get honoured.

I ended up finding a system prompt leak repo, to copy over the claude-code-guide agent but add SendMessage to it.

5/10 having not a terrible experience. But at best neutral. Better than Gemini CLI, killed by Google, and honestly, that was a good call.

Lets keep Claude Code TUI alive. I like it, sometimes.