[BUG] Desktop Extension MCP servers not passed to Cowork VM despite being enabled in session config

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/20377
2. https://github.com/anthropics/claude-code/issues/23424
3. https://github.com/anthropics/claude-code/issues/21440

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Those are related issues, but it seems they still persist or were introduced again. Here are some additional logs:

mcp.log
session-enabledMcpTools.json
cowork-vm-node-spawn.log
mcp-info.json

I believe I'm dealing with a related issue on Windows 11.

Installed Metabase MCP from the Claude extension library and it works just fine in Claude Chat, but I'm getting the error:
Missing user:mcp_servers scope and the current Cowork session only has user:inference scope.

Version: Claude 1.1.3363 (ee4247) 2026-02-17T15:55:21.000Z

After the recent update to Claude 1.1.4328 (d8e391) 2026-02-25T17:04:36.000Z , the build in chrome and newly added scheduled tasks are working within cowork, but custom node based local one still don't work within cowork.

The custom one listed above, so context7 and Control your Mac seem not to be passed / bridged into the cowork VM.

MCP Server | Status | Notes
-- | -- | --
Claude in Chrome | ✅ Working | Full tool access — tabs, navigation, screenshots, etc.
Filesystem | ✅ Working | Can mount directories and read/write files via mcp__cowork__ tools
Context7 | ❌ No tools exposed | Not available in Cowork
Control your Mac | ❌ No tools exposed | Not available in Cowork

ey @Klizzy,

I’m currently working on a Unity server MCP. It’s been working fine on my end (it’s actually been working since I started building it about four days ago). It was originally set up in Node, but I migrated it to MCPB following your latest message.

Unfortunately, I can’t get it to work for the rest of my team. Claude doesn’t detect it on their side and it doesn’t appear in the list of available connectors. However, on my end, it shows up correctly under Extensions → Developer.

Do you have any idea what might be causing this discrepancy?

Hello @francoios ,

was your MCP server running locally successfully within a cowork session, or only inside regular claude desktop chats- and code?

Remote MCP servers seems to work for some users, based on some related GH issues comments.

Actually i found out the issue with most of the MCP that weren't working.

It's related to maximum amount of tools, which is approx 40 within an MCP, so if you experience the same issue, it's mostly because of that.

Implementing a Proxy + lazy loading fix the thing !

Actually i found out the issue with most of the MCP that weren't working. It's related to maximum amount of tools, which is approx 40 within an MCP, so if you experience the same issue, it's mostly because of that. Implementing a Proxy + lazy loading fix the thing !

@francoios

That's nice to hear and good to know. In my case the total tool amount is ~6, so it seam that is related to something else - at least for my case.

I'm running into this on Claude Desktop on MacOS (Claude 1.1.5368 (d12d02) 2026-03-05T17:29:33.000Z) and a bunch of the stuff I want to do requires mcps :-(

After the session starts -- I can say "no really the <mcp server> is installed and running" and it's like "oh! you're right".

This obv doesn't work for scheduled tasks to behave properly though when those tasks rely on the mcp. I've even adjusted the prompts to add: IMPORTANT: The <mcp server> is installed, use it.

Following up on this ticket. I've done additional debugging and can confirm the issue is not configuration-related.
What's verified on my machine:

Tableau extension (ant.dir.gh.tableau.tableau-mcp v1.13.10) is correctly installed in ~/Library/Application Support/Claude/extensions-installations.json
Extension settings file exists at Claude Extensions Settings/ant.dir.gh.tableau.tableau-mcp.json with isEnabled: true and valid PAT credentials
Tableau works correctly in Claude Desktop chat using this same extension
A colleague with an identical setup (same extension version, same config structure, same org) has Tableau working in Cowork

The problem:
Cowork does not surface the Tableau extension as an available tool despite the extension being properly installed and enabled. The Cowork connector registry returns no Tableau entry. This appears to be instance-specific, not org-wide.
Likely root cause:
This matches GitHub issues #28695 and #26259, where the Cowork OAuth token only includes user:inference but never requests user:mcp_servers, preventing extensions from loading in Cowork. Re-authentication does not resolve it because the re-auth flow also omits the required scope.
Already tried (no effect):

Uninstalling and reinstalling the Tableau extension
Generating a new PAT and reconfiguring
Restarting Claude Desktop

Is there a timeline for the fix?

Adding evidence of intermittent behavior on the same machine, same user, no config changes between sessions:

Three consecutive Cowork sessions on macOS (Claude 1.1.7714):

• 15:41 bold-pensive-bell — "App Framework" present in --mcp-config ✅
• 16:10 wonderful-stoic-johnson — "App Framework" missing from --mcp-config ❌
• 16:13 jolly-tender-lamport — "App Framework" back in --mcp-config ✅

Also reproduces on Windows — most recent spawn had the extension missing from config.

mcp-server-App Framework.log confirms the server starts, completes initialize, and returns all tools via tools/list correctly every single time on both platforms. The issue is entirely in the orchestrator's spawn config generation — it's a race condition that non-deterministically omits extensions.

Additional observations:

• This is an org-wide extension installed via .mcpb upload
• Works 100% reliably in Claude Chat (claude.ai web) — only Cowork is affected
• CMD+R (new session) sometimes resolves it
• Admins seemed to get it more reliably than non-admins, though the intermittent nature makes that hard to confirm
• Re-uploading the extension (new version) may have increased the frequency of drops

More detail here: https://github.com/anthropics/claude-code/issues/36405

Adding a data point that narrows this down to a timing/race condition rather than extensions being blanket-excluded.

I'm seeing the same desktop extension ("Google Docs & Sheets", custom .mcpb) appear intermittently in --mcp-config — present in some sessions, absent in others, within the same app lifecycle. Other internal extensions exhibit the same behaviour.

From cowork_vm_node.log on 2026-03-25 (macOS ARM, VM bundle fb30784, SDK v2.1.78):

New session spawned at 08:30:19 — Google Docs & Sheets missing from mcpServers:
[Spawn:create] name=blissful-gallant-newton
--mcp-config {"mcpServers":{..., "plugins":{"type":"sdk","name":"plugins"}, "":{"type":"sdk","name":""},...}}

Same session resumed at 08:36:56 — Google Docs & Sheets now present, along with another extension that was also missing at initial spawn:
[Spawn:create] name=blissful-gallant-newton --resume 2ceab011-...
--mcp-config {"mcpServers":{..., "Google Docs & Sheets":{"type":"sdk","name":"Google Docs & Sheets"}, "":{"type":"sdk","name":""}, "":{"type":"sdk","name":""},...}}

App quit at 08:41:50, VM rebooted. All subsequent new sessions are missing Google Docs & Sheets again, but a new UUID-identified server (f5438224-...) appears that wasn't present before the restart:
[Spawn:create] name=eloquent-peaceful-brahmagupta
--mcp-config {"mcpServers":{"f5438224-...":{"type":"sdk","name":"f5438224-..."}, ..., "":{"type":"sdk","name":""},...}}

So the mcpServers config is being snapshotted at spawn time before all extensions have finished registering. Resumed sessions pick up the late registrations because the extensions have completed their handshake by then. After a VM restart the same extension can
reappear under a UUID rather than its display name, which suggests registration state isn't persisted across VM lifecycles.

Aligns with @freeformz's finding that manually telling Claude
the MCP exists works mid-session — the server is running on the host, it's just absent from the spawn config.

Adding another affected extension: iMessage MCP (ant.dir.ant.anthropic.imessage) is also not exposed to Cowork sessions despite being enabled in settings.

All 4 tools (Search Contacts, Read iMessages, Get Unread iMessages, Send iMessage) are toggled on in the Cowork settings UI, but none appear in the session's deferred tools list. No error banner is shown — the failure is completely silent.

Other MCP extensions (Gmail, Slack, Google Calendar, ClickUp, Chrome, PagerDuty, Make.com, AWS) all connect fine in the same session.

Environment: macOS Apple Silicon, Claude Desktop latest version (March 29, 2026), Full Disk Access granted to Claude.app. iMessage extension v0.1.11 (with the FDA pre-check fix from #21737).

Filed as #40703, closing that as duplicate of this issue.

Following up on this as I'm still hitting the same issue on macOS 15.7.1 (24G231), build 2.1.87, and have dug into the session logs which might help narrow things down.

Key finding: the behaviour is intermittent, not a hard omission

After testing across multiple sessions with identical config, some local Desktop Extension connectors come through fine while others are missing — and which ones are absent varies between sessions. A session restart sometimes resolves it. This points to a race condition rather than a filtering bug.

Importantly, it's not all local connectors that fail — in the session below, Fathom (10 tools) and Google Docs & Sheets (67 tools) both came through correctly as local: type connectors, while InternalAPIConnector (6 tools) and ComplianceTool (4 tools) did not. Same session, same config.

Evidence from session logs

enabledMcpTools in local_<session-id>.json correctly records all connectors as enabled:

"local:Fathom:fathom_list_meetings": true,
"local:Fathom:fathom_get_transcript": true,
"local:Google Docs & Sheets:readSpreadsheet": true,
"local:Google Docs & Sheets:writeSpreadsheet": true,
"local:InternalAPIConnector:get-user-settings": true,
"local:InternalAPIConnector:search-records": true,
"local:InternalAPIConnector:get-revenue-data": true,
"local:InternalAPIConnector:get-products": true,
"local:InternalAPIConnector:get-settings": true,
"local:InternalAPIConnector:get-access-permissions": true,
"local:ComplianceTool:tests": true,
"local:ComplianceTool:people": true,
"local:ComplianceTool:controls": true,
"local:ComplianceTool:documents": true

But remoteMcpServersConfig — the actual config forwarded to the VM — only contains these 10 servers:

Atlassian, Customer.io, Figma, Gmail, Google Calendar,
Granola, Mermaid Chart, Slack, KnowledgeBase, Google Drive

InternalAPIConnector and ComplianceTool are absent entirely. Fathom and Google Docs & Sheets are also absent from remoteMcpServersConfig but are available in the session — so they must be reaching the VM via a different path, which makes the inconsistency harder to explain.

Hypothesis

Whatever process populates remoteMcpServersConfig is reading local server state at a point where some have finished initialising and some haven't. The ones that miss the window are silently dropped with no error. The fact that different connectors fail across different sessions — with no config change — is consistent with a timing/ordering issue during startup.

Happy to share the full sanitised session JSON if it helps.

--

This is essentially blocking our entire organisation from properly using cowork as we depend on a lot of internal desktop extensions. Some acknowledgement from the core team would be appreciated, this thread is looking stale.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.