Resuming a session re-arms the comment monitor for only one Artifact, though several are persisted as armed

Environment

• Claude Code 2.1.238, Linux (Kubuntu 24.04), zsh, CLI

Summary

A session that has published more than one Artifact only gets one of its
comment monitors back when the session is resumed — the most recent one. The
others are dropped, and every resume prints a notice about them:

Automatic replies were not resumed for https://claude.ai/code/artifact/<artifact-A>
— a resumed session brings back at most its most recent Artifact's comment monitor.
Ask Claude to watch one of these, or publish it again, to turn its replies back on.

The limitation is in the resume path only. Multiple monitors can be armed at
once while the session runs, and the transcript already records them that way.

Evidence that this is a resume-path limit, not a capacity limit

The session in question published two Artifacts, and its transcript contains 15
artifact-comment-monitor records. Parsing them (rather than eyeballing), 14 of
the 15 hold both artifacts, each with "state": "armed", in the same record:

{"type":"artifact-comment-monitor","v":1,"sessionId":"…","artifacts":{
  "<artifact-A>":{"state":"armed","writtenAtMs":…,"title":"…"},
  "<artifact-B>":{"state":"armed","writtenAtMs":…,"title":"…"}}}

So the persisted state is a map and is perfectly capable of holding several
armed monitors — and in my case it currently does. What the resume path does is
re-arm exactly one of them and warn about the rest.

Why this matters

• The whole point of arming a monitor is that someone may comment on a page you

shared. Losing it is silent in the direction that matters: the page keeps
accepting comments, they just stop reaching Claude.

• It is not a one-time notice. It reappears on every resume of that session,

so it reads as a recurring error rather than a state you can resolve.

• With two or more Artifacts the situation cannot be resolved at all: re-arming

the dropped one makes it the most recent, and the next resume drops the other.
You are choosing which artifact loses auto-replies, permanently.

• The user did not do anything to disarm them. From their side, nothing changed

except closing and reopening the session.

Expected behaviour

Re-arm every monitor that was armed when the session ended, since the state to
do so is already persisted. If there is a real reason to cap the number of live
monitors per session, say so in the notice and make the cap explicit — the
current wording ("at most its most recent") describes the mechanism but not why
the rest are worth losing.

Workaround

Ask Claude in that session to watch the dropped Artifact again. It works, and
both monitors are live again — until the next resume, which drops one of them
once more.

Related

• #87673 — Claude cannot read back Artifacts it published (different problem, same area)