[BUG] Cowork Live Artifacts: `mcp_tools` allowlist is never populated for any connector on some accounts — every runtime `callMcpTool` rejected

Summary

On an affected account, every Live Artifact created in Claude Cowork (desktop) has an empty mcp_tools allowlist: any runtime window.cowork.callMcpTool(...) call is rejected with

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

This happens for every connector (verified with two: a custom HTTP MCP connector and the first-party HubSpot connector), on every artifact-creation path (chat-side create_artifact and the Artifacts-view "new artifact" flow), regardless of the connector's server-id shape (name-shaped and UUID-shaped both observed and both rejected), and on builds before and after applying the pending desktop update from v1.24012.1.

Per the support doc ("Live artifacts can only use the connectors you approved during creation or update"), the allowlist should be populated from session-approved connectors at create/update time. On the affected account it never is. A colleague's account in an org workspace creates working artifacts (live data fetches succeed) from the same skill/template the same day — so the feature works on some accounts and not others.

Environment

Affected account:

• Claude Desktop / Cowork, macOS; observed on v1.24012.1 AND after applying the pending update (current build)
• Personal Max plan workspace
• Connectors: custom HTTP MCP connector (self-added via claude.ai Settings → Connectors), first-party HubSpot connector — both Connected, both callable in-chat by the model in the same sessions that created the artifacts

Working reference account (colleague, same day, same artifact templates):

• Org workspace, org-provisioned connector (not self-added)
• Current build (updates daily; re-verified minutes after an update)
• Standing tool approvals in place; artifacts fetch live data with no Allow/Deny prompt on load

The observable difference is personal-Max workspace + self-added custom connector (affected) vs org workspace + org-provisioned connector (working). We cannot distinguish from outside which of those factors gates allowlist population.

Minimal reproduction

1. In a Cowork chat where a connector is connected and in active use (the model can call its tools successfully in-chat), have the model create an artifact whose page JS calls, on open:

window.cowork.callMcpTool('mcp__<server-id>__<any read tool>', {...})
with the server id detected from the model's own live tool list, and render the result or error to the page.

1. Open the artifact from the Artifacts gallery (the window.cowork bridge is present there; note it is NOT present in the chat pane's inline HTML preview, where the same page reports window.cowork.callMcpTool is not a function (bridge not present)).
2. The call returns isError: true with Tool "..." is not in this artifact's mcp_tools allowlist.

Observed matrix on the affected account (all fail identically):

| Variable | Values tried |
|---|---|
| Creation path | chat create_artifact / update_artifact; Artifacts-view "new artifact" flow |
| Connector | custom HTTP MCP connector; first-party HubSpot connector |
| Server-id shape | name-shaped (<Name>_<Name> and HubSpot); UUID-shaped (0119ab8f-…) |
| Session state | connector merely connected; connector actively used by the model in the same session immediately before create/update; artifacts deleted + app restarted + fresh deploy |
| App build | v1.24012.1; after applying the pending update |

Additional observation: the same connector surfaces with a different server-id segment in different sessions (name-shaped in some, UUID in others), so artifacts must re-detect the id per session — incidental, but it means the allowlist cannot be keyed to a stable id from the artifact author's perspective.

Expected

Artifacts created/updated in a session with an approved, in-use connector should have that connector's tools in their mcp_tools allowlist (per the Live Artifacts support article), or the UI should expose some way to grant a connector to an artifact. No grant UI exists on the affected account ("…" artifact menu has no permissions entry; no Allow/Deny prompt ever fires — cf. #57398 where a prompt does appear for other users).

Impact

Live Artifacts that fetch data at runtime are entirely unusable on affected accounts; every artifact fails on load with the allowlist error. Because the error is per-artifact and mentions no remedy, users reasonably conclude the artifact or its skill is broken. (We burned a full investigation on exactly that before isolating it to the account.)

Possibly related

• #57398 (artifact connector calls trigger one-shot Allow/Deny with no "Always allow") — on the affected account no prompt fires at all
• #55788 (Live Artifacts relay rejects non-UUID server names for local stdio) — different layer (relay 400 vs allowlist rejection), but same theme of artifact-path connector handling diverging from chat-path