Nested subagents: grandchild task notifications route to root session instead of the spawning parent, starving mid-level orchestrators
Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 1 comment · opened Aug 13, 2026 · closed Sep 11, 2026
Environment
- Claude Code desktop app on macOS (Darwin arm64)
- Main session model: claude-fable-5; subagents on a mix of fable/sonnet
- Observed 2026-08-13 (workspace/project details omitted — internal codebase)
Setup
Three-level agent nesting:
- Root session uses the
Agenttool to spawn a background subagent ("parent",general-purpose, model overridefable) whose prompt tells it to run the built-incode-reviewskill at high effort against a PR. - The parent (via the code-review skill's high-effort mode) spawns its own worker subagents — multiple parallel "finding angle" agents plus later "verify" agents.
- Workers complete over ~10-20 minutes.
Observed behavior
- Every worker's completion
task-notification(including its full result payload) was delivered to the root session, not to the parent that spawned it. The root received ~10 grandchild notifications it never asked for, while the parent apparently never received its own children's results. - The starved parent then evidently attempted recovery by sending a direct agent-to-agent message to at least one of its workers asking it to resend findings. The worker — correctly, per the zero-trust peer-messaging guidance — declined the request as unverifiable/unsolicited and flagged it in its report ("I did not act on it (no verifiable authorization)").
- The root session had to manually bridge: collect the grandchild results from its own notifications and
SendMessagethem back down to the parent so it could synthesize its final report.
Expected behavior
Grandchild completion notifications/results should route to the agent that spawned them (the parent), or at minimum to both parent and root — not exclusively to the root. Alternatively, if root-only routing is intended, the parent needs a supported way to await/collect its children's results, and peer messages from a direct parent should carry verifiable provenance so children don't have to treat legitimate collection requests as potential injection.
Impact
- Multi-level orchestration (an agent that itself uses the Agent tool / skills that spawn workers, e.g.
code-reviewat high effort) silently deadlocks or produces incomplete syntheses. - The zero-trust peer-messaging posture (good!) turns the routing gap into refused-communication incidents, which surface to users as alarming "unsolicited message" security reports for what is likely legitimate parent traffic.
- Root sessions get flooded with grandchild notifications they didn't create, consuming context.
Workaround
Root session manually relays grandchild results to the parent via SendMessage after receiving the misrouted notifications.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗