[BUG] Cowork Live Artifacts created since ~2026-07-28 get an empty mcp_tools allowlist — connector-backed artifacts can no longer be created
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}— nomcp_tools/connectors/permissions parameter. (An earliercreate_artifactaccepted anmcp_toolsallowlist.) - The artifact's
⋯menu offers only Unpin / Download as PDF / Delete. - No approval prompt appears at creation, on first open, or on Refresh.
window.coworkexposes onlycallMcpTool,askClaude,runScheduledTask— no grant/permission method, so the artifact cannot request access at runtime either.
Also ruled out
- Declaring
mcpTools/mcpServerNamesin 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗