[BUG] [Cowork] Sessions can't read or update their own published Artifacts by default (cloud_default egress blocks *.frame.claudeusercontent.com)

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?

In a Cowork session, reading or updating an Artifact that this same account published fails.

Calling the Artifact tool's read action on the artifact's own URL — and a normal (non-forced) publish, which reads the live version first — is blocked. The tool returns:

"this environment's network allowlist blocks <id>.frame.claudeusercontent.com, and the session gateway could not serve the read either (artifact reads through the session gateway are not enabled for this session); your access to the artifact itself is fine (the permission check passed)."

Because a normal publish can't read the current version, it silently skips the republish and returns without updating the page — so a scheduled Cowork task that maintains a living artifact (dashboard/tracker/status page) leaves the published page stale with no error surfaced to the user. Both fallback paths are off: frame-host egress is blocked AND the session-gateway artifact-read path is disabled for the session.

The error tells the user to add *.frame.claudeusercontent.com under "environment settings → Code → Network access → Custom → Allowed domains," but that control belongs to Claude Code (web) cloud environments — it does not apply to the managed cloud_default environment Cowork actually runs in, so the user cannot fix it. Confirmed: a fresh session in the Cowork environment still fails the read after that setting was changed.

The only workaround is force:true on publish, which deliberately discards the version/safety check that the read exists to provide.

What Should Happen?

A Cowork session should be able to read and update an Artifact it owns by default — including from a later or scheduled session — with no network setting for the user to change.

Concretely: calling the Artifact tool's read action (and a normal, non-forced publish, which reads the live version first) on an artifact this account published should succeed in a Cowork cloud_default environment, so a scheduled task can refresh its own dashboard/tracker/status page through the normal publish path.

Reading/updating an artifact a session just created is core functionality, so it should work out of the box — ideally by enabling the session-gateway artifact-read path for Cowork sessions (no allowlist needed), or by allowing egress to *.frame.claudeusercontent.com for the Cowork cloud_default environment by default. Users should not have to touch an environment network setting — especially one (the Claude Code web "Allowed domains" control) that doesn't even apply to the environment Cowork runs in.

Error Messages/Logs

Artifact action:"read" — and a normal (non-forced) publish, which reads the live version first — on an artifact this account owns returns:

  this environment's network allowlist blocks <id>.frame.claudeusercontent.com, and the session
  gateway could not serve the read either (artifact reads through the session gateway are not enabled
  for this session, or the artifact service no longer serves this version); your access to the artifact
  itself is fine (the permission check passed). To allow direct artifact reads here, add
  *.frame.claudeusercontent.com to the environment's allowed domains: environment settings → Code →
  Network access → Custom → Allowed domains.

Environment flags (from the Cowork container):
  CLAUDE_CODE_ENTRYPOINT=remote_cowork
  CLAUDE_CODE_REMOTE_ENVIRONMENT_TYPE=cloud_default
  CCR_EGRESS_GATEWAY_ENABLED=1
  CCR_UPSTREAM_PROXY_ENABLED=1
  IS_SANDBOX=1

Steps to Reproduce

1. In a Cowork session (personal/Pro plan), publish an HTML page with the Artifact tool; note the resulting claude.ai/code/artifact/<id> URL.
2. From the same session — or a later/scheduled Cowork session — call the Artifact tool's read action on that URL, or do a normal (non-forced) publish to the same URL (which reads the live version first).
3. Observe: the read is blocked (see Error Messages/Logs); for a normal publish, the republish is silently skipped, so the live page is never updated and no error is surfaced to the user.
4. (Optional) Add *.frame.claudeusercontent.com to a Claude Code web cloud environment's Allowed domains, then retry from a fresh Cowork session — the read still fails, because that setting doesn't apply to the cloud_default environment Cowork runs in.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.241

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Note on the CLI-oriented fields above: this is a Claude Cowork session, not the terminal CLI, so a few fields don't map cleanly:

• No terminal/shell exists — "Terminal.app" is just a placeholder to satisfy the required field.
• The failure occurs in the Cowork cloud VM (Ubuntu Linux, x86_64), not on the client. "macOS" is the machine I drive Cowork from, not where the bug runs.
• "Claude Code Version 2.1.241" is the engine version reported inside the Cowork cloud session (CLAUDE_CODE_ENTRYPOINT=remote_cowork, CLAUDE_CODE_REMOTE_ENVIRONMENT_TYPE=cloud_default, runner staging-8468f0367).

This is an infrastructure-side bug (network egress + the artifact-read path for the Cowork cloud_default environment) and is independent of client OS, terminal, or model.