[BUG] Desktop: forking a session duplicates its artifact watch, so a publish from the original wakes the fork into an unrequested turn

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Forking a session that has previously published an Artifact leaves two sessions subscribed to live updates of the same artifact URL. When the original session republishes that artifact, the fork receives an artifact-changed task-notification and runs a full unrequested turn.

From the user's side it looks like the prompt typed in the original chat was mirrored into the fork: the fork starts working at the same moment, but produces unrelated output, and both sessions draw down the same 5h usage budget. The fork was never given the prompt. It was given a notification.

Evidence from the local transcripts

Session A = original (c074ddf3-...), session B = fork (353e0107-...), same cwd, desktop app. B was forked from A on 2026-09-01T15:04:09Z. A had published artifact fa4fb125 four times before the fork (2026-08-27 and 2026-08-28), so the watch was part of the history B copied. B has never published anything itself.

All times UTC.

| Time | Session | Event |
|---|---|---|
| 08:37:02 | A | user prompt |
| 08:50:16 | A | Artifact publish of dostup-ehd.html to artifact fa4fb125 |
| 08:50:34 | B | receives <task-notification><task-type>artifact-changed</task-type> for fa4fb125 |
| 08:50:52 | B | calls Artifact action: "read" on that URL, then continues autonomously |
| 08:55:59 | B | last of 31 unrequested assistant turns |

Apparent cause

A fork copies the transcript, including the state in which a publish armed a live-updates watch. When the fork is opened it appears to restore that watch the same way --resume does, so both sessions end up watching one artifact URL and either one's publish wakes the other.

Watches are documented as session-local. B never published and never asked to watch anything, so it should hold no subscription to A's artifact.

Cost

Summed per-turn usage across B's 31 unrequested assistant turns: 38,862 output tokens, 1,329,610 cache-creation tokens, 19,966,675 cache-read tokens. That was a material part of what exhausted the 5h window, for work nobody asked for. B did not republish, so there was no ping-pong loop between the two sessions, but with two forks of a publishing session a loop looks reachable.

What Should Happen?

A forked session should not inherit the parent session's artifact live-update subscriptions.

Either drop watches when a transcript is copied into a new session, or scope the restore so that only the session which actually published the artifact, or explicitly called Artifact action: "watch", holds the subscription.

Failing that, an inherited watch should at minimum be visible and cancellable before it fires, rather than surfacing only as an unexplained turn in a chat the user was not looking at.

Error Messages/Logs

The full input the forked session received at 2026-09-02T08:50:34.815Z, from its transcript
(~/.claude/projects/<project>/353e0107-....jsonl). This is the entire user-role turn: there is no
prompt from the user anywhere in it.

<task-notification>
<task-type>artifact-changed</task-type>
<summary>Artifact changed: https://claude.ai/code/artifact/fa4fb125-...</summary>
Artifact https://claude.ai/code/artifact/fa4fb125-... appears to have been republished elsewhere
(by another session, or by someone saving from the page itself) - it is now version 1788339017-e04a.
Your copy is stale; re-read before editing or republishing (read it with the Artifact tool
(action: "read", url)).
</task-notification>

Matching publish in the parent session's transcript (c074ddf3-....jsonl) 18 seconds earlier:

2026-09-02T08:50:16.714Z  tool_use Artifact  action=publish  file_path=...\scratchpad\dostup-ehd.html

First tool call of the fork's unrequested turn:

2026-09-02T08:50:52.560Z  tool_use Artifact  action=read  url=https://claude.ai/code/artifact/fa4fb125-...

Steps to Reproduce

1. In session A, publish an Artifact (any page). This arms the live-updates watch on A.
2. Fork A into session B, and send at least one message in B so it warms up.
3. Go back to session A and prompt it to change and republish the same artifact.
4. Watch session B. Within roughly 20 seconds it receives an artifact-changed notification and starts an unprompted turn, beginning with Artifact action: "read" on that URL.

Observed on 2026-09-02 with 2.1.255: A published at 08:50:16Z, B was woken at 08:50:34Z and ran until 08:55:59Z without any user input.

The forked session in this case was several days old (forked 2026-09-01, parent's publishes were 2026-08-27 and 2026-08-28), so the inherited watch survives across app restarts and is not limited to a freshly created fork.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.255

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Related issues

• #90225 - artifact watch re-delivers the same artifact-changed notification on every app restart, firing an unrequested turn. Same delivery path and same outcome, different trigger (restart re-delivery, not forking). That issue explicitly does not cover a second session being woken by another session's publish.
• #89019 and #87734 - Artifact publish auto-arms a live-updates watcher with no handle and no opt-out. That is the enabling condition here: the watch the fork inherits is one the user never asked for in the first place.
• #89569 - desktop session shows as busy because of the live subscription.

Scope of what I verified

The timeline, the notification payload, the tool calls and the token counts above are taken directly from the two session transcripts under ~/.claude/projects/. The "apparent cause" (the fork re-arming the inherited watch when it is opened) is inference: the effect is observable, the re-arm itself is not, so treat that part as a hypothesis rather than a confirmed mechanism.

Environment note

Desktop app on Windows 11 Pro 26200. Both sessions are local sessions in the same working directory. Transcripts spanned versions 2.1.246 / 2.1.247 / 2.1.255; the incident itself was on 2.1.255.

Workaround for anyone hitting this

Run Artifact action: "unwatch" on the URL inside the forked session, or archive the fork once it is no longer needed.