Agent resume error message suggests destructive TaskStop as primary remedy

Summary

When attempting to Agent(resume: id) on a background agent that is still running, the error message suggests TaskStop as the first remedy — a destructive action that kills in-progress work. The non-destructive path (waiting for auto-notification) is listed second, making it easy to miss.

Reproduction

1. Launch a background agent: Agent(prompt: "...", run_in_background: true)
2. Before it completes, attempt: Agent(resume: agent_id)
3. Observe error message

Current behavior

Cannot resume agent {id}: it is still running.
Use TaskStop to stop it first, or wait for it to complete.

The phrasing "Use TaskStop to stop it first, or wait" implies both options are equivalent. In practice:

• TaskStop kills in-progress work (agent may have completed 90% of a multi-file analysis)
• Waiting is almost always the correct choice — background agents auto-notify via <task-notification> on completion
• The model (and users reading transcripts) may follow the first suggestion and destroy useful work

Expected behavior

Prioritize the non-destructive path in the error message:

Cannot resume agent {id}: it is still running.
You will be notified automatically when it completes.
Use TaskStop only if you need to cancel it.

This makes the safe default obvious and frames TaskStop as the exception, not the first option.

Context

Observed during a codebase audit session — a background consistency-check agent ran for ~6.3 minutes. Three Agent(resume) attempts during that window all returned the error. The <task-notification> eventually delivered correctly. No data was lost because we chose to wait, but the error copy nudged toward the destructive path each time.

Related but distinct from #32085 (agent IDs lost after context compaction — that's a state-loss bug; this is an error message UX issue).

Environment

• Claude Code v2.1.71
• Platform: macOS (darwin)
• Model: Claude Opus 4.6