Artifact publish auto-arms a monitor_ws task but returns no task_id, so the assistant cannot stop what it caused

Summary

Publishing an Artifact auto-arms a background task (shown in the tasks panel as live updates for artifact (auto-armed on publish), type monitor_ws). The Artifact tool result mentions that a live subscription is arming, but never returns the task's id. Since TaskStop requires a task_id, and there is no tool for the assistant to enumerate running tasks, the assistant cannot stop a task its own tool call created.

Net effect: N artifact publishes leave N background tasks that only the user can clear.

Version

Claude Code 2.1.237 (Desktop app engine, macOS 15.x / Darwin 25.5.0)

Reproduction

1. Ask Claude to build something and publish it as an Artifact.
2. Have it iterate and republish a few times (I hit this with four publishes of one deliverable across a long session).
3. Open the tasks panel. There is one monitor_ws task per publish, all still running.
4. Ask Claude to stop them.

Expected

Claude can stop a background task that one of its own tool calls started, e.g. because the Artifact result includes the task_id of the subscription it armed (the same way Agent, Monitor and background Bash all return an id that TaskStop accepts).

Actual

Claude cannot. Specifically:

• The Artifact tool result contains no id, only prose: Live subscription: arming in the background ...
• TaskStop with the artifact UUID fails: No task found with ID: 4e3f7740-...
• The real ids are short slugs (si4oxyrtq, sbevixey7, szjy55fmr, ssfmi8eq6). They are only ever surfaced after the task stops, in the stop notification, which is too late to be useful.
• TaskOutput's own description says ids "can be found using the /tasks command", which is a user-facing slash command, not something the assistant can invoke.
• Monitor tasks write no id-bearing file into the session's tasks/ directory (only explicitly spawned agents/bash tasks do), so there is no side channel either.

So the user has to clear each one by hand from the panel.

Why it matters

It breaks an otherwise clean invariant: every background task the assistant explicitly spawns (subagent, Monitor, background Bash) returns an id and is stoppable. This is the one case where a tool creates a task as a side effect and withholds the handle, which means an agent can accumulate work it is structurally unable to clean up. That is a surprising property for a user to discover, and the assistant cannot even enumerate the mess to report it accurately.

Suggested fixes (any one would resolve it)

1. Return the armed subscription's task_id in the Artifact tool result.
2. Auto-replace the previous subscription when the same artifact (same URL/file path) is republished, so iterating on one artifact yields one task rather than N.
3. Provide a task-enumeration tool (a TaskList counterpart to TaskStop) so the assistant can see and manage tasks it did not spawn.
4. Expire artifact subscriptions with the session, and/or make arming opt-in rather than automatic.

(2) alone would have reduced my four tasks to one, and (1) is the smallest change that restores the "you can stop what you started" invariant.