[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)

Status Open
Maintainer reply None cached
Activity 1 comment · opened Jul 20, 2026

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

  1. From a Claude Code CLI session logged into the account that owns the artifact, call WebFetch on a https://claude.ai/code/artifact/<uuid> URL (the tool's documented-supported case).
  2. Observed: artifact read failed: incomplete boot response. Reproducible — two consecutive attempts returned the identical error.
  3. 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 / --resume data-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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗