Repository navigation
[FEATURE]: A running subagent cannot be steered, cancelled, or aborted individually #38966
Description
Activity
This issue might be a duplicate of or closely related to existing issues. Please check:
- [BUG] Stuck subagents can't be nudged/restarted — Esc+Esc creates contextless replacement #32431: Stuck subagents can't be nudged/restarted — overlaps with the "correct it and let it continue" use case
- [FEATURE]:Add Suspend/Resume functionality to pause Agent and Subagent execution #27511: Add Suspend/Resume functionality to pause Agent and Subagent execution — covers similar per-subagent control needs
- v2: shell: no way to stop a running background command #36424: no handle at launch to stop/cancel running background commands — related steer/cancel gap
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.
- changed the title
[-]A running subagent cannot be steered, cancelled, or aborted individually[/-][+][FEATURE]: A running subagent cannot be steered, cancelled, or aborted individually[/+]on 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.
Confirm. This is a real problem.
At least earlier we could stop subagent execution, but now we can't.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.
Feature 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:
Suggested behaviour
Per-subagent steer / cancel / abort, from the parent (as tools) and from the human (TUI).
Points worth deciding rather than discovering:
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.