Skip to content

[FEATURE]: A running subagent cannot be steered, cancelled, or aborted individually #38966

Description

@iceteaSA

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions