[BUG] Cowork Live Artifacts created since ~2026-07-28 get an empty mcp_tools allowlist — connector-backed artifacts can no longer be created

Status Closed — duplicate
Maintainer reply None cached
Activity 1 comment · opened Aug 5, 2026 · closed Aug 15, 2026

Summary

Since a build between 2026-07-28 and 2026-08-05, newly created Cowork Live Artifacts are given an empty connector allowlist, so any artifact that fetches its own data via window.cowork.callMcpTool renders and then fails every call:

Tool "mcp__<connector-uuid>__<tool>" is not in this artifact's mcp_tools allowlist.

Artifacts created on or before 2026-07-28 still work today, which is what makes this a regression rather than a missing feature.

Environment

  • Claude Desktop for Windows 1.25927.0 (003700) (current at time of writing)
  • Cowork, desktop app
  • A custom org-level remote MCP connector, plus the built-in Salesforce connector
  • Artifact is a self-fetching HTML dashboard (calls one read-only MCP tool on load and on Refresh)

Evidence

Claude Desktop records each artifact's allowlist in
%APPDATA%/Claude/local-agent-mode-sessions/<install>/<org>/artifacts.json, as an mcpTools array.

| artifact created | mcpTools | artifact works? |
|---|---|---|
| 2026-06-24 | 2 UUID-form tool ids | yes |
| 2026-07-13 | 2 UUID-form tool ids | yes |
| 2026-07-16 | 2 UUID-form tool ids | yes |
| 2026-07-28 | 2 UUID-form tool ids | yes — still fetches and refreshes today |
| 2026-08-05 (×6) | [] | no |

Manually writing the same two UUID-form ids into a new artifact's mcpTools, then reopening it, makes it work immediately. So the runtime, the bridge and the relay are all fine — only the value written at creation is wrong.

update_artifact also writes an empty array: re-emitting an artifact wipes a previously working allowlist.

There is no supported way to grant an artifact

  • The artifact-creation tool exposes {id, file_uuid, description} — no mcp_tools/connectors/permissions parameter. (An earlier create_artifact accepted an mcp_tools allowlist.)
  • The artifact's menu offers only Unpin / Download as PDF / Delete.
  • No approval prompt appears at creation, on first open, or on Refresh.
  • window.cowork exposes only callMcpTool, askClaude, runScheduledTask — no grant/permission method, so the artifact cannot request access at runtime either.

Also ruled out

  • Declaring mcpTools / mcpServerNames in the artifact HTML — four syntaxes tried (<meta> comma-separated, <meta> JSON array, <script type="application/vnd.ant.artifact-metadata">, <script id="mcp-metadata" type="application/json">); all ignored, no prompt.
  • Naming the connector explicitly in the request that creates the artifact.
  • A brand-new artifact id vs. reusing an existing one (both get []).
  • Settings → Capabilities → Tool access mode, both settings.
  • Updating to the latest build (already on it; it contains the 2026-07-07 "MCP connectors in artifacts being silently dropped" fix).

Second, related problem: which id form the runtime accepts

The runtime accepts only the UUID form mcp__<connector-uuid>__<tool>. The connector-name form is rejected even when the allowlist is populated — verified with a controlled pair of artifacts holding identical allowlists:

  • boot config using mcp__<uuid>__<tool> → renders live
  • boot config using mcp__<connector-name>__<tool> → rejected

But the model authoring the artifact only ever sees the name form in its own tool catalog (cf. #47614), so it has no way to write a working id without external knowledge. Even after the allowlist bug is fixed, an artifact authored from the model's own catalog will still fail.

Expected

A newly created Live Artifact is granted the connectors it needs (or the user is prompted to approve them, as the help centre describes: "Live artifacts can only use the connectors you approved during creation or update").

Actual

mcpTools: [] at creation and on update, no approval path anywhere in the product, and the only workaround is editing local application data by hand.

Impact

Any Live Artifact that pulls from a connector — the headline use case for the feature — cannot be created at all right now. Existing ones keep working, so this is easy to miss until you build a new one.

View original on GitHub ↗

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