Interrupting a conversation terminates in-progress background tasks (Workflow / async subagents), wasting already-billed tokens

Summary

Sending a new chat message while a background task is running - which interrupts the active turn - immediately terminates that background task. The tokens the task already consumed are still billed, no partial output is saved, and there is no warning that interrupting will kill background work. In my session this destroyed a ~2.6M-token multi-agent job, and it happened more than once, because sending a message is the normal way to add context mid-task.

Environment

• Claude Code version: (unknown - not resolvable from the shell in this session)
• OS: Windows 11
• Model: Claude Opus 4.8
• Feature involved: background tasks - the Workflow tool (multi-agent orchestration) and async subagents that run in the background across turns.

Steps to reproduce

1. Launch a long-running background task designed to run across turns (e.g., a multi-agent Workflow, or any tool invoked with run_in_background).
2. While it is still running, send a new chat message. This interrupts the current turn.
3. Observe that the background task status flips to "Stopped."

Expected behavior

Background tasks are explicitly designed to run independently and persist across turns. Interrupting the foreground turn to send a message should not kill them. At minimum, one of:

• Background tasks keep running after a foreground interrupt (preferred), or
• The user is clearly warned / asked to confirm before an interrupt cancels running background work, or
• Completed sub-steps are checkpointed so an interrupted task can resume without re-billing finished work, and partial results are surfaced.

Actual behavior

• Interrupting the turn silently terminates all in-progress background tasks.
• In this case ~2.6M tokens across 22 subagents were consumed and billed, then the run was stopped mid-synthesis with zero usable output.
• No warning is shown that sending a message will terminate the running task.
• Because sending a message is the normal interaction, this is trivially easy to trigger accidentally - I triggered it twice in one session (the second time while trying to report the first).

Impact

• Direct, quantifiable token/cost waste - millions of tokens per incident, with nothing to show for it.
• Undermines the core value of the background-task feature: the user cannot safely communicate while a task runs, which is the entire point of running it in the background.

Suggested fixes (any subset)

1. Decouple background task lifecycle from the foreground turn so tasks survive interrupts.
2. Prompt to confirm before an interrupt cancels running background work (e.g., "1 background task is running - stop it? [y/N]").
3. Checkpoint completed sub-steps so an interrupted task auto-resumes without re-billing completed work.
4. Show a persistent indicator that an interrupt will terminate N running background task(s).