[BUG] Explicit Artifact unwatch is discarded on session resume, so the watch re-arms and keeps waking the session

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

An explicit Artifact action: "unwatch" does not survive a session resume. The watch is silently re-armed, and the session starts waking on artifact events again with no user action and no indication that the earlier stop was discarded.

This is distinct from #93712 (watch records for deleted artifacts re-arming at every start) and from #90225 (an already-delivered artifact-changed notification being re-delivered after an app restart). The artifact here was never deleted and no duplicate notification was involved. The failure is that a deliberate user-requested stop is not persisted.

Observed sequence in one session

1. Published an artifact. The publish result reported that a live watch was arming.
2. Called Artifact action: "unwatch" on that URL. The tool confirmed the stop:

> Stopped watching https://claude.ai/code/artifact/<id>; republishes of it will no longer be reported in this session. Do not watch it again unless the user asks.

1. Later in the same session, a task notification arrived stating the watch had ended for an unrelated reason:

> Watch on https://claude.ai/code/artifact/<id> ended — the live connection kept failing and reconnecting has stopped. This session will no longer hear when it is republished; watch it again if you still need that.

1. The user then reported that this conversation kept being pushed to the top of their session list.
2. Artifact action: "status" showed the watch alive again:

> 1 artifact watch in this session
> - https://claude.ai/code/artifact/<id> — connected, re-armed when this session was resumed, since 2026-10-08T20:43:04.528Z

1. A second unwatch stopped it again, and status then returned "No artifact watches in this session". Nothing else was running: CronList returned no scheduled jobs and the scheduled-tasks MCP returned none.

Two separate problems in that sequence

The re-arm overrides an explicit stop. The status text documents the re-arm as intended behavior ("a --resume in an interactive terminal brings back the watch on the most recently used artifact"). But it makes no distinction between a watch that was merely interrupted and one the user deliberately stopped. An explicit unwatch is the only documented lever for turning this off, and it is discarded at the next resume, so there is no way to make the stop stick for the life of a session.

The reported state contradicted itself. At step 3 the session was told the watch had ended because reconnection had stopped. At step 5 the same watch reported as connected and re-armed. One of those two messages was wrong at the time it was written, and from the user's side the first one actively conceals the problem: it reads as confirmation that the thing is off.

Impact

Each re-arm wakes the session on artifact activity, which moves the conversation to the top of the session list. For a session the user has finished with, this recurs on every resume indefinitely. The user cannot tell from the session list which conversation holds a watch or why it keeps surfacing, and the only reliable remedy is deleting the artifact, which is not always acceptable. The user reports this behavior as long-standing rather than new; the evidence above is from a single session on 2.1.295.

What Should Happen?

An explicit unwatch should be recorded as a deliberate stop and should not be re-armed by a subsequent resume. Re-arming on resume is reasonable for a watch that was interrupted; it should not resurrect one the user turned off.

Two smaller fixes in the same area:

• A "watch ended, reconnecting has stopped" notification should not be emitted for a watch that is about to be re-armed, or the re-arm should correct it. The two messages currently disagree.
• Artifact action: "status" should show whether a watch was re-armed over a prior explicit stop, so the state is attributable without reconstructing the session history.

Steps to Reproduce

1. In a session, publish an artifact. A live watch arms automatically.
2. Call Artifact action: "unwatch" with that artifact's URL. Confirm the tool reports the watch stopped.
3. Resume the session.
4. Call Artifact action: "status". The watch is listed as connected and "re-armed when this session was resumed".
5. The session now wakes on artifact events again and the conversation returns to the top of the session list.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.295

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related but distinct: #93712 (deleted artifacts re-armed at session start), #90225 (duplicate artifact-changed notification after app restart), #97686 (auto-armed watch keeps running after the artifact is deleted). All three share the symptom of a session waking or surfacing without user action, which makes them easy to conflate.