Repository navigation
[FEATURE]: A running subagent cannot be steered, cancelled, or aborted individually #38966
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Once a subagent is running there is no way to intervene on it specifically. If it goes off-track you either wait for it to finish and discard the result, or interrupt the whole session — which takes down the parent and every sibling with it.
For background dispatches this is the difference between a small correction and losing the work. A subagent that is 80% right and heading the wrong way on the last step has no path back; a runaway one burns tokens until it stops on its own.
The three needs are genuinely different:
- Correct it and let it continue — it is salvageable, and its progress is worth keeping
- Stop it, but keep what it has — wrong direction, partial findings still useful
- Stop it now — runaway, or wedged, and the partial work is not worth waiting for
Suggested behaviour
Per-subagent steer / cancel / abort, from the parent (as tools) and from the human (TUI).
Points worth deciding rather than discovering:
- Delivery has to land somewhere. A child inside a long tool call cannot react until that call returns, so a graceful stop is turn-boundary-soft and needs a hard fallback that does not wait.
- The child should never block on an interrupt — reading a pending one at its own boundary avoids introducing a new wait, and a new wait is a new deadlock.
- Attribution matters in the transcript. "Cancelled by user" and "cancelled by parent" are different events and reading them as the same thing makes debugging an unattended run harder than it needs to be.
- Reasons are untrusted input — they reach the model and the UI, so they need escaping and a length cap.
Version
v1.18.5
Additional context
PR #32425 implements this behind an experimental flag. Supersedes the intent of #21458, #23534, and #28738, all of which were closed by the inactivity bot rather than resolved.
Activity
github-actions commentedon Jul 26, 2026
This issue might be a duplicate of or closely related to existing issues. Please check:
If these don't fully cover the scope here (particularly the three-way steer/cancel/abort distinction and the transcript attribution point), it may be worth linking them rather than closing as duplicate.
[-]A running subagent cannot be steered, cancelled, or aborted individually[/-][+][FEATURE]: A running subagent cannot be steered, cancelled, or aborted individually[/+]iceteaSA commentedon Jul 26, 2026
Checked the duplicate flags.
#32431 (stuck subagents can't be nudged/restarted) is the closest — it asks for nudge/retry within an existing subagent session, which is the "steer" case here. It is a subset rather than the same issue: this also covers cancel-preserving-partial-work and hard abort. Worth noting that a PR implementing the full surface should demonstrate the stuck-session recovery before claiming to close #32431, not assume it follows.
#27511 (suspend/resume) overlaps on the graceful-stop mode but asks for resumable suspension, which is a different guarantee than cancel — a cancel/abort implementation should not claim it.
#36424 is about background shell commands lacking a cancellation handle. Different subject; the overlap is the word "cancel". Not a duplicate.
yurii-sio2 commentedon Aug 2, 2026
Confirm. This is a real problem.
At least earlier we could stop subagent execution, but now we can't.
yurii-sio2 commentedon Aug 26, 2026
Please return back the ability to give instructions to a subagent.
Sometimes a main agent doesn't give instructions with all the details and there is a need to add these to the subagent call.
alecerca commentedon Oct 16, 2026
The root of this is that cancellation is scoped to the parent session: once a child is spawned there's no handle on it, so you either wait or kill everything.
Worth noting: the subagent tool already returns the child's ses_... id at launch. A client can hold that id and expose a per-child stop/steer without touching the siblings — the ids are enough, no new protocol needed. That's the whole reason I ended up building a desktop client for this workflow (a live pane per sub-agent, interrupt just one): https://github.com/alecerca/ORCHESTRATOR — 3-min demo: https://youtu.be/7CgfHGHYCKM. Not a TUI fix, just a data point that per-child control is reachable from what's already there.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up, and for spelling out the steer / stop-and-keep / hard-abort cases.
This was filed against v1.18.5. OpenCode v1 (0.x/1.x) now only gets fixes for critical bugs such as data loss, security problems or crashes with no workaround, so new features like this are unlikely to land in v1, and that includes the experimental work in #32425.
We'd encourage you to try v2 (
@opencode/cli, theopencodecommand). Its subagent handling is a separate implementation, with each subagent running as its own child session. If you still need to steer or cancel a single running subagent there, please reply here or open a new request for v2. Your points about soft stops at turn boundaries with a hard fallback, the child never blocking on an interrupt, recording whether the user or the parent cancelled it, and escaping and length-capping reasons would all apply there too.Related:
If you think this is critical, or you can reproduce the problem on v2, please reply and we'll take another look.
opencodejr commentedon Oct 29, 2026
Closing this as not planned. The request was made against v1.18.5, and v1 now only gets fixes for critical bugs, so per-subagent steer/cancel/abort won't be added there. We haven't heard that this is critical or that the gap also exists in v2.
Thanks again for the detailed write-up. If you try v2 (
@opencode/cli) and still can't steer or cancel a single running subagent, please open a new request for v2 and link this issue and #32425. The design points you raised would carry over directly.