[BUG] Live artifact connector permission prompt never appears after remote update_artifact (Cowork)

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?

A Cowork live artifact that is persisted and updated remotely (via the create_artifact / update_artifact MCP tools, called from a Claude cloud/agent session rather than authored once directly in the desktop app) never receives the connector permission prompt the documentation describes, even on genuine first interaction after an update.

Setup:

• Artifact created with create_artifact, then updated multiple times with update_artifact, from a cloud agent session (not edited by hand in the desktop app).
• Two connectors are already connected at the account level (confirmed via ListConnectors, both show status "connected"): Microsoft 365 (installedServerId 70725a95-4989-4f86-a771-a8a31fb7318b) and Atlassian Rovo (installedServerId 136bdb94-6f34-45d7-889c-c500b8e6ab66).
• The artifact's own JS calls window.cowork.callMcpTool("mcp__70725a95-4989-4f86-a771-a8a31fb7318b__outlook_calendar_search", {...}), using the correct tool-id convention (mcp__<installedServerId>__<toolName>), confirmed correct by cross-checking against a different, working call elsewhere in the same artifact using the same convention.

What happens:

• The call always rejects with the error shown below.
• No Allow/Deny permission dialog ever appears in the desktop app, tested at two distinct moments on the same device, with the user watching throughout:

1. Immediately after an update_artifact push (in case the prompt fires on the update itself).
2. On genuine first interaction with the connector-using feature (opening the artifact's own "New meeting" panel for the first time after the update), which is the moment the docs say the prompt should appear.

• Both tests were repeated on separate occasions with the same result: no prompt, connector call still fails.

Relevant tool/doc text reviewed:

• The create_artifact / update_artifact MCP tool descriptions state: "Remote-created artifacts start with no connector grants" and "A remote update clears the artifact's connector grants".
• Anthropic support documentation states live artifacts "can only use the connectors you approved during creation or update... you'll be prompted to approve access on first interaction. Your preferences persist for subsequent uses of that artifact."
• Per that documentation a permission prompt should have appeared on first interaction after the update. It never did, for either connector, across repeated tests.

What Should Happen?

On first genuine interaction with a live artifact feature that calls a connector tool (after the artifact's connector grants were cleared by a remote update_artifact), the desktop app should show an Allow/Deny permission prompt for that connector, per the documented behavior. Once approved, the connector call should succeed and the grant should persist for later interactions with that artifact.

If remotely-updated live artifacts are not currently supported for connector use at all, the callMcpTool call should fail with a clear, actionable error (for example "this artifact has no connector grants, re-open it in the desktop app to grant access") rather than the generic "Tool ... is not in this artifact" message, so a developer can distinguish a missing permission grant from a wrong tool id.

Error Messages/Logs

Tool "mcp__70725a95-4989-4f86-a771-a8a31fb7318b__outlook_calendar_search" is not in this artifact

Connectors involved (both showing status "connected" at account level via ListConnectors):
- Microsoft 365, installedServerId 70725a95-4989-4f86-a771-a8a31fb7318b
- Atlassian Rovo, installedServerId 136bdb94-6f34-45d7-889c-c500b8e6ab66

Same "not in this artifact" style failure occurs for the Atlassian connector tools called from the same artifact.

Steps to Reproduce

1. From a Claude cloud/agent session (Cowork), create a live artifact with the create_artifact MCP tool, then push at least one update with update_artifact. The artifact's JS calls a connector tool via window.cowork.callMcpTool(...) using a tool id built as mcp__<installedServerId>__<toolName> (installedServerId confirmed correct via ListConnectors, and confirmed correct by a second, working call elsewhere in the same artifact using the same convention).
2. Confirm the relevant connector (in our case Microsoft 365 and separately Atlassian Rovo) shows status "connected" at the account level.
3. Open the desktop app and open the persisted live artifact from the sidebar/artifact gallery.
4. Interact with the part of the artifact that triggers the connector call for the first time since the last update_artifact push (in our case, opening a "New meeting" panel that searches the calendar).
5. Observe: no Allow/Deny connector permission dialog appears at any point, either immediately after the update_artifact push or at this genuine first interaction.
6. The callMcpTool call rejects with: Tool "mcp__70725a95-4989-4f86-a771-a8a31fb7318b__outlook_calendar_search" is not in this artifact.
7. Repeated on a separate day/session with the same artifact and the same result: still no prompt, still the same error.

Expected per documentation: a permission prompt should appear on first interaction after an update, since "a remote update clears the artifact's connector grants".

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A - not the CLI. This is the Cowork desktop app's live artifact feature; the artifact is created/updated via the create_artifact and update_artifact MCP tools from a Claude cloud/agent session.

Platform

Other

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Note on fields above: this template is written for the CLI, so "Claude Code Version", "Platform", "Operating System" and "Terminal/Shell" don't map cleanly onto this report. This bug is in the Cowork desktop app's live artifact + connector permission system, reached via the create_artifact/update_artifact MCP tools rather than the claude CLI. Operating System and Terminal/Shell were left at their form defaults since they are not relevant to reproducing this bug (no terminal is involved at all, the whole reproduction happens inside the desktop app's artifact sidebar).

Also relevant: this is not a wrong-tool-id bug. The same tool-id convention (mcp__<installedServerId>__<toolName>) is used successfully elsewhere in the same artifact for a different connector operation, so the id format itself is confirmed correct; the only thing missing is the permission grant/prompt for this artifact after it was updated remotely.