subagent: background subagent's resumed turn completes but the parent session never receives the completion notification #50751

Activity

1. github-actions

   assigned

   nexxeln

   on Sep 22, 2026
2. github-actions commented on Sep 22, 2026

   

   github-actionsBot

   on Sep 22, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • fix(session): notify parent when subagent sessions finish #35066: "fix(session): notify parent when subagent sessions finish" — covers the same root behavior (background subagent completion not delivered to parent). Your issue narrows the repro to sessions resumed via prompt-session after the first background turn, which may help pinpoint whether this is the same underlying fix or a distinct regression.
   • V2: preserve subagent parent completion across restart #36349: "V2: preserve subagent parent completion across restart" — covers the case where a server restart severs the process-local completion watcher; you mention a server restart occurred earlier in the same parent session, which may be relevant.
3. opencode-agent commented on Sep 24, 2026

   

   opencode-agentBot

   on Sep 24, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. The follow-up in this repro uses opencode-froggy's prompt-session tool, rather than V2's built-in subagent tool. In V2, the built-in tool registers a background job and completion notification when invoked with background: true, including when continuing an existing child with sessionID. Calling the session prompt API directly admits/runs the child's next turn, but does not register a new parent completion notification.

   At the Froggy revision preceding this change, prompt-session simply called session.prompt and returned. That explains why the initial native subagent turn notified the parent while later plugin-prompted turns completed without notifying it. This isn't evidence of a V2 native subagent notification regression, and the child doesn't need to be running background processes to produce it. The linked Froggy change adds a plugin-side completion watcher.

   Could you retry with the Froggy update containing that change, or continue the child with the native subagent tool (sessionID plus background: true)? If the native continuation misses a completion notification, a repro using that path would be useful to investigate on the V2 side.
4. Codestz commented on Sep 25, 2026

   

   Codestz

   on Sep 25, 2026

   More actions

   Same gap in the foreground case, measured on 1.18.32 and 2.0.15. A subagent finishes and returns its result to the parent. The user then messages the child session directly (v1 session.promptAsync, v2 session.prompt): the child wakes, does the work, and answers. The parent never hears about it: no notification, no new turn, and nothing when it's next prompted. Messages sent while the child is still running are fine, because they land in the answer the parent receives.

   For opencode-cockpit (a subagents viewer) I work around it by adding the exchange to the parent without starting a turn (v1 noReply: true, v2 session.synthetic with resume: false). A built-in <subagent> notification for any completed child turn would cover both this and the resumed-background case above.
5. 0x4nur4g commented on Sep 25, 2026

   

   0x4nur4g

   on Sep 25, 2026

   More actions

   Corroborating this at scale — same mechanism, 44 instances, with a controlled reproduction.

   Loss signature. Scanning the local session store for "child terminal >60 s after its last delivered <subagent> notification" finds 44 instances: 2 on 2026-09-10 (beta-19425), 1 on 09-23, 23 on 09-24, 18 on 09-25. Every loss sits on a child that had been resumed or re-woken; fresh-spawn first completions were delivered correctly every time, matching the report.

   One fully-traced instance. Parent resumed a background child at 17:08; the drain's first idle fired the notification at 17:42:58. A second call from the parent at 17:41:10 (admitted while the child was busy) promoted as a successor turn after that idle. Final idle: 17:45:25 — no notification, ever. Parent had gone idle at 17:44:56; its inbox was empty and pending count 0 (never posted, not queued).

   Controls. No service restart in the window (single run id across the log). Error drains still notify — a child whose drain failed on 2026-09-25 delivered two notifications. Empty inbox rules out queue-promotion loss.

   Controlled reproduction. Spawned a test orchestrator-type agent as a subagent with one background child. Its first idle landed 2 s before the child's completion notification; the parent received the interim text as final. The child's real verdict turn (26 s later) was invisible by construction, recovered only via GET /api/session/{id}/message readback.

   Mechanism (hypothesis consistent with all observations): the background job's watcher fires at the child's first idle after the parent's call and is consumed. Any later drain — steer/queue-promoted successor, or a wake from a <shell state="completed"> synthetic — is owned by no job, so its terminal event injects nothing. The delivered notification is additionally prematurely terminal: the parent is told completed at an intermediate idle while the real final state lands later, unseen.

   Exposure note. Local loss rate went ~2 per 2 weeks → 41 in 2 days when the fleet moved all lead→worker dispatch to background on 09-24. Can share a sanitized per-instance table — timestamps, opaque session IDs, and outcome fields only; no paths, project names, or transcripts — plus the SQL signature behind the scan, if useful for triage.
6. johnmwhitman commented on Sep 27, 2026

   

   johnmwhitman

   on Sep 27, 2026

   More actions

   The 44-instance trace suggests the invariant needs to be per continuation turn, not per child session or first idle. Concretely, each parent-to-child continuation could create a durable delivery obligation keyed by (parentSessionID, childSessionID, turnID/finalMessageID). Mark it delivered only when that exact terminal assistant message is injected into the parent; on parent resume, replay any undelivered obligation idempotently. That also avoids treating an intermediate idle as terminal. Polling session_message can remain a recovery path rather than the primary correctness mechanism.

   Disclosure: I maintain MeshFleet. We use per-recipient receipts keyed by message, recipient, and action to make duplicate delivery idempotent; that pattern is why the single-use watcher behavior here stood out.
7. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed report!

   One thing we need to pin down first: OpenCode v2 doesn't ship a prompt-session tool. I couldn't find it in 2.0.14, on the current dev branch, or in the published opencode-froggy package. The <subagent state="completed"> notification is only sent for turns started through the built-in subagent tool. To continue an existing child, you call that same tool with the child's sessionID (and background: true). If prompt-session prompts the child session directly (e.g. through session.prompt), no subagent job is registered for that turn, so the parent would never get a notification.

   Could you tell us:

   1. Where the prompt-session tool comes from (a custom tool, a local build of a plugin, an MCP server…) and what API it calls to prompt the child?
   2. Does the notification still go missing if you send the follow-up with the built-in subagent tool, passing the child's sessionID and background: true? If you can, please try on a current 2.0.x release with plugins disabled.

   You can reply here with the details or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know you're done.

   Related issues I found, ordered by likelihood. None looks like an exact match:

   • subagent: parent gets cancelled when an interrupt with resume=true continues a background subagent #54658: a resumed background subagent's reply never reaches the parent, but the trigger is an interrupt with resume=true
   • subagent: gateway stream cut ends session "completed" — no artifact, no notification, sessionID continuation hangs #59565: a child ends "completed" with no notification to the parent after a gateway stream cut
   • V2: preserve subagent parent completion across restart #36349 / fix(core): background subagents resume after a server restart instead of showing cancelled #58261: subagent parent completion across a server restart (you mentioned a restart earlier in the session)
   • [BUG] V2: subagent with pending background work (shell commands or subagents, background: true) marked completed early — results never collected #48826: a subagent with pending background work is marked completed early and its results are never collected
8. opencodejr

   added

   triaging

   on Oct 28, 2026
9. opencodejr

   closed this as not plannedon Oct 31, 2026
10. opencodejr commented on Oct 31, 2026

    

    opencodejrBot

    on Oct 31, 2026

    Contributor

    More actions

    Closing this for now, since we haven't heard back about the details we asked for. We still need to know where the prompt-session tool comes from, since it isn't part of OpenCode v2. We'd also like to know whether the completion notification still goes missing when you continue the child with the built-in subagent tool, passing its sessionID and background: true. Without that, we can't tell whether this is a bug in OpenCode or expected behaviour for a turn the subagent tool didn't start.

    If you can share those details, or it happens again with the built-in subagent tool on a current 2.0.x release, please comment here or open a new issue and we'll look again. #54658 tracks a related case: a resumed background subagent whose reply never reaches the parent. Thanks for the thorough report!