[BUG] Claude agents can't read a claude.ai artifact via WebFetch — "artifact read failed: incomplete boot response" on a valid same-account artifact (including an Anthropic-published one)
Summary
Claude Code's WebFetch tool is documented to read claude.ai/code/artifact/{uuid} URLs through the user's own claude.ai login (its tool description explicitly says to use WebFetch, not curl, for these). In practice it fails on a valid, same-account artifact with:
artifact read failed: incomplete boot response
Reproduced twice in a row — identical error, same session, same claude.ai account that owns the artifact. This is not an access-scoping problem: it's the artifact-read path failing to boot.
The part that stings: the artifact I was trying to read is one published by Anthropic — guidance on reducing agent-workflow sprawl. So the guidance for fixing exactly the kind of workflow problem I'm fighting is locked behind a broken artifact-read. My agent can't open Anthropic's own artifact to apply it — I have to screenshot or hand-copy it instead.
The contrast that shows it's the host, not the tool: the same WebFetch reads a public GitHub issue URL perfectly. Only the claude.ai artifact — Anthropic's own domain — returns "incomplete boot response."
Steps to reproduce
- From a Claude Code CLI session logged into the account that owns the artifact, call
WebFetchon ahttps://claude.ai/code/artifact/<uuid>URL (the tool's documented-supported case). - Observed:
artifact read failed: incomplete boot response. Reproducible — two consecutive attempts returned the identical error. - Expected: the artifact's contents are returned (per the tool description: "claude.ai/code/artifact/{uuid} URLs ARE fetchable via your claude.ai login — use WebFetch").
Artifact in my case (an Anthropic-published artifact on reducing workflow sprawl): https://claude.ai/code/artifact/bfdfaef9-bc62-4dfe-ba9e-c58a26c9accf
Environment
- Platform: Windows, recent CLI (2.1.21x-era).
- The same claude.ai account owns the artifact and runs the session.
- Cross-surface note: the Claude mobile app's model reports it can't read any artifact URL (it resolves only to "the generic artifact wrapper, not the contents"). So both surfaces fail, differently — mobile can't read artifacts by URL at all; the CLI should per its own tool docs, but errors with "incomplete boot response."
Impact
There is no working way to hand an artifact to an agent to read — not even an Anthropic-published one. Every artifact-based handoff degrades to manual screenshot / copy-paste. For a workflow meant to run agents against shared artifacts, that's a real gap — and it's especially pointed when the unreadable artifact is Anthropic's own guidance on how to reduce that very workflow friction.
Related
- #78348 — Design conversations are account-scoped with no transfer path (the artifact/Design account-binding cluster).
- #78583 — Claude Design can't use a connected filesystem MCP / falsely claims disk writes (adjacent artifact/handoff cluster).
- #79470 — same-day remote-control /
--resumedata-loss report (another surface of the same cross-device/handoff fragility). - #79247 — weekend post-mortem on workflow sprawl; this is a concrete, ironic instance of its point: the fix-the-sprawl artifact is itself unreadable by the agent that would apply it.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗