Agent session cannot publish to a co-written Artifact after a colleague self-publishes (persistent version-conflict errors)

Title

Agent session cannot publish to a co-written Artifact after a colleague's browser session has self-published to it (persistent "hasn't viewed latest version" / baseVersion errors)

Summary

An Artifact with capabilities:{artifact:{}} enabled (so page viewers can self-publish edits from within the page itself) becomes permanently unpublishable from a Claude chat/agent session once a human colleague has used that in-page self-publish feature. Every Artifact.publish call fails, even immediately after a guaranteed-fresh read of the artifact, and even with force:true.

Environment

• Claude Code desktop app session (chat), not a headless/routine run
• Artifact: https://claude.ai/code/artifact/b783ea29-7266-4eb5-85fa-d03a183c2eac
• Artifact has capabilities: {"artifact": {}} declared, used by other editors (colleagues) via the page's own window.claude.use("artifact").publish() to self-publish form submissions

Steps to reproduce

1. Publish an Artifact with capabilities: {"artifact": {}}.
2. Have a different user (not the Claude session doing the publishing) open the artifact in their browser and use its in-page UI to trigger a self-publish (e.g. submit a form that calls window.claude.use("artifact").publish(...)).
3. From a Claude chat session, call WebFetch on the artifact URL to read its current content.
4. Immediately after, call the Artifact tool with action: "publish", the same url, and a locally edited copy of the just-fetched HTML.

Expected behavior

The publish should succeed, since the content was read immediately beforehand and no other write happened in between (confirmed idle).

Actual behavior

Every publish attempt fails with:

This session hasn't viewed the latest version of the artifact. Read it first (WebFetch the URL), reapply your edits, then publish. force:true discards the other session's changes — use it only if the user asks to overwrite.

Retrying WebFetch (including with a cache-busting query parameter appended to the URL, to rule out a WebFetch-side cache) immediately before each retry made no difference — the error was identical every time, across 8+ attempts over roughly 40 minutes, including attempts made after the human co-editor confirmed they were not actively using the page.

Passing force: true on the Artifact.publish call changes the error to a different, harder failure:

deploy 400: this artifact self-publishes — provide the baseVersion you edited from

The Artifact tool's exposed parameters do not include any baseVersion field, so this error cannot be resolved from the client side at all with the current tool schema.

Additional observation

Across all 8+ WebFetch calls on the artifact URL (with and without a cache-busting query param), the returned content was byte-identical every time — same <base href="/_f/1787738772-f8ad/"> version fingerprint, same restockLog data. This suggests either:

• WebFetch was serving a stale cached copy that never actually reached the live server-rendered version, or
• The version pointer that the publish endpoint checks against is tracked separately from whatever WebFetch/the artifact read path returns, so no amount of re-fetching before publishing can ever satisfy the check from an agent session.

Impact

This blocks a core intended use case: a Claude session and one or more human colleagues collaboratively maintaining the same Artifact, where humans edit through the page's own UI (self-publish capability) and Claude edits through the Artifact tool. Once any human colleague has self-published once, the artifact appears to become permanently unpublishable from any Claude session — with no available workaround (retry, force, or otherwise) using currently exposed tools.

Suggested fix directions

• Expose the required baseVersion (or equivalent) as an optional parameter on the Artifact tool's publish action, so force:true (or a targeted variant) can actually complete the overwrite it claims to perform.
• Alternatively/additionally, ensure that a WebFetch read (or the Artifact tool's own read path) immediately prior to a publish reliably updates whatever "latest version viewed" state the publish endpoint checks, so the documented recovery flow ("Read it first via WebFetch, reapply edits, then publish") actually works as described.