Summary

A subagent that calls sessions_yield() after spawning child subagents can still be announced to its parent/grandparent as "completed successfully", even though it is not actually finished and still has pending descendants.

In the observed case, the parent/orchestrator subagent yielded with a message like:

{"status":"yielded","message":"Spawned child subagents ... Waiting for both completion results ..."}

and the main session immediately received an internal event saying a completed subagent task was ready for user delivery. But subagents list still showed that same orchestrator as:

active (waiting on 2 children)

So the completion announcement was premature/confusing/wrong.

Reproduction

1. Main session spawns an orchestrator subagent.
2. Orchestrator spawns 2 child subagents.
3. Orchestrator calls sessions_yield("waiting for both children").
4. Before either child finishes, the main session receives an internal task-completion event for the orchestrator:
   • status: completed successfully
   • result payload is the sessions_yield response ({"status":"yielded", ...})
   • instruction says: A completed subagent task is ready for user delivery
5. But the orchestrator is still listed as active (waiting on 2 children) and the children are still running.

Expected behavior

If a subagent yields while it still has pending descendants:

• no completion announcement should be sent to the requester yet
• the run should stay in a waiting/deferred state
• the parent/orchestrator should be resumed only after descendants settle
• only after the orchestrator processes child results and ends naturally should a completion announcement be sent upward

Actual behavior

The requester receives a completion announcement immediately after sessions_yield, even though the yielding subagent still has pending descendants.

Why this looks like a bug

The current bundled logic appears to intend the opposite behavior:

• sessions_yield itself only aborts the current turn and persists hidden yield context; it does not itself say "announce completion":
  • dist/auth-profiles-DDVivXkv.js:109161-109166
• the announce flow is supposed to bail out when descendants are still pending:
  • dist/auth-profiles-DDVivXkv.js:91412-91414
• descendants are considered pending until they have both endedAt and cleanupCompletedAt:
  • dist/auth-profiles-DDVivXkv.js:91993-91996
• cleanup is supposed to defer and set wakeOnDescendantSettle instead of announcing:
  • dist/auth-profiles-DDVivXkv.js:92618-92630
• once descendants settle, the parent is supposed to be resumed/woken:
  • dist/auth-profiles-DDVivXkv.js:91321-91344
  • dist/auth-profiles-DDVivXkv.js:92698-92704

So the observed behavior contradicts the intended guard.

Possible root cause

The npm package currently ships multiple bundled auth-profiles-* roots, each with its own subagent-registry runtime import path, e.g.:

• dist/auth-profiles-DDVivXkv.js:90720-90722 → subagent-registry-runtime-C9SAVDDK.js
• dist/auth-profiles-DRjqKE3G.js:87970-87972 → subagent-registry-runtime-C3sroivL.js

This may be causing split-brain/stale in-memory subagent registry state across different entrypoint bundles, so one path can see pendingDescendants > 0 while another announces as if the run is complete.

That part is a hypothesis, but it matches the symptom: the main session saw a completion event while subagents list still showed the same run as active (waiting on 2 children).

Environment / notes

• Investigated against the installed npm bundle (2026.3.13 package contents).
• This was observed in a real subagent orchestration flow, not just a synthetic example.
• The installed npm package did not include the repo-side test harness (scripts/test-parallel.mjs) or local oxlint/oxfmt binaries, so I could not run the usual package verification commands directly in that install tree.