[BUG] Interrupting a turn silently kills in-flight background subagents — no notification, no failure state
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet (searched: interrupt kills background agents, interrupted subagent silently)
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
What's Wrong?
When the user interrupts the assistant's turn (esc / sending a new message mid-turn), background subagents that are currently in flight are killed — silently. Their transcripts just end with [Request interrupted by user], no task-notification fires, no failure status is surfaced to the model or the user, and the tool results from the original Agent spawn still read as if the agents are running.
Steps to Reproduce
- Ask Claude to launch several background subagents (Agent tool, run_in_background default).
- While they're running, interrupt the turn with a new user message.
- Observe: subagent JSONL transcripts stop growing, last entry is
[Request interrupted by user]; no completion/failure notification is ever delivered.
Expected
Either (a) background agents survive a turn interruption (they're 'background' — the spawning turn ending shouldn't kill them; a later assistant turn can still receive their notifications), or (b) if they must die, deliver an explicit task-notification (status: killed/interrupted) so the model knows to relaunch instead of waiting forever.
Actual
Agents die silently. In our session the assistant kept waiting on three dead scout agents; only a manual check of the transcript files (mtime stopped advancing, tail showed the interrupt marker) revealed they were gone, costing ~15 minutes and a full relaunch.
Environment
- macOS (Darwin 24.6.0), Claude Code desktop app 2.1.209
- Model: claude-fable-5
- Subagents: Explore type, spawned via Agent tool in background
(Filed on behalf of my user by Claude Code itself. Related-but-different: #73095 — SendMessage-resumed agents never appear in the running-agents UI.)
3 Comments
The silent-kill behavior here is a real gap in the agent lifecycle contract. When an interrupt fires, there's no signal that distinguishes "the parent was interrupted" from "the subtask completed normally" -- so anything waiting on the subagent's result just hangs.
One interim workaround I've found useful: write a brief status line to a shared file (e.g.,
.agent-state/subtask-name.status) at each major checkpoint inside the subagent's instructions. If the parent is interrupted and you restart, you can inspect those files to see where each subagent was when it died, rather than staring at a silent transcript.The deeper fix probably needs a dedicated "task interrupted" event type in the notification system -- something the model can react to, not just the UI. The
Stophook fires for the agent that's stopped, but a parent-side "my children were killed" hook doesn't seem to exist yet.Related: #73095 surfaces the same visibility gap from the other direction (resumed agents not appearing in the running-agents UI). Looks like the agent state machine is missing a few transitions at both ends of the lifecycle.
Still happening on 2.1.280 through Remote Control: "Send now" on a queued message interrupts the turn and silently kills all running background agents. Opened #97705 for "Send now" to deliver the message without touching background work.
Same thing on the CLI with Ctrl+C (2.1.296, Windows 11, inside zellij).
I had text in the input bar and hit Ctrl+C just to clear it. One press interrupted the turn, cleared the input, and killed the running background subagent.
Repro: spawn a background subagent that appends a timestamped heartbeat to a file every 10s for 2 min, type something, hit Ctrl+C. The file stops at:
Beat 2 never lands. One difference from the original report: here the model did get a notification (
Background agent "..." was stopped by the user.), so it's not silent, but the work is still gone.What I'd want: Ctrl+C with text in the input only clears the input. Background agents only die when I ask for it (
ctrl+x ctrl+k, or after I switch to that agent and stop it). Ctrl+C is hardcoded and can't be rebound inkeybindings.json, so right now the only workaround is to never touch it.---