Stop/interrupt kills in-flight background agents — should interrupt the turn, not the workers

Problem

Pressing stop/interrupt during a turn cascades the kill to background subagents spawned via the Agent tool (run_in_background: true). In a long-running orchestration session (multi-agent engine-porting project), the user pressed stop intending only to interject — to stop the assistant's current output — and the harness killed a background fixer agent that was mid-iteration on a build-and-verify loop, discarding its in-context state.

The user's mental model: stop = interrupt the conversation turn; background workers keep working. The actual behavior: stop = kill the turn and its spawned background tasks. The user compared this unfavorably to other tools' handling of long-running work.

Why it matters

Sessions that orchestrate background agents treat them as durable workers, not disposable turn-scoped calls. When stop kills them:

• work in the agent's context (not yet committed/written) is lost;
• the operator becomes afraid to interject, which defeats the point of interactive steering;
• there is no way to say "pause output, let the workers finish."

We now defensively require every agent to checkpoint to disk every ~25 tool uses purely because a user interjection can kill it — that's workaround, not design.

Suggested behavior (any of)

1. Stop interrupts the assistant's turn only; background tasks keep running (with a visible way to stop them individually — they already appear as tasks).
2. If a stop would kill running background tasks, prompt: "3 background agents are running — stop them too? [interrupt only / stop everything]".
3. A distinct 'pause' affordance that quiesces background agents (signal them to checkpoint and stand down) instead of SIGKILL semantics.

Environment

Claude Code desktop app, macOS (Darwin 25.5.0), long-running session with Workflow + Agent background tasks.

🤖 Generated with Claude Code