Named Agent-tool subagent dispatch intermittently goes idle without ever returning its result

Summary

When dispatching a background subagent via the Agent tool with a name parameter (making it addressable later via SendMessage), the subagent occasionally starts, appears to run, then goes idle without ever delivering its final result back to the calling session. idle_notification events arrive (idleReason: "available") but carry no content. Follow-up SendMessage calls asking the named agent directly for its result sometimes recover the content and sometimes do not.

Frequency

Observed independently at least 4 times over roughly 10 days in the same project, across different unrelated tasks and different subagent types:

1. A research/audit subagent went idle twice, was re-pinged once, went idle again with no content ever recovered in that session.
2. Two independent review subagents (different names/types) both went idle after apparently completing — but in this case their full results were successfully retrieved by the parent session. So idle_notification alone isn't sufficient signal to distinguish a real completion from a stall.
3. A build subagent "went dead" mid-task; the parent session gave up waiting and did the work directly instead.
4. (Most recently investigated in detail) A code-review subagent (subagent_type: deep-reasoner, model: opus) was dispatched with a clear, self-contained review prompt. It reported spawning successfully, then sent three idle_notification pings over about 5 minutes with idleReason: "available" and no content, despite two direct SendMessage follow-ups explicitly asking for its verdict. ListAgents did not list this agent at all when checked shortly after. The user independently confirmed no such process was visibly running on their end.

What I ruled out

For case 4, I checked whether a local PreToolUse permission hook could be blocking the subagent's tool calls and causing it to silently stall waiting on an approval that would never arrive. I found no evidence of this: the task was read-only by design (Read + running local test commands), none of which match the hook's high-risk patterns, and there are no matching "block" decisions logged in the relevant time window. So this doesn't look like a permission-hook interaction on my end — it looks like something in the subagent dispatch/completion-notification path itself.

Environment

• Claude Code CLI, macOS (Darwin 25.6.0)
• Involves the Agent tool (named, non-fork dispatch) plus cross-session addressing via SendMessage / ListAgents
• Case 4 used model: opus; other cases used different models/subagent types, so this doesn't appear to be tied to one specific model or agent type

Why this matters

Named background subagents are the recommended pattern for independent review/verification work (e.g. "a builder should not accept its own work"). When the dispatch silently stalls instead of erroring, there's no clean signal to fall back on — you just wait on idle pings that never resolve, with no way to tell from the outside whether the agent is genuinely working, finished-but-lost, or stuck.

Request

This is intermittent and I don't have a reliable repro yet, but the pattern — idle_notification with no content, sometimes recoverable via a follow-up SendMessage and sometimes not, and the agent sometimes not appearing in ListAgents at all — suggests a race or drop in how a named/addressable subagent's completion gets surfaced back to the dispatching session. Flagging in case this is already known, or the pattern above is useful for reproducing it internally.