Steering the main chat irreversibly kills all running background subagents

What happened

I sent a steering message to the main chat while two background subagents were running. Sending that message terminated both subagents — including the one entirely unrelated to what I was steering.

Afterwards they could not be resumed. SendMessage to the agent returned:

Agent <id> was stopped by the user and won't be resumed.
Treat its work as cancelled; only launch a new agent if the user explicitly asks.

So several minutes of subagent work were lost, and the agent had to be relaunched from scratch with the same prompt.

Expected behaviour

1. Steering / sending a message to the main chat should not terminate background subagents at all — they are independent units of work, and interacting with the main thread is not a signal to abandon them.
2. If a subagent is stopped, it should be resumable. The SendMessage tool description explicitly promises this ("a send resumes it from its transcript"), and the transcript still exists on disk — but the runtime marks the agent as permanently cancelled, so resuming is impossible.

At minimum these two should agree: either the documented resume-by-message behaviour works, or the tool description should not promise it.

Impact

Any interaction with the main chat becomes risky while background work is in flight. In a long-running session this silently discards work and forces duplicate token spend on a relaunch. It also makes the documented resume-by-message behaviour unreliable, so there is no way to recover an accidentally stopped agent.

Environment

• Claude Code, desktop app
• Model: Opus 5
• Subagents launched via the Agent tool with run_in_background (default)