[FEATURE] Cowork can't read the user's own published artifacts — no authenticated read path, unlike Claude Code
[FEATURE] Cowork can't read the user's own published artifacts — no authenticated read path, unlike Claude Code
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single request
- [x] I am using the latest version
What I'm Trying To Do
Ask a Cowork session to read back one of my own published artifacts — a claude.ai/code/artifact/{uuid} page that I created and own — so it can update it, audit it, or use it as input to another artifact.
This does not work, and there is currently no route that does.
What Happens
WebFetch on the artifact URL fails in Cowork. It does not return my artifact's content.
Two things make this worth reporting as a gap rather than a permissions problem:
1. WebFetch itself works fine in Cowork. In the same sessions, on the same day, it fetched ordinary sites without trouble:
webfetch:stockanalysis.com → approved → 26,093 chars
webfetch:www.jobs.manchester.ac.uk → approved
webfetch:findajob.dwp.gov.uk → approved
webfetch:example.com → approved → 249 chars
webfetch:news.ycombinator.com → approved → 16,983 chars, 163 linksSo this is not a disabled tool, a missing permission, or a network sandbox problem. Generic fetching is healthy; my own artifact specifically is not reachable.
2. Claude Code can already do it. From the Claude Code CLI, WebFetch on the exact same URL returns the artifact, explicitly tagged as mine:
[Artifact dc0d7658-… "Skills Galaxy" — owned by you; raw HTML follows]
<!doctype html>…Claude Code's own tool documentation calls this out as a deliberate capability — "claude.ai/code/artifact/{uuid} URLs ARE fetchable via your claude.ai login — use WebFetch, not curl." So an authenticated artifact read exists in the product. Cowork just doesn't have it, despite being the surface that creates most of these artifacts.
Why This Matters
The obvious workaround — read the local copy at ~/Claude/Artifacts/<slug>/index.html instead — also doesn't work, because publishing stops updating that file once an artifact is hosted. On my machine the local copy of one artifact is five weeks behind its hosted version. (Filed separately.)
Between the two, a published Cowork artifact is currently unreadable from Cowork by either route: the URL isn't authenticated and the local file is stale. Cowork can write artifacts but cannot reliably read back what it wrote. That blocks:
- updating an artifact whose source file is gone or was authored in another session
- auditing or diffing what's actually live versus what a skill believes is live
- one artifact consuming another as input
- any scheduled task that reconciles hosted state
What I'd Like
Give Cowork the same authenticated artifact read that Claude Code has — WebFetch on a claude.ai/code/artifact/{uuid} URL owned by the signed-in user should return that artifact's current content. A dedicated tool (read_artifact(uuid)) would be just as good, arguably better, since it could return version metadata alongside the HTML.
Note On The Error Text
I have not captured the verbatim string Cowork returns when the artifact fetch fails, and I'd rather leave that gap visible than paraphrase it into something misleading. I'll add the exact text as a comment on this issue. The behaviour above — generic fetches succeeding in the same session, the same URL succeeding in Claude Code — is reproducible without it.
Possible Mechanism (inference — unverified, may be wrong)
Cowork's WebFetch appears not to fetch locally at all. It looks like it POSTs to …/api/organizations/{orgId}/cowork/web_fetch with {url, allowed_urls}, and that server-side fetcher retrieves pages anonymously — it doesn't carry the signed-in user's session, so a private artifact page looks like any other private URL and is refused. There also seems to be a provenance guard, where allowed_urls is seeded from previously-fetched pages' links, so a URL pasted in cold may be rejected before it's even attempted.
I inferred this from the desktop bundle and log lines rather than from source, and I was wrong twice on the way to it — so please treat the mechanism as a hint, not a diagnosis. The observable facts are the ones above: generic fetches succeed in Cowork, the same artifact URL succeeds in Claude Code, and it fails in Cowork.
Environment
- macOS (Apple Silicon), Darwin 25.5.0
- Claude Desktop 1.44121.1
- Bundled Claude Code SDK 2.1.258
- Plan: <fill in — Pro / Max>
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗