subagent: sessionID continuation forks running lanes — zero-context sidecar spawns, no parentage in payload #56249

Activity

1. opencode-agent commented on Oct 16, 2026

   

   opencode-agentBot

   on Oct 16, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report! Before we try to reproduce this, we need a few things.

   In 2.0.30, when the subagent tool gets a sessionID, it either fails (Subagent session not found / not a child of the current session) or prompts that same session (it starts the session if idle, or steers it if running) and returns the same ID. We couldn't find a code path that creates a new session when a valid sessionID is passed. A new session that gets only the prompt is what happens when the call has no sessionID, so we suspect those calls didn't actually include one, or a plugin changed them.

   Could you please share:

   1. The exact tool call for one of the calls that forked: the raw subagent input (the agent, prompt, sessionID and background fields) and the output it returned. A screenshot of the expanded tool call or the JSON of that message part is fine. We need to see that sessionID was really sent.
   2. Whether it still happens with your plugins disabled (lanetools, autocompact, elementbridge, opencode-memory). lanetools in particular sounds like it might touch subagent calls.
   3. The provider and model of the session that made the calls.
   4. A short description in your own words of what you did, what you expected and what you saw. The current text uses a lot of custom terms ("lanes", "sidecar", "steer") and is hard to map onto OpenCode's behaviour.

   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, ordered from most to least likely to be relevant:

   • Subagent tool: sessionID not clearly marked as optional in serialized JSON schema #55504: some models mishandle the optional sessionID field on the subagent tool
   • fix(core): persist subagent session id before child starts #53188: PR that stores the subagent's session ID before the child starts
   • subagent: parent gets cancelled when an interrupt with resume=true continues a background subagent #54658: problems continuing a background subagent after an interrupt with resume=true
   • subagent: background subagent's resumed turn completes but the parent session never receives the completion notification #50751: the parent isn't notified when a resumed background subagent's turn completes
   • v2: subagent: no cancellation support for background subagents #36423: background subagents can't be cancelled
2. opencode-agent

   added

   triaging

   on Oct 16, 2026
3. EventideMiles commented on Oct 16, 2026

   

   EventideMiles

   on Oct 16, 2026

   Author

   More actions

   Thanks for the sharp triage — we took it to the bench with controlled probes. Short version: you're right, and we can no longer reproduce the fork when the field is verifiably present. Consider this a correction with data.

   What we ran (synthetic tasks only)

   Three background Worker lanes running tight tool loops (sleep 3-4 × 15-18 iterations, one shell call per iteration — targets alternate between tool-held and between-calls phases). From the orchestrator seat, we re-invoked subagent with each lane's sessionID at three different phases: early loop, mid loop, deep loop.

   Result — 3/3 in-place, zero forks

   • The tool echoed the same sessionID every time; no new session was returned.
   • Server session-list spawn-checks across each probe window: zero new sessions beyond the probe lanes themselves.
   • Exporting one target's transcript shows the steer delivered as a second user message mid-run (message 6 of 20), and the loop continued to completion with its iteration count unrestarted — genuine in-place interleave, matching the tool-held behavior we'd measured earlier with a single long sleep 150.

   What this means for the original report

   The "state-dependent fork" framing was likely wrong. We could not reproduce a fork from a caller that verifiably composed the field, across phases. The original four "fork" calls came from a different orchestrator session on the same build and plugin set — per your #55504 link, the plausible mechanism is those calls being emitted without the sessionID (model-side optional-field drop), which the platform then correctly treated as fresh spawns. The downstream impact data stands as reported: a spawn-that-should-have-been-a-steer burns enormous context reconstructing what it was never handed (212k input tokens in our incident) and can act on the wrong checkout. Our caller-side doctrine now treats "returned a different ID than the one I sent" as the live failure signal regardless of mechanism.

   Your specific asks

   1. Exact tool call JSON: our session exports omit tool-call inputs entirely (see secondary note), so we're pulling the expanded call from the caller session's UI and will attach one example with the prompt text elided.
   2. Plugins disabled: all four are local and none transform the subagent tool — lanetools registers its own namespaced tools only; the others hook compaction, a chat bridge, and memory. Happy to run the literal disabled-config rerun at our next scheduled restart if the source-level attestation isn't sufficient.
   3. Provider/model of the calling session: zai-coding-plan / glm-5.3 (Worker subagents on glm-5.3-flash).
   4. Plain-language restatement: an orchestrator session dispatches background child worker sessions ("lanes"); to deliver a mid-task instruction it re-invokes subagent passing the child's session ID ("steer"). Measured behavior when the field is present: routed in-place, message delivered into the child's transcript, same ID returned. The failure we originally reported — a fresh unrelated session receiving only the prompt (a "sidecar") — now looks like the session ID field being absent from those calls, not a routing fork.

   Secondary finding (possibly its own ticket)

   /api/experimental/session/{id}/export drops tool-call inputs — assistant messages render with no text, so only user prompts survive. That makes post-hoc verification of "was the parameter actually sent" impossible from server data alone, which is precisely the question triage needs answered in #55504-class cases. Including tool-call inputs in exports would make optional-field drops self-diagnosable.

   We'll follow up with the redacted call example. Given the above, retagging/redirecting this toward #55504 as a duplicate-with-impact-data is reasonable if that fits your triage.
4. opencode-agent commented on Oct 16, 2026

   

   opencode-agentBot

   on Oct 16, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for testing this so carefully and writing up the results. With 3/3 in-place steers and no new sessions when sessionID was really sent, this matches the code. In 2.0.30, a subagent call with a sessionID either reaches that session (starting it if idle, steering it if running) or fails with an error. A new session is only created when the field is missing. So your four original "forks" were most likely GLM-5.3 leaving sessionID out of those calls.

   That makes this the same root cause as #55504: models getting the optional sessionID field on the subagent tool wrong. That report covers models filling it with made-up values, and yours is the other direction, dropping it. Your figures on the cost (212k input tokens and writes to the wrong checkout) are useful there, so feel free to add them as a comment on #55504. As you suggested, the bot will close this issue as a duplicate of #55504 in about a day unless you reply explaining how it's different. No need to rerun with plugins disabled.

   Your other two points are worth their own issues so they don't get lost here:

   • Session export missing tool-call inputs (/api/experimental/session/{id}/export). A separate bug report with an example would be the best way to track it.
   • Marking spawned subagent sessions with their parent session, worktree and branch, and/or warning when a call that looks like a continuation creates a new session. This would be a feature request.

   If you do attach the redacted tool call, posting it on #55504 or in a new issue is more useful than posting it here.
5. opencode-agent

   added

   pending close

   on Oct 16, 2026
6. opencode-agent commented on Oct 17, 2026

   

   opencode-agentBot

   on Oct 17, 2026 – with OpenCode Agent

   Contributor

   More actions

   Closing this as a duplicate of #55504, as discussed above. Your tests showed that a subagent call that really includes sessionID steers that session in place. The new sessions came from calls where the model (GLM-5.3) left the field out, which is the same model-side problem with the optional sessionID field that #55504 tracks.

   Thanks again for the careful follow-up. Your figures on the impact (212k input tokens, writes to the wrong checkout) and the redacted tool call would be useful as a comment on #55504. The export gap (tool-call inputs missing from /api/experimental/session/{id}/export) and marking spawned sessions with their parent are still worth separate issues. If you think this is a different problem after all, reply here and we'll take another look.
7. opencode-agent

   closed this as duplicateon Oct 17, 2026