Artifact publish auto-arms a monitor_ws live-updates watcher with no returned handle and no opt-out

Summary

Publishing a claude.ai Artifact via the Artifact tool auto-arms a persistent
monitor_ws watcher (a Monitor tool ws-source watch) for "live updates" on that
artifact — one per distinct artifact, idempotent within a session. Two ergonomics gaps
make this a problem, especially in unattended / scheduled sessions:

1. The watcher's handle is not surfaced at arm time. The publish result announces the

subscription in prose but returns no task ID. No callable tool lists active monitors
(task IDs come only from the /tasks UI command), so the watcher cannot be stopped
from inside the session — TaskStop has nothing to aim at, and the artifact UUID is
rejected (No task found with ID: …). The short task ID (e.g. ss2y34hqc) only appears
in the stop notification, which is too late to use.

1. There is no publish-time opt-out. The Artifact tool schema exposes no parameter to

decline the live subscription. (capabilities: {} clears a page's stored capability
declaration — a different thing.) Arming on publish is unconditional.

What the watcher is for

Per the publish result's own text, once connected the session is notified when (a) another
session republishes the same artifact, or (b) a comment on it is sent to Claude while that
thread's auto-replies are armed; plain comments never notify. A republish within the same
session does not arm a second watcher ("already connected from earlier in this session").

Why it matters

In an unattended, scheduled run — e.g. a daily routine that publishes several artifact pages
per run — these accumulate, one per distinct artifact, and stay Running (a persistent, idle
WebSocket) for the session. In that context neither trigger has a consumer: nothing
republishes the artifacts concurrently and no human is present to comment, so each watcher is
notification overhead that can't be cleanly stood down from inside the session. Observed in
one run: three such watchers still Running 35 / 17 / 12 minutes after the publishes that armed
them.

Requests

1. Return the watcher's task ID in the Artifact publish result (and/or expose an

in-session way to list active monitors), so it can be passed to TaskStop. (Whether
TaskStop accepts such an ID while the monitor is running is currently untested — the
ID isn't discoverable until it stops, so it can't be tried.)

1. Add a publish-time opt-out to decline the live subscription — most valuable for

unattended runs, where neither trigger the watch exists to serve has a consumer.

Repro (approximate)

1. In a session, publish a page via the Artifact tool.
2. Observe a monitor_ws "live updates for artifact (auto-armed on publish)" task in the

Background tasks panel.

1. Note the publish result returns no task ID, and there is no way to stop the watcher from

the session.

Environment

Claude Code (CLI). Observed 2026-08-21.