[Bug] Artifact publish auto-arms live-updates monitor with no opt-out or agent control

Submitted via /bug, feedback ID: b5f7e9c2-d65d-403e-80f8-8ff310170502

Bug Description

Artifact publish auto-arms a live-updates monitor with no opt-out, and the agent cannot stop it

Environment

• Claude Code 2.1.234, desktop app on macOS 26.6.1 (Darwin 25.6.0)
• Model: Opus 5 (claude-opus-5)

Summary

Every Artifact publish silently arms a background monitor_ws task labelled
live updates for artifact (auto-armed on publish). There is no way to decline it
at publish time, no setting to turn it off globally, and the agent that triggered it
cannot stop it — so in a long-lived session it accumulates in the Background tasks
panel and only the human can clear it.

Steps to reproduce

1. In a long-running interactive session, publish an HTML file with the Artifact tool.
2. Observe the tool result: `Live subscription: arming in the background — once

connected, this session is notified if another session republishes this artifact.`

1. Open the Background tasks panel. A monitor_ws entry

live updates for artifact (auto-armed on publish) is running.

1. Ask the agent to stop it.

Expected

Either the live subscription is opt-in, or it can be declined per publish
(e.g. Artifact({..., live: false})) or disabled once in settings.json. Failing
that, the agent should at least be able to stop it with TaskStop.

Actual

• The Artifact tool schema has no parameter controlling the subscription. Publishing

without it is not possible.

• No settings.json key exists for it (nothing artifact/monitor-related in either

~/.claude/settings.json or settings.local.json).

• TaskStop cannot reach it. The task does not appear among the session's background

task output files ($TMPDIR/.../tasks/*.output), and calls with the visible label
(monitor_ws) and with plausible ids all fail with No task found with ID: ….
The real task id (sl89sx1gj in our case) only became visible in a
<task-notification> when the monitor emitted its own [Monitor stopped] event —
i.e. after it was already gone. There is no way to discover the id while it is
running, so the agent has no handle on it.

• The entry stayed in the panel for 20+ minutes across an interactive session, and

each republish arms another one.

Impact

The subscription's purpose is to notice a concurrent republish from another session.
For a large class of artifacts that case cannot occur and the watch is pure overhead:

• Our artifacts are dashboards refreshed by a scheduled task on a slow cadence

(once a day, or Mon/Wed/Fri). Nothing else ever republishes them.

• The panel entry reads as a stuck job to the user, who then asks the agent to clean

it up — and the agent has to answer that it cannot, which is a bad interaction on
both sides.

• Scheduled/headless runs are unaffected in practice (the session ends and takes the

subscription with it), so the cost lands entirely on long interactive sessions.

Suggested fix, in order of preference

1. Make the subscription opt-in, or add a live: false / liveUpdates: false

parameter to the Artifact tool.

1. Add a settings.json key to disable it account- or project-wide.
2. Return the monitor's task id in the Artifact tool result so TaskStop can

target it, and make TaskStop accept it.

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.234
• Feedback ID: b5f7e9c2-d65d-403e-80f8-8ff310170502

Errors

[]