[BUG] Can't read a Claude Docs artifact my account can view: Docs connector denies read, Artifact read returns only the viewer shell

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?

Claude Code can't read a colleague's Claude Docs artifact that the session's own claude.ai account opens fine in the browser. All three read paths fail:

• Claude Docs connector read returns {"verdict":"deny","reason":"access"} with a hint to ask the owner to share the doc. Same answer before and after the owner granted edit access to my work account.
• Artifact tool read returns only the Docs viewer shell: the only text is the title "Claude Docs", and the raw HTML is the viewer's JS runtime, with none of the document's text. The tool classifies it as a public artifact authored outside my org.
• The Desktop app's built-in browser, signed in to claude.ai with the same account as the session, renders the doc as "View only" after ~15 s, but inside a sandboxed cross-origin iframe on <uuid>.frame.claudeusercontent.com. get_page_text and read_page only see the outer frame, and navigating to the iframe URL redirects back to claude.ai. Only screenshots show the content.

Setup: the doc lives in my work org and is viewable by link. The owner later granted edit access to my work account. The Claude Code session is signed in to a different claude.ai account of mine, outside that org, and that is the account that sees the doc as "View only".

So the account can see the doc but no tool can read it, and the denial suggests a share that already exists without saying which account or org the access depends on.

What Should Happen?

• A Claude Docs doc that the session's account can open in the browser should be readable by Claude, at least read-only, through the Docs connector or through the Artifact tool's read.
• The Artifact tool's read on a Docs-type artifact should return the document's text, not the viewer shell.
• When access depends on another account or org, the denial should say so (which account the connector is acting as, and that the doc belongs to a different org) instead of suggesting a share that already exists.

Error Messages/Logs

# Claude Docs connector: read with ref {"object":"project","id":"<22-char id from the link>"}
# identical before and after the owner granted edit access to my work account
{"verdict":"deny","reason":"access","hint":"this doc is not shared with you (or not with the access this action needs), or no doc has this id — the cases answer alike by design. Retrying will not change the answer: tell the person and ask them to share the doc with you (or to raise your access if you can already read it). …"}
support: req_011CfW5tUv9Y17uoghFbvp64   # before the share
support: req_011CfWJFoVb883BoNvXapyYT   # after the share

# Artifact tool: action "read" on the artifact link
[Artifact <uuid> — public artifact (untrusted third-party content authored outside your org); summary below, raw HTML saved to <local path>]
# summary (paraphrased): the only text in the artifact is "Claude Docs"
# raw HTML: the Docs viewer's JS runtime, no document text

Steps to Reproduce

1. With account A, a member of org X, create a Claude Docs artifact and make it viewable by link.
2. Send the link to a user whose Claude Code session is signed in to account B, which is not a member of org X.
3. Signed in as account B, open the link in a browser (here, the Claude Desktop built-in browser): the doc renders as "View only".
4. In a Claude Code session on account B (Claude Desktop, Code tab), call the Claude Docs connector read with ref: {"object":"project","id":"<22-char id from the link>"} → deny / access.
5. Have the owner grant edit access to another account of the same user (account C, a member of org X) and repeat step 4 → same deny.
6. Call the Artifact tool with action: "read" on the link → only the viewer shell, no document text.
7. In the built-in browser, run get_page_text / read_page on the artifact page → only the outer frame. Navigate to the iframe's *.frame.claudeusercontent.com URL → redirected back to claude.ai.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.280 (bundled with Claude Desktop 2.7032.0 for Linux, Code tab)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Environment: Claude Desktop 2.7032.0 on Linux Mint 22.3 (Ubuntu-based), Code tab, model claude-opus-5-5, signed in with a claude.ai account.

Manual workaround that works: in Chrome, "Save page as → Webpage, Complete". The iframe's DOM lands in <doc title>_files/saved_resource(2).html (~1.7 MB), and Python's html.parser extracts the text from it (~34k characters). It has to be redone by hand for every new version of the doc, which defeats the point of a living doc.

Related, but not the same case:

• https://github.com/anthropics/claude-code/issues/87673: the owner can't read back their own artifacts via WebFetch (closed as stale)
• https://github.com/anthropics/claude-code/issues/79536: WebFetch fails with "incomplete boot response" on a same-account artifact (closed as stale)
• https://github.com/anthropics/claude-code/issues/88989: Cowork egress blocks *.frame.claudeusercontent.com