v2: subagent: no cancellation support for background subagents #36423
Description
Summary
In opencode v2, the subagent tool returns a session ID (ses_...) both at launch and in the completion notification, and sessions can be resumed via the sessionID parameter. However, there is still no way to cancel a running background subagent.
What works now (v2)
- Background subagents return a session ID at launch:
ses_0721f344effe5ZAKw2R1Y9AVF1 - The ID also appears in the completion notification.
- Sessions are resumable via the
sessionIDparameter.
What is still missing
- No cancellation: There is no
cancel/kill/abort/stopparameter on thesubagenttool and no dedicated cancel tool to stop a running background subagent.
Desired behavior
- A way to cancel a running background subagent using its session ID
Activity
[-]subagent: foreground agents don't expose session ID, preventing resume[/-][+]v2: subagent: foreground agents don't expose session ID, preventing resume[/+][-]v2: subagent: foreground agents don't expose session ID, preventing resume[/-][+]v2: subagent: no resume or steering capabilities (regression from v1 task tool)[/+]Ploppy3 commentedon Jul 23, 2026
Updated the issue to reflect the latest v2 changes: background subagents now do return a session ID at launch (
ses_...), which is progress. However, the core gaps remain — there's still no mechanism to resume a completed subagent or steer a running one, both of which were standard in v1'stasktool. Keeping this open so it doesn't go stale while these capabilities are being worked on.Ploppy3 commentedon Aug 6, 2026
damjtoh commentedon Aug 28, 2026
this makes any orchestration workflow impossible, I've returned to v1 sadly 🥲
[-]v2: subagent: no resume or steering capabilities (regression from v1 task tool)[/-][+]v2: subagent: no cancellation support for background subagents[/+]Ploppy3 commentedon Aug 29, 2026
Updated this issue: resume via
sessionIDnow works in v2, so the report is narrowed to the missing cancellation support (no way to stop a running background subagent by its session ID).imarshallwidjaja commentedon Sep 13, 2026
Also hitting this. My workflow launches background workers and needs an operator-visible way to cancel one without cancelling the parent session.
session.interrupton the client works for a known child ID, but there's no tool-level surface for the model, and no way to list what's running. PRs #32425 and #34947 look like the right shape; the /tasks view from #41914 would complete it.mattew113 commentedon Sep 30, 2026
thank god i did the v2 upgrade in a cloned vm and i'm destroying it and sticking to v1.
i have several background services that run on opencode and i dont want background subagents at all on them. on cheap models, even adding a hard rule to not deploy in background, some end up deploying, and opencode, the harness that allows you to tailor it for you, does not have a basic parameter to block this....
i don't see why they're not adding deterministic configuration to such things that could be easily configurable....
for sure async background subagents have its role on some workflows, but forcing it down to everyone is not a good way. even my company tickets are answered by opencode agents. i really hope opencode team shifts this and allow some per-agent or global configuration to activate/deactivate this.
letting the model decides what goes in background is just insane. opencode team is awesome , but v2 with that is definitely not for me.
Ploppy3 commentedon Oct 5, 2026
Still valid on v2.0.23 (v2 tip
fad352c): thesubagenttool still has no cancel/abort parameter and there is no dedicated cancel tool. The only cancellation path is interrupting the parent's blocking call (sessions.interrupt+jobs.cancel), which is not model-callable.joshbla commentedon Oct 11, 2026
From #32425: This needs to be added. Whether it's this PR or another. We can't just let subagents go rogue or be called accidentally without a mechanism for canceling them.
RateteDev commentedon Oct 15, 2026
Same need on 2.0.26 (self-hosted). I run the model as an orchestrator that fans out background subagents, and I often drive it from my phone, so I cannot assume I am at the keyboard to hit Stop.
Two concrete cases:
As a note, even on 2.0.26 the stop control for running subagents only exists in the desktop-width layout; the mobile view does not even show that a subagent is running (#51113). Not being able to rely on the human-side stop makes this gap hurt more.
Both cases would have been contained if the model could cancel the child by its sessionID. Happy to test a V2 port of #32425 on my server.
neowit commentedon Oct 15, 2026
Consider using OpenChamber. It is a convenience wrapper around Opencode v2 with several quality‑of‑life improvements. It offers mobile apps for iOS and Android and allows you to cancel a sub‑agent job easily from a mobile device. See screenshot (iOS app).
xingzihai commentedon Oct 16, 2026
Adding a reproduction on the current release (v2.0.31) — client-side interrupt works per child, but nothing cascades, and there is an extra wake-up wrinkle.
Environment: opencode v2.0.31 (npm global install, Linux x64, TUI + shared background service); no plugins.
Repro
background: true(each returns ases_...ID).interrupted, but both children keep running — still listed asrunninginGET /api/session/activewithtime.updatedadvancing.Observed
POST /api/session/{childID}/interrupt({"interrupted":true}; a no-op{"interrupted":false}if the child is already idle). There is no tool-level or TUI one-shot that stops a session together with its children.<subagent state="cancelled">synthetic notices, auto-resume its turn, and re-dispatch a continuation subagent using the storedsessionID. So stopping a tree becomes a chase loop: stop children → parent wakes and re-dispatches → stop parent again.Desired: make
session.interrupton a session cascade to its background descendants, or provide an explicit "stop tree" / cancel surface in the tool and TUI (as referenced above in #32425 / #34947 / #41914).Related: #28738 reports the same TUI-side symptom (closed stale).
silkiebear commentedon Oct 23, 2026
Also having this problem, subagent hangs for a long time due to unrecoverable errors and there is no way for either me or the main agent to terminate the process.
I would want a way for the main agent to terminate the process, but I can settle for just being able to terminate it myself.
Ploppy3 commentedon Oct 23, 2026
@silkiebear it's possible, but only via the cli
silkiebear commentedon Oct 24, 2026
Preferably the main agent should be able to do it, when instructed to wait for a certain time, or to check if no new files have been created for say 30 minutes.