[BUG] [Cowork] update_artifact fails with generic "Failed to update artifact." error — intermittent, not tied to payload size or content diff

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?

update_artifact (the Cowork MCP tool that updates an existing Live Artifact in place) intermittently fails with a bare, generic error — Failed to update artifact. — no status code, no detail. create_artifact (making a brand-new artifact with the same content) never failed once, across every attempt in this session.

The failure does not correlate cleanly with any single variable I controlled for:

Payload size: failed on a ~10MB HTML file, and also failed on a 72-byte trivial HTML file pushed to the same artifact ID immediately after.
Content diff: failed on a byte-identical re-push of content that was already live, and failed on genuinely new content.
Update history: failed on an artifact ID that had ~7 prior successful updates that day, and separately failed on a brand-new artifact ID that had zero prior updates (only one create_artifact call before the first update_artifact attempt).
It is not a blanket outage either: in the same session, update_artifact succeeded on a different, small (~300 byte) artifact just minutes before failing on the larger one. So the tool isn't uniformly down — it appears to get an individual artifact (or some server-side record for it) into a bad state, but I could not identify the trigger.

What Should Happen?

update_artifact should either succeed or return an error with enough detail to act on (e.g., "artifact locked", "storage quota exceeded", "internal error, retry after Xs") instead of a generic, non-actionable message.
If an artifact id does get into an unrecoverable state, that should be surfaced to the user/agent explicitly (e.g., "this artifact can no longer be updated, create a new one") rather than failing silently/generically on every retry.
Ideally: whatever server-side state causes a previously-working artifact id to stop accepting updates shouldn't happen at all, since it discards the artifact's URL/history/sharing state for the user.

Error Messages/Logs

Evidence — timeline from one investigation session (2026-09-22 to 2026-09-23)
artifact id	created	update attempts	result
central-west-capex-2026-dashboard	2026-09-22T02:30:00.607Z	multiple successful updates through 2026-09-22T15:10:47.189Z, then all subsequent update_artifact calls (next session) fail	stuck — every later update fails, including a byte-identical re-push and a ~72-byte trivial file
central-west-capex-2026-dashboard-v2 (created fresh specifically to work around the above)	2026-09-23T00:10:27.225Z	~6–7 successful updates over the next ~15 hours, then fails	stuck the same way — real content and trivial content both fail
diagnostic-test-tiny	2026-09-23T00:10:14.417Z	1 update attempt (small ~300B placeholder)	succeeded, minutes before the failures below
central-west-capex-2026-dashboard-v3 (created fresh again)	2026-09-23T15:42:14.324Z	first-ever update attempt (real ~10MB content), retried, then retried again with a 72-byte trivial file	all 3 fail identically
diag-test-create-fresh-2	same session	n/a — only create_artifact called	succeeds instantly
central-west-capex-2026-dashboard-v4	same session	n/a — only create_artifact called	succeeds instantly

create_artifact succeeded on every single attempt across the whole session, including immediately after update_artifact had just failed on a different id. verify_artifact's debug log for the very first stuck id also shows an unusually tight cluster of {kind:"load"} events (46 entries across ~21.5 hours, several just minutes apart) plus two recurring JS console errors (Cannot read properties of null (reading 'textContent') and a Chart.js Cannot read properties of undefined (reading 'handleEvent')) — noting this in case it's a relevant secondary signal, though I can't confirm causation, since that artifact also had a real content bug in its own script at the time.

Impact

Once an artifact id gets into this state, it is permanently stuck — no combination of retrying, waiting, or changing the payload got update_artifact working again on that id in this session. The only workaround found was abandoning the id and calling create_artifact with a new id, which means every "update" to a Live Artifact the user wants to keep revisiting instead becomes a brand-new artifact (new URL, lost version history, user has to find the new one in the sidebar each time). For a dashboard that gets iterated on repeatedly in one conversation, this happened 3 times in ~36 hours.

Steps to Reproduce

Not reliably reproducible on demand — it appears to eventually affect any actively-iterated artifact, but I couldn't find a deterministic trigger. Steps that consistently surface it once an id is affected:

Call update_artifact on the affected id with any content → Failed to update artifact.
Call update_artifact on the same id with byte-identical content to what's already live → same error.
Call update_artifact on the same id with a trivial, tiny, syntactically valid HTML file → same error.
Call create_artifact with a brand-new id and the same content from step 1 → succeeds immediately.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — not Claude Code CLI, this is Cowork Desktop. 2.7032.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Cowork Desktop GUI, no terminal involved. Full writeup with the evidence table and exact artifact ids/timestamps is in the issue body above. Related: #80435 (different symptom — silent stale-content revert — but same tool, update_artifact, and same general instability), #86316 (permission prompt gap after remote update_artifact calls).