[BUG] Claude cowork MCP Issue continues

Open 💬 38 comments Opened Feb 21, 2026 by EricDetermined

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?

<html><head></head><body><h1>[BUG] Cowork: mcp-registry and Claude in Chrome MCP servers fail to connect — all MCP tools unavailable despite correct configuration</h1>
<h2>Preflight Checklist</h2>
<ul>
<li>[x] I have searched existing issues and this hasn't been reported yet</li>
<li>[x] This is a single bug report (please file separate reports for different bugs)</li>
<li>[x] I am using the latest version of Claude Code</li>
</ul>
<h2>What's Wrong?</h2>
<p>After updating Claude Desktop to the latest version (post-1.1.3189), Cowork cannot connect to the <code>mcp-registry</code> or <code>Claude in Chrome</code> MCP servers. Two red error banners appear at the top of every new Cowork session:</p>
<ul>
<li>⚠️ <strong>Could not connect to MCP server mcp-registry</strong></li>
<li>⚠️ <strong>Could not connect to MCP server Claude in Chrome</strong></li>
</ul>
<p>Because <code>mcp-registry</code> is the foundational service that manages all MCP tool discovery, its failure means <strong>Cowork is completely blind to all MCP tools</strong>, even those that technically launch at the server level. This makes browser automation through Cowork entirely non-functional.</p>
<p><strong>This was working perfectly until approximately February 13-14, 2026</strong>, coinciding with the Claude Desktop auto-update to version 1.1.3189 (build 2026-02-14T00:09:46.000Z). The issue persists on the latest build (updated February 21, 2026).</p>
<h2>Environment</h2>
<ul>
<li><strong>OS:</strong> macOS (Apple Silicon)</li>
<li><strong>Claude Desktop:</strong> Latest version (updated Feb 21, 2026, post-1.1.3189)</li>
<li><strong>Chrome Extension:</strong> Claude in Chrome — reinstalled fresh</li>
<li><strong>Chrome:</strong> Latest stable (updated Feb 21, 2026)</li>
<li><strong>Desktop Extension:</strong> Control Chrome (chrome-control) — installed and enabled</li>
<li><strong>Account:</strong> Max Plan</li>
</ul>
<h2>Steps to Reproduce</h2>
<ol>
<li>Update Claude Desktop to the latest version</li>
<li>Update Chrome to the latest version</li>
<li>Reinstall the Claude in Chrome extension from Chrome Web Store</li>
<li>Verify all settings are correct (see Configuration Verification below)</li>
<li>Switch to Cowork mode</li>
<li>Observe two red error banners: "Could not connect to MCP server mcp-registry" and "Could not connect to MCP server Claude in Chrome"</li>
<li>Ask Cowork to use Chrome browser tools — it cannot find any MCP tools</li>
</ol>
<h2>What Should Happen</h2>
<ul>
<li><code>mcp-registry</code> should connect successfully on Cowork session start</li>
<li><code>Claude in Chrome</code> MCP server should connect successfully</li>
<li>All 10 Control Chrome tools (open_url, get_current_tab, list_tabs, close_tab, switch_to_tab, reload_tab, go_back, go_forward, execute_javascript, get_page_content) should be available to Cowork</li>
<li>Cowork should be able to automate Chrome browser actions</li>
</ul>
<h2>Configuration Verification — Everything Is Correct</h2>
<p>All settings have been verified as properly configured:</p>
<h3>Settings > Capabilities</h3>
<ul>
<li>✅ Artifacts: ON</li>
<li>✅ AI-powered artifacts: ON</li>
<li>✅ Cloud code execution and file creation: ON</li>
<li>✅ Allow network egress: ON</li>
<li>✅ Domain allowlist: All domains</li>
</ul>
<h3>Settings > Extensions</h3>
<ul>
<li>✅ Control Chrome: Installed on computer</li>
<li>✅ chrome-control extension detail shows: Enabled, 10 tools listed, "All requirements met" ✓</li>
</ul>
<h3>Settings > Connectors</h3>
<ul>
<li>✅ Google Drive: Connected</li>
<li>✅ Gmail: Connected</li>
<li>✅ GitHub: Connected</li>
<li>✅ Claude in Chrome: INCLUDED (with Configure button)</li>
<li>✅ Control Chrome: DESKTOP (with Configure button)</li>
</ul>
<h2>Log Analysis — Key Finding</h2>
<p>The <code>main.log</code> reveals the exact failure point. Here is the relevant log output from a Cowork session started at 12:13:52 on Feb 21, 2026:</p>
<pre><code>2026-02-21 12:13:52 [info] [Chrome MCP] Bridge feature flag: chrome_ext_bridge_enabled_desktop=true, IS_NEST_BUILD=false
2026-02-21 12:13:52 [info] [Claude in Chrome] MCP server registered
2026-02-21 12:13:54 [info] MCP Server connection requested for: Control Chrome
2026-02-21 12:13:54 [info] Launching MCP Server: Control Chrome
2026-02-21 12:13:54 [info] MCP Server connection requested for: mcp-registry
2026-02-21 12:13:54 [info] MCP Server connection requested for: Claude in Chrome
2026-02-21 12:13:54 [info] Using UtilityProcess for extension Control Chrome: appConfig.isUsingBuiltInNodeForMcp is true and built-in node is compatible
2026-02-21 12:13:54 [info] [UtilityProcess stderr] Chrome Control MCP server running on stdio
mcp_config: [Object]
2026-02-21 12:14:08 [info] MCP Server connection requested for: mcp-registry
2026-02-21 12:14:08 [info] MCP Server connection requested for: Claude in Chrome
</code></pre>
<h3>What the logs show:</h3>

<p><strong>The critical difference:</strong> <code>Control Chrome</code> gets a <code>Launching MCP Server</code> log entry and successfully starts via UtilityProcess. <code>mcp-registry</code> and <code>Claude in Chrome</code> get stuck at "connection requested" — they retry multiple times (12:09:01, 12:09:41, 12:09:49 in the first session; 12:13:54, 12:14:08 in the second) but <strong>never progress to the "Launching" stage</strong>. They silently time out with no error message in the logs.</p>
<h3>Additional log details:</h3>
<ul>
<li>Native host manifests are installed correctly for all browsers (Chrome, Brave, Edge, Chromium, Arc, Vivaldi, Opera)</li>
<li>Chrome extension <code>fcoeoabgfenejglbffodgkkbkcdhcgfn</code> is detected: <code>[Chrome Extension MCP] Extension fcoeoabgfenejglbffodgkkbkcdhcgfn found in: Chrome</code></li>
<li>Bridge feature flag is enabled: <code>chrome_ext_bridge_enabled_desktop=true</code></li>
<li>No Claude Code CLI is installed (no native host config conflict)</li>
</ul>
<h2>Impact</h2>
<ul>
<li><strong>Complete loss of browser automation in Cowork</strong> — the primary use case for my workflows</li>
<li><strong>All MCP tools are invisible to Cowork</strong> because <code>mcp-registry</code> failure prevents tool discovery</li>
<li>Even the working <code>Control Chrome</code> extension cannot be used because Cowork cannot discover its tools through the broken registry</li>
<li><strong>Chat mode</strong> in the same Claude Desktop app does NOT have this issue — this is Cowork-specific</li>
</ul>
<h2>Workarounds Attempted (None Successful)</h2>
<ul>
<li>✅ Updated Claude Desktop to latest version</li>
<li>✅ Updated Chrome to latest version</li>
<li>✅ Reinstalled Claude in Chrome extension</li>
<li>✅ Verified all settings (Capabilities, Extensions, Connectors)</li>
<li>✅ Full clean restart: quit both apps, cleared <code>/tmp/claude-mcp-browser-bridge-$USER</code>, relaunched Chrome first, then Claude Desktop</li>
<li>✅ Disabled Claude Code's native host config (<code>com.anthropic.claude_code_browser_extension.json</code>)</li>
<li>✅ Started multiple new Cowork sessions</li>
<li>✅ Tried explicitly asking Cowork to use "Control Chrome" tools — Cowork says it can't find them (because mcp-registry is down)</li>
</ul>
<h2>Related Issues</h2>
<ul>
<li>#25706 — MCP "searched available tools" regression in 1.1.3189 (Feb 14)</li>
<li>#26094 — MCP parameter serialization broken in 1.1.3189 (Feb 16)</li>
<li>#26217 — Chrome extension MCP never connects despite registration (Feb 17)</li>
<li>#26305 — Chrome extension connection failure in Desktop app (Feb 17)</li>
<li>#25151 — Claude in Chrome fails to connect on macOS (Feb 12)</li>
</ul>
<p>All of these trace back to the 1.1.3189 update (build 2026-02-14). None have received an official fix or response from Anthropic as of Feb 21, 2026.</p>
<h2>Claude Model</h2>
<p>Opus 4.6 / Sonnet 4.5 (both affected)</p>
<h2>Is this a regression?</h2>
<p><strong>Yes</strong> — Chrome MCP browser automation was working perfectly in Cowork prior to approximately February 13-14, 2026.</p>
<h2>Last Working Version</h2>
<p>Pre-1.1.3189 (approximately 1.1.2998 or earlier)</p>
<h2>Platform</h2>
<p>macOS (Apple Silicon)</p>
<h2>Additional Information</h2>
<p>The root issue appears to be that the Cowork VM's MCP client can launch <strong>local desktop extensions</strong> (like Control Chrome via UtilityProcess) but <strong>cannot establish connections to bridge-type MCP servers</strong> (<code>mcp-registry</code>, <code>Claude in Chrome</code>). This suggests a regression in how the Cowork VM communicates with the host application's MCP bridge layer — possibly related to the VM socket/proxy configuration introduced or changed in the 1.1.3189 build.</p></body></html>

What Should Happen?

Error Messages/Logs

Steps to Reproduce

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Version 1.1.3963 (71a7ae)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

View original on GitHub ↗

38 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

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

gitfatsalty · 4 months ago

Seeing a milder form of this on v1.1.3963 (71a7ae) / Windows 11 Pro for Workstations / Razer Blade i7-8750H: the same mcp-registry and Claude in Chrome error banners appear when clicking the Cowork tab, but they recover within a few seconds rather than persisting.

From main.log, both servers are requested twice — once at Desktop startup and again ~6 seconds later specifically when Cowork is clicked:

2026-02-21 22:54:15 [info] MCP Server connection requested for: mcp-registry
2026-02-21 22:54:15 [info] MCP Server connection requested for: Claude in Chrome
...
2026-02-21 22:54:21 [info] MCP Server connection requested for: mcp-registry
2026-02-21 22:54:21 [info] MCP Server connection requested for: Claude in Chrome

The Cowork click triggers a fresh initialization of both servers, which briefly fails before the connections stabilize. This did not happen before the v1.1.3918 update — Cowork worked cleanly on the prior version with no MCP errors on tab click. It persists in v1.1.3963.

The transient recovery in v1.1.3963 vs. permanent failure in earlier builds suggests the fix in that version improved connection retry/timeout handling but didn't address the underlying race condition where the Cowork tab click triggers server reinitialization before the previous connection is fully torn down.

lpanda2 · 4 months ago

hitting this on macOS, Claude Desktop latest build (updated Feb 22). get the "Could not connect to MCP server mcp-registry" toast on every launch

what i've tried (none worked):

restarting cowork / full app restart (Cmd+Q)
disconnecting and reconnecting all connectors from the UI
clearing Cache, Code Cache, and blob_storage from ~/Library/Application Support/Claude/
claude_desktop_config.json has mcpServers: {} — confirming this isn't a user-configured MCP issue, it's the built-in registry

impact:

all cowork connectors (Slack, Linear, Notion, Google Calendar, Gmail, Google Drive, Granola) are completely non-functional. mcp-registry is the foundational service so when it fails, nothing works. cowork is unusable for any workflow that touches external tools

env: macOS, Claude Desktop (latest as of Feb 22, 2026)

would be helpful to know if there's a workaround to force sequential MCP server initialization, or if a hotfix is planned. this is blocking daily use of cowork

braidwalkers · 4 months ago

Experiencing this on February 21 and 22, 2026, right after an update to Claude Desktop app. Just updated evening of 2/22/26 and it's still broken. Same error messages: can't connect to mcp-registry and Claude in Chrome. Workflow requires local MCP access.

EricDetermined · 4 months ago

No problem supporting another ticket, but I want to make sure @claude use the full report for your fix so that we can see a resolution....

agochs · 4 months ago

I'm experiencing the exact same issue on a different hardware setup, confirming this is not machine-specific.
My Environment

Hardware: Mac Mini, Apple M4, 16GB RAM
OS: macOS 26.3.0 (Tahoe)
Claude Desktop: 1.1.3963 (71a7ae)
Chrome: Latest stable with Claude in Chrome extension (fcoeoabgfenejglbffodgkkbkcdhcgfn)
Account: Max Plan
No Claude Code CLI installed

Same Symptoms
Identical to what you described — two red error banners on every Cowork session:

"Could not connect to MCP server mcp-registry"
"Could not connect to MCP server Claude in Chrome"

Logs show the same pattern: MCP Server connection requested for: mcp-registry and Claude in Chrome repeat every ~3 seconds but never progress to "Launching."
Additional Debugging Findings
I did extensive debugging that adds some detail to your findings:

The Chrome native host binary launches successfully — it creates a Unix socket at /tmp/claude-mcp-browser-bridge-<username>/<pid>.sock and enters its message loop. The chrome-native-host.log confirms it's running and listening.
No client ever connects to that socket — the native host log shows the socket is created and listening, but no incoming connection ever arrives. This confirms the break is between the Cowork VM and the native host socket, not between the native host and Chrome.
The Cowork VM boots successfully — coworkd.log shows the VM starting, mounting shared directories, connecting via RPC, and configuring network. The VM itself is healthy.
The Chrome extension detects correctly — logs show [Chrome Extension MCP] Extension fcoeoabgfenejglbffodgkkbkcdhcgfn found in: Chrome and the bridge feature flag is enabled (chrome_ext_bridge_enabled_desktop=true).
Native messaging host manifest is correctly configured — verified the JSON at ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json has the correct binary path and allowed origins matching the extension ID.
Reinstalling Claude Desktop did not fix it — fresh download and install, same result.

Summary
Every component works individually (Chrome extension, native host binary, Cowork VM) but the bridge connection between the VM and the native host socket never establishes. This aligns with your analysis that bridge-type MCP servers fail while local UtilityProcess extensions (like Control Chrome) work fine.
Adding my voice to request Anthropic investigate — this is blocking browser automation entirely for Cowork users on macOS.

Aztherion · 4 months ago

Experienced this on February 24th after an update to the Claude Desktop app. Same errors "Could not connect to MCP server mcp-registry" and "Could not connect to MCP server Claude in Chrome". Updated to version "Claude 1.1.4173 (12766c) 2026-02-24T15:04:14.000Z" on February 25th and the problem is resolved.

nicha16 · 4 months ago

<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Confirming this issue persists as of Feb 27, 2026, now tested across three Desktop + extension version pairs:</p>
<div class="overflow-x-auto w-full px-2 mb-6">
Desktop | Extension | Result
-- | -- | --
v1.1.3770 | v1.0.53 | ❌ Invalid token or user mismatch
v1.1.4498 | v1.0.56 | ❌ Identical error, same bridge UUID

</div>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Log from today (v1.1.4498):</p>
<div class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg"><div class="sticky opacity-0 group-hover/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"><button class="inline-flex
items-center
justify-center
relative
shrink-0
can-focus
select-none
disabled:pointer-events-none
disabled:opacity-50
disabled:shadow-none
disabled:drop-shadow-none border-transparent
transition
font-base
duration-300
ease-[cubic-bezier(0.165,0.85,0.45,1)] h-8 w-8 rounded-md active:scale-95 backdrop-blur-md Button_ghost__BUAoh" type="button" aria-label="Copy to clipboard" data-state="closed"><div class="relative"><div class="transition-all opacity-100 scale-100" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-100 scale-100" aria-hidden="true" style="flex-shrink: 0;"><path d="M12.5 3C13.3284 3 14 3.67157 14 4.5V6H15.5C16.3284 6 17 6.67157 17 7.5V15.5C17 16.3284 16.3284 17 15.5 17H7.5C6.67157 17 6 16.3284 6 15.5V14H4.5C3.67157 14 3 13.3284 3 12.5V4.5C3 3.67157 3.67157 3 4.5 3H12.5ZM14 12.5C14 13.3284 13.3284 14 12.5 14H7V15.5C7 15.7761 7.22386 16 7.5 16H15.5C15.7761 16 16 15.7761 16 15.5V7.5C16 7.22386 15.7761 7 15.5 7H14V12.5ZM4.5 4C4.22386 4 4 4.22386 4 4.5V12.5C4 12.7761 4.22386 13 4.5 13H12.5C12.7761 13 13 12.7761 13 12.5V4.5C13 4.22386 12.7761 4 12.5 4H4.5Z"></path></svg></div><div class="absolute inset-0 flex items-center justify-center"><div class="transition-all opacity-0 scale-50" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-0 scale-50" aria-hidden="true" style="flex-shrink: 0;"><path d="M15.1883 5.10908C15.3699 4.96398 15.6346 4.96153 15.8202 5.11592C16.0056 5.27067 16.0504 5.53125 15.9403 5.73605L15.8836 5.82003L8.38354 14.8202C8.29361 14.9279 8.16242 14.9925 8.02221 14.9989C7.88203 15.0051 7.74545 14.9526 7.64622 14.8534L4.14617 11.3533L4.08172 11.2752C3.95384 11.0811 3.97542 10.817 4.14617 10.6463C4.31693 10.4755 4.58105 10.4539 4.77509 10.5818L4.85321 10.6463L7.96556 13.7586L15.1161 5.1794L15.1883 5.10908Z"></path></svg></div></div></div></button></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;"><span><span>2026-02-27 14:48:02 [info] [Claude in Chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/5e216c8a-9c47-48cd-83a8-4b694c83c64d
</span></span><span>2026-02-27 14:48:02 [info] [Claude in Chrome] WebSocket connected, sending connect message
</span><span>2026-02-27 14:48:02 [warn] [Claude in Chrome] Bridge error: Invalid token or user mismatch</span></code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Same bridge UUID persists across all client-side wipes (12 troubleshooting steps exhausted). No Claude Code CLI installed. macOS Apple Silicon, Max plan, email magic link auth. Full details in my issue #27055. Anthropic support ticket filed (Conversation ID 215473175396590) — no response in 7 days.</p>

nicha16 · 4 months ago

✅ RESOLVED — Disconnect/Reconnect Cycle Fixes Bridge Auth for Claude in Chrome

After extensive debugging (12+ client-side steps, full local storage wipe, version updates), the fix turned out to be a 3-step disconnect/reconnect cycle performed in this exact order:

The Fix

Phase 1 — Disconnect:

Claude Desktop → Settings → Integrations → "Claude in Chrome" → Disconnect
Close Claude Desktop (Cmd+Q)
Chrome → chrome://extensions/ → Claude extension → Disconnect

Phase 2 — Restart:

Restart the computer

Phase 3 — Reconnect (this order matters):

Open Claude Desktop → Settings → Integrations → Reconnect "Claude in Chrome"
In Chrome, reconnect the extension
Start a Cowork task that requires Chrome → this triggers the bridge connection prompt

Key: Reconnection order matters — Desktop first, then extension, then let Cowork initiate the actual bridge handshake.

What Doesn't Work (Don't Do These)

Clearing cache, cookies, local storage — no effect
Reinstalling Desktop or extension — no effect
Deleting local-agent-mode-sessions/, vm_bundles/, Local Storage/ — destroys Cowork session history and does NOT fix the bridge (UUID is server-assigned, not locally stored)

Key Finding

The bridge UUID (5e216c8a-... in my case) is server-assigned. Even after wiping every local trace of it, the server returns the identical UUID on reconnection. The disconnect/reconnect cycle appears to force a fresh token handshake server-side without requiring engineering intervention.

Environment

macOS Apple Silicon
Desktop v1.1.4498, Chrome extension v1.0.56
Max plan, email magic link auth
No Claude Code CLI

Hope this helps others hitting this. cc @EricDetermined

ilaikim99 · 4 months ago

Hitting the 'Could not connect to MCP server mcp-registry' error in Cowork after a Desktop update? The issue is a stale bridge token that needs a specific disconnect/reconnect sequence to reset server-side — order matters. Covered the exact steps here: https://cacheoverflow.dev/blog/fRKe2ghM

DeanSingh · 4 months ago

Latest Claude Cowork fixed this everyone!

nicha16 · 4 months ago

No longer working again after the latest update. And doesn't seem like Anthropic bothers to even look at this thread or actively fixing the root cause.

ToniMahoni-PC · 4 months ago

Still broken on Windows (Desktop v1.1.5xxx) — Cowork + Claude in Chrome MCP never connects

Environment:

OS: Windows 11
Claude Desktop: latest (auto-updated)
Chrome Extension: Claude in Chrome v1.0.59
Plan: Pro/Max

What's happening:

Cowork cannot connect to Claude in Chrome MCP server. The connector is enabled in Settings → Connectors (blue toggle), it appears in the + menu in the Cowork chat and is toggled on — but every attempt to use browser tools fails with:

"No MCP tab groups found. Use createIfEmpty: true to create one."

The tool call panel shows tabs_context_mcp is attempted (2 TOOL-AUFRUFE visible), but the response is always {} / no connected tabs found.

Use case blocked:

I need Cowork to simultaneously read local project files AND control Chrome. This is exactly the scenario Cowork + Claude in Chrome is designed for. Currently completely non-functional.

Confirmed NOT a configuration issue:

✅ Extension installed and active (v1.0.59, enabled on all websites)
✅ Connector activated in Desktop App Settings → Connectors
✅ Connector enabled per-conversation via + menu
✅ Multiple full reboots attempted
✅ Chrome started after Desktop App — no difference
✅ No Chrome Canary installed (ruling out #31771)

This is cross-platform — same failure reported on macOS (#27492 original report). Not a Windows-specific issue.

Request:

Please provide either:

An official status update — is this actively being worked on?
A confirmed working workaround (previous "fixes" in comments received downvotes — they don't work)
An ETA for a fix — this has been broken since ~Feb 14, 2026 (v1.1.3189)

Related: #31864, #29057, #26305

benjaminTerminal · 3 months ago

Happening to me too on MacOS. Very unstable and unreliable connection to Chrome on desktop

still21 · 3 months ago

Confirming – still an issue on Mac.

nicha16 · 3 months ago

Still an issue for me. It's been a month with no word from Anthropic

gskornowicz · 3 months ago

Still an issue on Windows 11 and Claude 1.1.8359 (64248d) 2026-03-23T22:17:05.000Z

Necromancerjpeg · 3 months ago

Related: Same Cowork MCP regression affecting Filesystem server on Windows 11

Adding a Windows-side data point to this issue. I'm seeing the same class of Cowork VM bridge failure, but with the Filesystem MCP server rather than mcp-registry/Claude in Chrome.

Environment:

OS: Windows 11
Claude Desktop: latest (post-February 2026 update)
Node.js: v24.12.0 (installed at C:\Program Files\nodejs\node.exe)
MCP server: @modelcontextprotocol/server-filesystem (installed globally via npm)

Errors on Cowork launch:

"MCP Filesystem: Server disconnected"
"Failed to start workspace"
"Could not attach to MCP server Filesystem"

Config (claude_desktop_config.json):

{
  "mcpServers": {
    "filesystem": {
      "command": "C:\\Program Files\\nodejs\\node.exe",
      "args": [
        "C:\\Users\\Chris Duncanson-Hale\\AppData\\Roaming\\npm\\node_modules\\@modelcontextprotocol\\server-filesystem\\dist\\index.js",
        "C:\\Users\\Chris Duncanson-Hale"
      ]
    }
  }
}

Troubleshooting completed:

node -v returns v24.12.0; Get-Command node confirms path at C:\Program Files\nodejs\node.exe
Filesystem server installed globally; npm root -g confirms C:\Users\Chris Duncanson-Hale\AppData\Roaming\npm\node_modules
Server runs fine outside Cowork. Manual launch via PowerShell starts successfully and outputs "Secure MCP Filesystem Server running on stdio" with no errors
Config uses full absolute paths to node.exe and dist\index.js (bypassing npx entirely)
Fully quit and relaunched Claude Desktop after config changes — same errors persist

Additional context — concurrent user profile changes:

The errors appeared during a large-scale reorganisation of the filesystem MCP's target directory (C:\Users\Chris Duncanson-Hale). During the session, the following changes were made:

OneDrive deletion: Three legacy OneDrive directories were purged, along with the main OneDrive folder containing 157,152 cloud-only placeholder files (Windows "Files on Demand" stubs with attribute flag 0x400000). Approximately 2,024 real files (~4.75 GB) were extracted and sorted before deletion.

Shell folder registry corruption: After the OneDrive deletion, nine registry values under HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders and Shell Folders were still pointing to deleted OneDrive subdirectories (e.g., C:\Users\Chris Duncanson-Hale\OneDrive\Desktop, ...\OneDrive\Documents). This caused Windows Explorer "location is not available" errors. The affected entries included Desktop, Personal (Documents), My Pictures, My Music, My Video, and GUIDs {F42EE2D3-909F-4907-8871-4C22FC0BF756}, {0DDD015D-B06C-45D5-8C4C-F59713854639}, {24D89E24-2F19-4534-9DDE-6A6671FBB8FE}, {A0C69A99-21C8-4671-8703-7934162FCF1D}, and {35286A68-3C57-41A1-BBB1-0EAE73D76C95}. All were redirected back to standard %USERPROFILE%\... paths.

Root folder restructuring: ~1,800 files were moved into a new subdirectory structure, and two root-level folders (Creative Cloud Files, MicrosoftEdgeBackups) were removed.

Resolution: After correcting the nine broken shell folder registry entries and relaunching Claude Desktop, the filesystem MCP connected successfully and has remained stable. All MCP connections (Filesystem, Gmail, Google Calendar, Google Drive, Claude in Chrome) were subsequently verified as functional.

Assessment: The original report framed this as purely a Cowork VM bridge regression. While that may still be a factor, the evidence suggests a contributing (possibly primary) cause on the Windows side: broken shell folder resolution after OneDrive removal. The Cowork VM bridge may depend on Windows shell folder paths when resolving the MCP server's allowed directory, which would explain why the server worked fine when launched manually in PowerShell (which doesn't resolve shell folder GUIDs the same way) but failed within Cowork. If the bridge uses Windows API calls that traverse shell folder registry entries, a dangling reference to a deleted path could cause the server connection to hang or fail.

This may be worth investigating on the Anthropic side: does the Cowork VM bridge resolve filesystem MCP paths through the Windows shell folder API, or does it pass the raw string path? If the former, broken shell folder entries on the host OS would be a user-side root cause rather than a Cowork regression.

eyesWIDEopen12392 · 3 months ago

Adding my experience to this issue. Windows 11 Pro (upgraded from Home), fresh MSIX install via winget, CoworkVMService confirmed running, chrome-native-host process confirmed running, registry entry pointing to correct ChromeNativeHost JSON file. Cowork only shows tab closing and file upload tools — no Chrome browsing tools. Claude in Chrome connector panel shows 'Install' despite extension being active. Support ticket opened 3/22, no response yet. Debug logs submitted via Cowork interface.

Murat-A-A · 3 months ago

Adding our working solution — we have 18 MCP servers running in Cowork. Worked on the first try.

Two things most people miss:

SDK Bridge exists: MCPs in claude_desktop_config.json are auto-proxied into Cowork by Claude Desktop. They appear as "type": "sdk". This covers most stdio servers (Notion, Playwright, custom Node.js servers, etc.)

supergateway for the rest: supergateway converts any stdio MCP into an HTTP endpoint. Add it to .mcp.json as "type": "streamable-http". Works perfectly in Cowork since it's just an HTTP call.

Quick setup:

npm i -g supergateway pm2
supergateway --stdio "npx -y @your/mcp-server" --port 8001 --baseUrl /mcp
# Use pm2 for persistence

// .mcp.json
{ "mcpServers": { "name": { "type": "streamable-http", "url": "http://localhost:8001/mcp" } } }

Our stack: Notion, Outlook, Windows-MCP, PDF Tools, Excel, Playwright, Claude in Chrome (via SDK bridge) + alphabanana, mermaid, pandoc, antv-chart, un-markdown (via supergateway HTTP).

This is not a bug — it's a missing documentation issue. The SDK bridge works, it's just not documented anywhere.

Full writeup: https://dev.to/murat-a-a/how-we-got-local-mcp-servers-working-in-claude-cowork-the-missing-guide-nbc

— Murat_construction_Germany

michael-head-leeco · 3 months ago

Cross-referencing from #38783 — same issue on Windows 11, Claude Desktop 1.1.8359+. Detailed log analysis shows toolCount dropped from 19 to 3 exactly when the app auto-updated from v1.1.6679 to v1.1.8359. The computer-use MCP server is simply not being included in the spawn command for Cowork sessions anymore. Chrome extension pairs and connects successfully — the issue is upstream in the Desktop app.

jensend01 · 3 months ago

Same issue here. Reproduced on 3 separate machines (Windows + macOS), all using the same Claude Max account.
Performed a full diagnostic: registry entry ✅, JSON manifest ✅, extension ID match ✅, exe file exists ✅ — but chrome-native-host.exe returns "Error: Access is denied. (os error 5)" when executed.
I've filed a detailed report with the full diagnosis in #42134

mattberns · 3 months ago

Yep this is still not working for us either :(

Nubaeon · 1 month ago

For anyone landing here while hitting this on Claude Desktop 1.8555.x (May 22-23+ auto-updates): there's a more recent, more diagnostic deep-dive at #62072 — same class of regression but caught with full A/B evidence across three machines (Linux Ubuntu, macOS arm64, macOS Intel), full reproduction logs, and a customer-side workaround (downgrade to 1.3883.0 / 1.7196.3 + global mcpServers SDK-bridge patch).

The 1.8555.x manifestation is sharper than the intermittent-race-condition pattern in this thread — every spawn fails on every install vector (.mcpb, mcpServers SDK bridge, Custom Connectors, project-local .mcp.json) rather than the partial / per-extension drops described here. That suggests it may be a related but distinct regression in the spawn-config serializer, not just another instance of the same root cause.

@alicelovescake — you were hands-on shipping the fix for the prior 1.1.1890 / 1.1.2156 wave of this same class of regression on the original #20377 thread; figured you'd want a heads-up that the same neighborhood looks affected again on 1.8555.x. Evidence bundle in #62072 if you or whoever currently owns this area wants it.

dealsoverclients · 22 days ago

It's June 23rd and I'm still dealing with this. Cowork is pretty useless at this point. 7 out of 11 MCP's don't show up regardless of being properly installed.

raoulvdberge · 18 days ago

I'm trying to create a valuable training programme for Cowork, and this bug is making it hard for me to do so.

Nubaeon · 15 days ago

Update — appears resolved on 1.17377.1 (macOS)

Hit this exact symptom on macOS 15.7.7 / Claude Desktop 1.15962.2: a Cowork (local-agent-mode) session spawned an agent whose MCP set was built-ins only — user connectors (a seat plugin bundling remote MCP servers, plus a native Custom Connector) were absent, so the agent couldn't call them even though they worked fine in Chat.

After (a) a clean profile reinstall (~/Library/Application Support/Claude, Caches/Claude, Logs/Claude moved aside) and (b) updating to 1.17377.1, agent enumeration is restored:

mcpServerStatus returned 49 servers (16 with tools) — now including the user connectors alongside built-ins (previously built-ins only).
The agent requested permission for and called those connectors' tools (a *_session_init + record CRUD tools), verified in main.log + the session record.

Caveat: we changed two variables at once (build and a clean profile), so we can't fully isolate which was load-bearing — but since the regression tracked auto-updates, the newer build appears to restore the spawn/enumeration pipeline. If you're stuck on an older build, a clean-profile reinstall + update to ≥1.17377.1 is worth trying. (macOS only — can't speak to the Windows report.)

dealsoverclients · 14 days ago

I tried this fix and ran it through claude code.

I ended up losing all of my claude cowork chats and projects (quite
devastating)...

As well as all my claude code chats.

And after 3 hours cowork still doesn't see my MCP's.

I'm in a worse situation than I was when I started.

Claude Code conversations are still local but Claude Chat is telling me they
can't be restored to the Desktop.

and Claude Cowork convos and projects are completely gone (supposedly).

This is insane.

On Wed, Jul 1, 2026 at 3:59 AM David Samuel Laurence Van Assche
@.***> wrote:

[https://ci3.googleusercontent.com/meips/ADKq_NbJh_C5EJqImmVxjnB8hrNbPuSdA2hCm67coeufV8_Jr7k_iPu03JBwIGyDwwxn4N3JxJFJ2zaOInaOyFj-ECZoEXkE-I7XFls4zECXXVM=s0-d-e1-ft#https://avatars.githubusercontent.com/u/64048715?s=20&v=4]Nubaeon left a comment (anthropics/claude-code#27492) [https://github.com/anthropics/claude-code/issues/27492#issuecomment-4853604985] Update — appears resolved on 1.17377.1 (macOS) Hit this exact symptom on macOS 15.7.7 / Claude Desktop 1.15962.2: a Cowork (local-agent-mode) session spawned an agent whose MCP set was built-ins only — user connectors (a seat plugin bundling remote MCP servers, plus a native Custom Connector) were absent, so the agent couldn't call them even though they worked fine in Chat. After (a) a clean profile reinstall (~/Library/Application Support/Claude, Caches/Claude, Logs/Claude moved aside) and (b) updating to 1.17377.1, agent enumeration is restored: mcpServerStatus returned 49 servers (16 with tools) — now including the user connectors alongside built-ins (previously built-ins only). The agent requested permission for and called those connectors' tools (a _session_init + record CRUD tools), verified in main.log + the session record. Caveat: we changed two variables at once (build and a clean profile), so we can't fully isolate which was load-bearing — but since the regression tracked auto-updates, the newer build appears to restore the spawn/enumeration pipeline. If you're stuck on an older build, a clean-profile reinstall + update to ≥1.17377.1 is worth trying. (macOS only — can't speak to the Windows report.) — Reply to this email directly, view it on GitHub [https://github.com/anthropics/claude-code/issues/27492?email_source=notifications&email_token=BNWBZ52D6S6YBEVCJSJCPN35CTVHTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVGM3DANBZHA22M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4853604985], or unsubscribe [https://github.com/notifications/unsubscribe-auth/BNWBZ557T2UKGHVCIFLO6JD5CTVHTAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGOJXGI3TIMBWHA42C5QC]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [https://github.com/notifications/mobile/ios/BNWBZ5YF46GERVTNHLQGY2D5CTVHTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVGM3DANBZHA22M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y] and Android [https://github.com/notifications/mobile/android/BNWBZ56F5AAP7NBOXRRVN7L5CTVHTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVGM3DANBZHA22M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI]. Download it today! You are receiving this because you commented.[https://ci3.googleusercontent.com/meips/ADKq_NbeEpsBxFxQmVjoWukDPvJmjuYSKUumLREwuPkmxhM9b4dntxrmZn8z_m5aguWKZXbUhYmIgwwyVM3j8TIAA0N6ODQsrxA9BfC-7CddOaV0OH5eYdiND3wZN5l4IwqM3HFPe_eM2CYBww2hz2Afdbv-HInyictTnn5OpgACK-H857SPg7Az87k5bWK9kcDXR62kcaz-_CHhjflFHi1iXfjzCjmtuoh-B4oTxjLm2ErVvSBLx5JWWbaFsbs21QfvZ8nfo-LzPigIrNVN8nqm3NKOfFnVWY0U=s0-d-e1-ft#https://github.com/notifications/beacon/BNWBZ55MUFCBNEQ7MGXFYY35CTVHTBFCNFSM6AAAAACV3PXPR6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACIKMEJ42M4TFMFZW63VHMNXW23LFNZ2A.gif]Message ID: @.**>

Tony Teegarden

www.TonyTeegarden.com [http://www.TonyTeegarden.com]
Read The Meaningful Man [https://tonyteegarden.substack.com/]
Connect with me on Facebook [https://www.facebook.com/tonyteegarden]
Learn more about me on Linkedin [https://www.linkedin.com/in/ateegarden]
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]

Nubaeon · 14 days ago

You did not backup your conversations? Always do that, Cowork (just a pinned claude code version running in a VM with limited tool access) and Code stores its conversations locally, the chat ones are in the cloud.

Also check for any zombie / past processes that might be interfering. This fix works, I've used it across an Enterprise plan. Make sure your MCP servers are using Oauth (custom connectors) rather than local dev. I can get my Claude to give a more detailed explanation for the full fix if that helps...

dealsoverclients · 14 days ago

Yes I did a full ClaudeProfileBackup to my desktop.

But what I think happened is the files disappeared and went to my iCloud account
(which of course now I can't find them in iCloud)

However right after you commented I had claude code give it one more go and now
all of my chats & projects are back in Cowork and Claude Code.

Thanks goodness.

Now I'm still wrestling with the MCP's not working.

I'm still getting this error for example:

I don't have a Gmail connection set up in this session, Tony. To check your
emails, you'd need to connect a Gmail MCP tool.

You can do that by going to Settings > Connections in Cowork and adding Gmail.
Once connected, I'll be able to pull your inbox, search emails, draft replies,
and more.

Want me to help you find and set up a Gmail connector?

I'm not sure how to research Zombie/past processes but I can ask claude code.

Any feedback you have is welcomed and appreciated.

On Wed, Jul 1, 2026 at 1:04 PM David Samuel Laurence Van Assche
@.***> wrote:

[https://ci3.googleusercontent.com/meips/ADKq_NbJh_C5EJqImmVxjnB8hrNbPuSdA2hCm67coeufV8_Jr7k_iPu03JBwIGyDwwxn4N3JxJFJ2zaOInaOyFj-ECZoEXkE-I7XFls4zECXXVM=s0-d-e1-ft#https://avatars.githubusercontent.com/u/64048715?s=20&v=4]Nubaeon left a comment (anthropics/claude-code#27492) [https://github.com/anthropics/claude-code/issues/27492#issuecomment-4859617717] You did not backup your conversations? Always do that, Cowork (just claude running in a VM with limited tool access) and Code stores its conversations locally, the chat ones are in the cloud. Also check for any zombie / past processes that might be interfering. This fix works, I've used it across an Enterprise plan. Make sure your MCP servers are using Oauth (custom connectors) rather than local dev. I can get my Claude to give a more detailed explanation for the full fix if that helps... — Reply to this email directly, view it on GitHub [https://github.com/anthropics/claude-code/issues/27492?email_source=notifications&email_token=BNWBZ56OODFSXCYXQTPRHRT5CVVFNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVHE3DCNZXGE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4859617717], or unsubscribe [https://github.com/notifications/unsubscribe-auth/BNWBZ55A3EBFFLAV7PDK6Y35CVVFNAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGOJXGI3TIMBWHA42C5QC]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [https://github.com/notifications/mobile/ios/BNWBZ54IO57ZGMF3MRPLCL35CVVFNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVHE3DCNZXGE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y] and Android [https://github.com/notifications/mobile/android/BNWBZ57P6E53VNC5CV5BYFT5CVVFNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVHE3DCNZXGE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI]. Download it today! You are receiving this because you commented.[https://ci3.googleusercontent.com/meips/ADKq_NbFycAkXuiOSVNtmNavdZIfgUc3AAW_TvNfqP0wwbVN4y7gi_faKhKOtUIL_hIl9XkU0rw55Yjwl1dT_nYzfJxpKNf6QSMvXezuZX3HrFKLH13XlvxRX2C6HqBWcUKXlFEfjDS_56y5qt2bvmMatEc6XcvUnFN8dOSQ3Zj6mkbsXnr_OqI-JRY9Gvn_Cr4Af-Ot12eLTUXrnfzUVPRS-NOtxLW9gGMG9fO_Hp077vPiVPWHZIqGovqOoY2Hxt_rLuvRK_fA2LIS1-Q-hFzTnbmRhpBsC5aR=s0-d-e1-ft#https://github.com/notifications/beacon/BNWBZ5446YHA5SW6WE7FQED5CVVFNBFCNFSM6AAAAACV3PXPR6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACINH4G22M4TFMFZW63VHMNXW23LFNZ2A.gif]Message ID: @.***>

Tony Teegarden

dealsoverclients · 14 days ago

It was telling your solution is what caused the disconnect of my gmail MCP
(which I called it out that this issue is going on a month old)...

If it matters I'm getting this response when asking claude code to help and of
course I get the generic answer at the very bottom to reuahtorize them all which
does nothing:

Fair correction — you're right, and I'll drop that causation claim. If the
problem predates this morning by a month, the reset didn't cause it; at most it
shuffled which connectors enumerate. Let me stop theorizing and actually map
every UUID in the Cowork enumeration to a real connector name, so we can see
precisely which of your 12 are usable in Cowork versus dead.

Great catch on the connector list — that image is exactly what I needed, and it
changes my read. Let me reconcile it against the logs before I give you a
straight answer.

Comparing your installed connectors to what Cowork actually hands the agent (the
CCD SDK call passes 11 remote connectors by name):

Fathom, Gmail, Google Calendar, Google Drive, Kajabi MCP, NotebookLM, Skoot, Slack, Supabase, Vercel, WriteStack.io

Your screenshot shows 12 web connectors — that list plus GitHub Integration. So
GitHub is the one dropped from the agent handoff, yet Gmail is in the list. That
means Gmail isn't missing from enumeration — it's being handed to the agent but
failing at call time. Let me confirm that with the actual error from your two
failed Gmail sessions.

The logs just settled it — and it's not an auth problem. Your failed "Recent
Gmail emails" session (local_b6966b63) shows Turn succeeded at 13:16:15 with
zero tool calls, zero 401s, zero connection errors. The only errors in the whole
log are unrelated (missing screenshot files in ProjectSync, one network blip).
The agent didn't fail to reach Gmail — it was never handed Gmail tools, so it
answered from scratch.

Let me check the one lever that would explain a month-long, connector-specific
gap: the per-plugin enable overrides (your log shows fetchPluginEnabledState: 28
overrides).

That last search cracked it — and it's your own words in the log that confirm
the real symptom. Recovered from your Cowork history:

"All of my skills & MCP's are now showing up but claude cowork still can't 'access them' even though they're there."

That's the signature. Combined with the failed Gmail turn completing cleanly
(Turn succeeded, no tool call, no 401, no connection error) and no per-connector
"disabled" flag anywhere in your local state, here's the honest, evidence-based
conclusion:

REVISED DIAGNOSIS

You were right — I'll retract the causation claim. This isn't your profile, your
build, or auth expiry. It's a Cowork product bug: remote connectors appear in
Cowork's picker but never get wired into the agent's callable toolset. The agent
doesn't error — it just doesn't see the tools, so it answers "no Gmail
connection" from scratch.

And there's a clear pattern in which ones break. Look at what actually loaded
live tools into this very session versus what didn't:

Connector Auth type Usable in Cowork? Skoot (CUSTOM) API key ✅loaded in this
session Kajabi MCP (CUSTOM) API key ✅loaded in this session Supabase access
token ✅loaded in this session Fathom token ✅loaded in this session Gmail OAuth
❌your failing case Google Calendar OAuth ❌almost certainly Google Drive OAuth
❌almost certainly Slack OAuth ❌almost certainly GitHub Integration OAuth ❌(also
dropped from the SDK handoff entirely) Vercel OAuth ❌likely NotebookLM (CUSTOM)
key/URL ⚠️probably works (custom) WriteStack.io (CUSTOM) key/URL ⚠️probably
works (custom)

The split is auth type: token/API-key and custom-URL connectors wire into Cowork
fine; OAuth-based connectors don't. That's why Chat (which owns the OAuth
session) works and Cowork doesn't — the Cowork agent runtime isn't carrying the
OAuth handshake through. Roughly 4–6 of your 12 are actually usable in Cowork
today, and they're the non-OAuth ones.

WHAT ACTUALLY TO TRY (NONE OF IT IS ANOTHER RESET)

Confirm it empirically first. In a fresh Cowork session, ask: "List every

MCP tool you currently have access to, grouped by server." That gives you
the ground-truth usable set per session. I can also run that probe live
right now if you want.

For the OAuth connectors: open each in Settings → Connectors → Reconnect /

re-authorize, then start a new session. This occasionally re-registers the
runtime binding. Low cost, worth one pass.

If they still don't wire in — that's the bug, and it's on Anthropic's side.

It's worth reporting, and you now have airtight evidence to attach:

Build 1.17377.1 (the "fixed" one) — enumeration works, mcpServerStatus

returns 23 servers with tools.

CCD hands the SDK 11 remote connectors including Gmail, yet the

local-agent session's toolset omits the OAuth ones.

Session local_b6966b63 ("Recent Gmail emails"): Turn succeeded with zero

tool calls and zero errors — the agent never had Gmail tools.

Pattern: only non-OAuth connectors expose tools to the agent.

Want me to run the live tool-enumeration probe in this session right now so we
can see the exact usable list, no guessing?

On Wed, Jul 1, 2026 at 1:19 PM Tony Teegarden @.***> wrote:

Yes I did a full ClaudeProfileBackup to my desktop. But what I think happened is the files disappeared and went to my iCloud account (which of course now I can't find them in iCloud) However right after you commented I had claude code give it one more go and now all of my chats & projects are back in Cowork and Claude Code. Thanks goodness. Now I'm still wrestling with the MCP's not working. I'm still getting this error for example: I don't have a Gmail connection set up in this session, Tony. To check your emails, you'd need to connect a Gmail MCP tool. You can do that by going to Settings > Connections in Cowork and adding Gmail. Once connected, I'll be able to pull your inbox, search emails, draft replies, and more. Want me to help you find and set up a Gmail connector? I'm not sure how to research Zombie/past processes but I can ask claude code. Any feedback you have is welcomed and appreciated. [data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D] On Wed, Jul 1, 2026 at 1:04 PM David Samuel Laurence Van Assche @. @.> wrote: > [https://ci3.googleusercontent.com/meips/ADKq_NbJh_C5EJqImmVxjnB8hrNbPuSdA2hCm67coeufV8_Jr7k_iPu03JBwIGyDwwxn4N3JxJFJ2zaOInaOyFj-ECZoEXkE-I7XFls4zECXXVM=s0-d-e1-ft#https://avatars.githubusercontent.com/u/64048715?s=20&v=4]Nubaeon > left a comment (anthropics/claude-code#27492) > [https://github.com/anthropics/claude-code/issues/27492#issuecomment-4859617717] > > You did not backup your conversations? Always do that, Cowork (just claude > running in a VM with limited tool access) and Code stores its conversations > locally, the chat ones are in the cloud. > > Also check for any zombie / past processes that might be interfering. This > fix works, I've used it across an Enterprise plan. Make sure your MCP > servers are using Oauth (custom connectors) rather than local dev. I can get > my Claude to give a more detailed explanation for the full fix if that > helps... > > — > Reply to this email directly, view it on GitHub > [https://github.com/anthropics/claude-code/issues/27492?email_source=notifications&email_token=BNWBZ56OODFSXCYXQTPRHRT5CVVFNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVHE3DCNZXGE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4859617717], > or unsubscribe > [https://github.com/notifications/unsubscribe-auth/BNWBZ55A3EBFFLAV7PDK6Y35CVVFNAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGOJXGI3TIMBWHA42C5QC]. > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > [https://github.com/notifications/mobile/ios/BNWBZ54IO57ZGMF3MRPLCL35CVVFNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVHE3DCNZXGE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y] > and Android > [https://github.com/notifications/mobile/android/BNWBZ57P6E53VNC5CV5BYFT5CVVFNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBVHE3DCNZXGE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI]. > Download it today! > You are receiving this because you > commented.[https://ci3.googleusercontent.com/meips/ADKq_NbFycAkXuiOSVNtmNavdZIfgUc3AAW_TvNfqP0wwbVN4y7gi_faKhKOtUIL_hIl9XkU0rw55Yjwl1dT_nYzfJxpKNf6QSMvXezuZX3HrFKLH13XlvxRX2C6HqBWcUKXlFEfjDS_56y5qt2bvmMatEc6XcvUnFN8dOSQ3Zj6mkbsXnr_OqI-JRY9Gvn_Cr4Af-Ot12eLTUXrnfzUVPRS-NOtxLW9gGMG9fO_Hp077vPiVPWHZIqGovqOoY2Hxt_rLuvRK_fA2LIS1-Q-hFzTnbmRhpBsC5aR=s0-d-e1-ft#https://github.com/notifications/beacon/BNWBZ5446YHA5SW6WE7FQED5CVVFNBFCNFSM6AAAAACV3PXPR6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACINH4G22M4TFMFZW63VHMNXW23LFNZ2A.gif]Message > ID: @.***> -- Tony Teegarden www.TonyTeegarden.com [http://www.TonyTeegarden.com] Read The Meaningful Man [https://tonyteegarden.substack.com/] Connect with me on Facebook [https://www.facebook.com/tonyteegarden] Learn more about me on Linkedin [https://www.linkedin.com/in/ateegarden]

Tony Teegarden

Nubaeon · 14 days ago

Hey Tony — glad your chats + projects came back; that iCloud-shuffle scare is exactly why I push "back up first," and sorry it put you through it.

Up front so there's no confusion: I don't work for Anthropic. Nubaeon is just another user (we run Claude across an Enterprise plan) sharing what worked in our own setup while their team gets to these Cowork issues — peer field-notes, not official guidance.

On "the fix caused a regression" — your follow-up already got there, and I agree. Two different layers are getting merged:

Enumeration — the piece the clean-profile + ≥1.17377.1 restores: the main agent even seeing your connectors (mcpServerStatus built-ins-only → full set). That's what we fixed.
Call-time binding — your Gmail case: they enumerate but their tools never reach the agent. Different layer; the reset neither caused nor fixes it (consistent with it being a month old).

What we actually pinned down (and I'll be precise about what we verified vs didn't): in Cowork's local-agent-mode, the tool-binding barrier we found was the spawn-level --allowedTools filter — the Cowork VM decides which tools the spawned agent may call. We chased auth first (tried an API-key path and an OAuth path) and both were dead ends — the blocker was orthogonal to auth. So I'd steer you away from "it's an OAuth problem" as the root; that's the trap we fell into.

Where your table is solid: Custom Connectors work in the Cowork agent — we ship one that's OAuth-based (our own server is the OAuth provider) and watched the local-agent session ask permission for and call its tools in main.log. The ones failing for you are Anthropic's first-party web connectors (Gmail/Calendar/Drive/Slack/GitHub). I'll be honest — we never debugged those in Cowork ourselves, so I won't hand you a mechanism we didn't verify. But one relevant thing we did log: Desktop doesn't pass your Anthropic identity through to MCP servers — so a first-party connector whose session lives in the Chat app has no obvious way into the spawned agent's sandbox. That's a plausible "why," not a confirmed one.

**What we know works (no more resets):**

Add the services you need as native Custom Connectors (Settings → Connectors → their own MCP endpoint, with their own key or OAuth) instead of the Chat "Connect Gmail" web connector. Standalone MCP servers exist for Gmail/Calendar/Drive/Slack — those are real MCP endpoints the Cowork agent binds, and we've confirmed that path end-to-end.
If your claude-code can dump the local-agent spawn args, look at the --allowedTools set — that's the exact lever we found for what the agent is permitted to call. That'll tell you empirically whether the OAuth ones are being filtered out at spawn vs never bridged.

And your instinct to report it to Anthropic is right — the evidence your claude-code assembled (1.17377.1, CCD handing connectors by name, the clean "Turn succeeded / zero tool calls" on the OAuth ones) is exactly what they'd need. There are related open issues on the .mcpb passthrough side (#20377, #26259); this first-party-web-connector case reads as its own thing worth a fresh report.

Happy to have my Claude write up the exact Custom-Connector setup for whichever services matter most to you — just say which.

dealsoverclients · 14 days ago

THANK YOU. Yes, I was very aware you don't work for Anthropic.

Hence, I wanted to ensure you knew I appreciated your help and insight.

I only have what I consider a handful of connectors.

Here's a general list:

Gmail
Google Calendar
Google Drive
Github Integration
Fathom
Slack
Supabase
Vercel

The Custom MCP's I have installed are:

Skoot
Writestack
NotebookLM (which is set up through my CloudFlare tunnel)

If it matters, I ran your feedback through Claude Code using Fable 5.

It's telling me I'm pretty much screwed and that this is an anthropic side
problem:

Understood — and I owe you a correction on my own evidence. Notably: this very
session I'm running in right now proves your point. My system prompt got
injected with instructions for Skoot, Supabase, Kajabi, Fathom, and computer-use
— but my actual callable toolset is just Skill/Read/Write/Bash. Zero MCP tools
bound. The connectors' instructions arrive; their tools never do. That's the
bug, live, in this conversation. You're right that it's all of them, not just
Gmail.

Let me check two things: whether your reconnect changed anything in the newest
session record, and whether any Cowork session has ever successfully called a
connector tool.

Your frustration is justified, and the data just proved it. Two decisive
findings:

Your reconnect actually DID work — at the config layer. Today's "Last 5 Gmail

emails" session (09:07) now shows Gmail with five current tools enabled
(search_threads, get_thread, list_drafts, list_labels) — the stale-map problem I
found is fixed. And the agent still said "no Gmail connector." So the enablement
map wasn't the root either.

The nuclear evidence: I scanned every tool-permission request in your entire

log history. The spawned Cowork agent has only ever requested: Bash (285 times)
and Write (7 times). In months of sessions, no MCP connector tool has ever been
requested or called — not once, by any session. Not Gmail, not Skoot, not
Supabase, not any of them.

So the full picture, layer by layer:

Layer Status Enumeration (mcpServerStatus) ✅works — 23 servers with tools Bridge
(remoteMcpServersConfig) ✅works — all 11 connectors, full tool schemas, in every
session Enablement map (enabledMcpTools) ✅now fixed by your reconnect Tool
binding to the model ❌broken — zero MCP tools ever reach the agent's callable
set

You've now personally falsified every user-fixable layer: clean profile ✅,
latest build ✅, reconnect/reinstall ✅, enablement refresh ✅. There is nothing
left on your side to fix. This is an app bug in the final tool-binding step of
the local-agent spawn, and only Anthropic can fix it. Your contact's
--allowedTools instinct was pointing at the right layer — but the filter isn't
the problem; the tools never get attached at all.

WHAT I SUGGEST NOW — THREE THINGS, IN ORDER

One discrimination test (2 minutes, tells us if ANY path binds). In a fresh

Cowork session, paste exactly this:

"Do not answer from memory. List the exact names of every tool you can currently call, grouped by server. Then attempt to call one Fathom tool and one Skoot tool and report the raw result."

This tests whether the plugin stdio path (fathom) or custom connector path
(Skoot) binds even though first-party ones don't. If either works, I can pipe
Gmail through that working layer as a real workaround. If it returns only
Bash/Read/Write/core tools — every path is dead and workarounds via MCP are off
the table until Anthropic fixes it.

Let me build the bug-report evidence file right now. You have a forensically

complete case — layer-by-layer proof with log lines, timestamps, and session
records. That's the difference between "me too" and a report an engineer can act
on same-day.

Meanwhile, for Gmail specifically: the agent's own suggestion of Claude in

Chrome is worth one try in that same test session ("open my Gmail inbox in
Chrome and read my last 5 emails") — it rides a different pipe than the MCP
bridge, so it may work even with binding broken.

Want me to generate the evidence file now while you run the discrimination test?
Then we'll know exactly which workaround is real — and you'll have the report
ready to send either way.

========
[I ran it's suggestion and this is what came back]:

here's what came back: Thought process Thought process I'll call both
simultaneously — and I'll be upfront that I can only enumerate tool names from
what's surfaced in the MCP server descriptions and live responses, since there's
no meta-"list all tools" endpoint. Let me fire both calls now. Used 2 tools Used
2 tools The tool name prefix guesses were wrong. Let me try UUID-based naming
(which matches those MCP server IDs) and the workspace tools I know exist: Used
2 integrations Used 2 integrations Neither UUID prefix works either. Here's my
honest report: Tools I can actually call right now (from the JSONSchema
definitions at the top of this session): Built-in file/search tools Read — read
files from the filesystem Write — write/overwrite files Grep — regex search via
ripgrep Glob — file pattern matching Skill — invoke an available skill by name
That's it. Five tools total. What I attempted and what happened: I tried every
reasonable naming convention for Fathom and Skoot tools:
mcp__fathom__get_identity → No such tool available
mcp__skoot__list_community_members → No such tool available
mcp__e2231508-4ed4-4954-bf34-169f089c6d77__get_identity → No such tool available
mcp__017f810b-ce97-430a-887d-9ff13c59b6ab__list_community_members → No such tool
available Conclusion: The MCP servers described in the system-reminder
instructions (Fathom, Skoot, Supabase, Kajabi, computer-use, scheduled-tasks,
workspace/bash, cowork) are all referenced in the system prompt but not
currently loaded as callable tools in this session. They're described as if they
exist, but none of the mcp____ style tools appear in my actual tool registry
right now. The system prompt mentions tools like mcp__workspace__bash,
mcp__cowork__present_files, mcp__scheduled-tasks__create_scheduled_task, etc. —
but these were not provided in the JSONSchema function list I received, and live
attempts confirm they're unreachable. If you're expecting those connectors to be
active, something may be off in how the session was initialized or which MCP
servers are currently connected.
=========

That's the definitive result — and it's worse than we thought. Even the built-in
Cowork tools (mcp__workspace__bash, mcp__cowork__present_files,
mcp__scheduled-tasks__*) that the agent's own system prompt references aren't
bound. Five core file tools, nothing else. The entire MCP binding layer is dead
in the spawn, regardless of connector type: first-party, custom, plugin stdio,
and Anthropic's own built-ins.

That's the complete case. Let me grab the exact log references and today's test
session record, then build the evidence file.

The evidence file is built: claude-cowork-mcp-bug-report.md
[https://l.gourl.es/l/9a58cde6f427765ffa9f46565bdfc4ba8eab421d?u=12621777]
(saved in your home folder).

It documents the complete layer-by-layer case: enumeration ✅→ SDK handoff ✅→
session bridge ✅→ enablement map ✅→ tool binding ❌, zero MCP tools ever bound in
445 sessions, with exact log line numbers, session IDs, timestamps, your
discrimination-test results verbatim, and everything you've already ruled out
(so nobody tells you to try a clean reinstall again). It also flags the two
secondary bugs we found along the way: GitHub Integration missing from every SDK
handoff, and the stale enablement-map migration issue.

WHERE TO SEND IT

In-app: Claude Desktop → Help menu → Report Issue (or the feedback option in

Settings) — paste the file contents.

Email: @.*** with the file attached. Subject line

suggestion: "Cowork local-agent-mode: MCP tools never bind to spawned agent
(all connector types incl. built-ins) — build 1.17377.1, full layer-by-layer
evidence"

Send it to your contact too. Their Enterprise seat likely has a faster

escalation path than consumer support, and this answers their --allowedTools
question definitively: the filter isn't filtering — the registry is never
populated. The fact that even mcp__workspace__bash doesn't bind (while the
system prompt references it) should get an engineer's attention fast.

WHILE YOU WAIT

Chat app for anything needing connectors — Gmail, Calendar, Drive, Slack all

work there.

Don't touch the profile again. Nothing client-side is left to try; you've

falsified every layer a user can reach.

Your backups (claude-snapshot-…141132, claude-recovery-…130732) stay put

until this is resolved.

When an update lands, the 30-second retest is that same discrimination prompt

— "list every tool you can call, grouped by server" — in a fresh Cowork
session. If MCP tools appear in the registry, it's fixed.

One genuine silver lining: a month ago this was "Cowork can't see my MCPs." Now
it's a precise, reproducible defect report isolated to one specific step in the
spawn pipeline, with receipts. That's the version that gets fixed.

[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
On Thu, Jul 2, 2026 at 8:49 AM David Samuel Laurence Van Assche
@. @.> wrote:

[https://ci3.googleusercontent.com/meips/ADKq_NbJh_C5EJqImmVxjnB8hrNbPuSdA2hCm67coeufV8_Jr7k_iPu03JBwIGyDwwxn4N3JxJFJ2zaOInaOyFj-ECZoEXkE-I7XFls4zECXXVM=s0-d-e1-ft#https://avatars.githubusercontent.com/u/64048715?s=20&v=4]Nubaeon left a comment (anthropics/claude-code#27492) [https://github.com/anthropics/claude-code/issues/27492#issuecomment-4867626737] Hey Tony — glad your chats + projects came back; that iCloud-shuffle scare is exactly why I push "back up first," and sorry it put you through it. Up front so there's no confusion: I don't work for Anthropic. Nubaeon is just another user (we run Claude across an Enterprise plan) sharing what worked in our own setup while their team gets to these Cowork issues — peer field-notes, not official guidance. On "the fix caused a regression" — your follow-up already got there, and I agree. Two different layers are getting merged: Enumeration — the piece the clean-profile + ≥1.17377.1 restores: the main agent even seeing your connectors (mcpServerStatus built-ins-only → full set). That's what we fixed. Call-time binding — your Gmail case: they enumerate but their tools never reach the agent. Different layer; the reset neither caused nor fixes it (consistent with it being a month old). What we actually pinned down (and I'll be precise about what we verified vs didn't): in Cowork's local-agent-mode, the tool-binding barrier we found was the spawn-level --allowedTools filter — the Cowork VM decides which tools the spawned agent may call. We chased auth first (tried an API-key path and an OAuth path) and both were dead ends — the blocker was orthogonal to auth. So I'd steer you away from "it's an OAuth problem" as the root; that's the trap we fell into. Where your table is solid: Custom Connectors work in the Cowork agent — we ship one that's OAuth-based (our own server is the OAuth provider) and watched the local-agent session ask permission for and call its tools in main.log. The ones failing for you are Anthropic's first-party web connectors (Gmail/Calendar/Drive/Slack/GitHub). I'll be honest — we never debugged those in Cowork ourselves, so I won't hand you a mechanism we didn't verify. But one relevant thing we did log: Desktop doesn't pass your Anthropic identity through to MCP servers — so a first-party connector whose session lives in the Chat app has no obvious way into the spawned agent's sandbox. That's a plausible "why," not a confirmed one. What we know works (no more resets): 1. Add the services you need as native Custom Connectors (Settings → Connectors → their own MCP endpoint, with their own key or OAuth) instead of the Chat "Connect Gmail" web connector. Standalone MCP servers exist for Gmail/Calendar/Drive/Slack — those are real MCP endpoints the Cowork agent binds, and we've confirmed that path end-to-end. 2. If your claude-code can dump the local-agent spawn args, look at the --allowedTools set — that's the exact lever we found for what the agent is permitted to call. That'll tell you empirically whether the OAuth ones are being filtered out at spawn vs never bridged. And your instinct to report it to Anthropic is right — the evidence your claude-code assembled (1.17377.1, CCD handing connectors by name, the clean "Turn succeeded / zero tool calls" on the OAuth ones) is exactly what they'd need. There are related open issues on the .mcpb passthrough side (#20377 [https://github.com/anthropics/claude-code/issues/20377], #26259 [https://github.com/anthropics/claude-code/issues/26259]); this first-party-web-connector case reads as its own thing worth a fresh report. Happy to have my Claude write up the exact Custom-Connector setup for whichever services matter most to you — just say which. — Reply to this email directly, view it on GitHub [https://github.com/anthropics/claude-code/issues/27492?email_source=notifications&email_token=BNWBZ5376QD7TRTFDNW6LH35C2AABA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBWG43DENRXGM32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4867626737], or unsubscribe [https://github.com/notifications/unsubscribe-auth/BNWBZ55EGERNCX64RZSUHVT5C2AABAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGOJXGI3TIMBWHA42C5QC]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [https://github.com/notifications/mobile/ios/BNWBZ5YP5A2PRSB27YJWO4L5C2AABA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBWG43DENRXGM32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y] and Android [https://github.com/notifications/mobile/android/BNWBZ5Z5X7YU5UC4W3DM5EL5C2AABA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBWG43DENRXGM32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI]. Download it today! You are receiving this because you commented.[https://ci3.googleusercontent.com/meips/ADKq_NZkfrhRtMU7qsSvKb2xfVjyV2hlTQTDOehaMqCh_-90iEWngU8t6toNFddic8vxDHQ6MuxbKocqbBtKl7kjmh-JbRX1Fv02sQMI7OVpfE6mQie7R8XpsW6MRA7Z_dwxpR9LJIt1Iz6Q-zpE5DHHM3NeDJz_Wvz4SaI5FTpaLmdCkEDIUsDWfQQGI_Qij8bGKtsDBGsWyWz34O6loU7XZeDe7ZRtxbEKZzu1QtXH7xcxB8v_CIJ_uib-6-UfKSvRQraYGeSaQotwUjg5qfVMSAPrhfRWOP2j=s0-d-e1-ft#https://github.com/notifications/beacon/BNWBZ52EJP63OQVRF4TWAOL5C2AABBFCNFSM6AAAAACV3PXPR6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACIRCC3Y2M4TFMFZW63VHMNXW23LFNZ2A.gif]Message ID: @.***>

Tony Teegarden

Nubaeon · 14 days ago

Tony — appreciate that, and thanks for the connector list. Your Fable-5 Claude nailed the mechanism: instructions inject, tools never bind — that's the spawn-level --allowedTools filter, and yes it hits your Custom MCPs (Skoot/Supabase/NotebookLM), not just the Gmail-type web ones. But "pretty much screwed" is too dark — this is build-specific, not architectural.

On a fixed build (≥1.17377.1 for us on macOS) we got our own Custom Connector — a real OAuth MCP endpoint — to bind and get called by the Cowork agent (verified in the logs). Your Skoot / Supabase / NotebookLM-via-tunnel are exactly that shape, so two moves:

Check your build. Below 1.17377.1 → update (first lever). Already ≥1.17377.1 and still zero tools bound → that's a newer regression, and your live Fable-5 session (Skoot/Supabase/Fathom instructions injected, callable set just Skill/Read/Write/Bash) is a clean repro worth its own report.
For anything urgent: run the connector-dependent agentic work in Claude Code directly — native MCP config, no VM boundary. Your Custom MCPs drop straight into Code's mcp config and bind reliably. Cowork for chat + built-ins; Code for agentic-with-your-tools.

The first-party web ones (Gmail/Calendar/Drive/GitHub/Slack) may stay Chat-only even on a fixed build — their OAuth session lives in the Chat app, not the agent VM. The reliable pattern is a standalone MCP server for the service added as a Custom Connector (or in Code), not the built-in "Connect Gmail" button.

So: not screwed — build + a Claude-Code fallback for urgent work. Your instinct to file it stands; that transcript is the repro.

dealsoverclients · 7 days ago

I apologize for not getting back to you quickly.

Thank you for all the help and the feedback.

Hopefully Anthropic can fix this issue on their end in some kind of timely
manner.

Until then I'll use the workaround you've suggested.

Thanka again for your valuable time.

~ Tony

On Thu, Jul 2, 2026 at 12:03 PM David Samuel Laurence Van Assche
@.***> wrote:

[https://ci3.googleusercontent.com/meips/ADKq_NbJh_C5EJqImmVxjnB8hrNbPuSdA2hCm67coeufV8_Jr7k_iPu03JBwIGyDwwxn4N3JxJFJ2zaOInaOyFj-ECZoEXkE-I7XFls4zECXXVM=s0-d-e1-ft#https://avatars.githubusercontent.com/u/64048715?s=20&v=4]Nubaeon left a comment (anthropics/claude-code#27492) [https://github.com/anthropics/claude-code/issues/27492#issuecomment-4869563804] Tony — appreciate that, and thanks for the connector list. Your Fable-5 Claude nailed the mechanism: instructions inject, tools never bind — that's the spawn-level --allowedTools filter, and yes it hits your Custom MCPs (Skoot/Supabase/NotebookLM), not just the Gmail-type web ones. But "pretty much screwed" is too dark — this is build-specific, not architectural. On a fixed build (≥1.17377.1 for us on macOS) we got our own Custom Connector — a real OAuth MCP endpoint — to bind and get called by the Cowork agent (verified in the logs). Your Skoot / Supabase / NotebookLM-via-tunnel are exactly that shape, so two moves: 1. Check your build. Below 1.17377.1 → update (first lever). Already ≥1.17377.1 and still zero tools bound → that's a newer regression, and your live Fable-5 session (Skoot/Supabase/Fathom instructions injected, callable set just Skill/Read/Write/Bash) is a clean repro worth its own report. 2. For anything urgent: run the connector-dependent agentic work in Claude Code directly — native MCP config, no VM boundary. Your Custom MCPs drop straight into Code's mcp config and bind reliably. Cowork for chat + built-ins; Code for agentic-with-your-tools. The first-party web ones (Gmail/Calendar/Drive/GitHub/Slack) may stay Chat-only even on a fixed build — their OAuth session lives in the Chat app, not the agent VM. The reliable pattern is a standalone MCP server for the service added as a Custom Connector (or in Code), not the built-in "Connect Gmail" button. So: not screwed — build + a Claude-Code fallback for urgent work. Your instinct to file it stands; that transcript is the repro. — Reply to this email directly, view it on GitHub [https://github.com/anthropics/claude-code/issues/27492?email_source=notifications&email_token=BNWBZ5Y4U4WJ6TUQ6F7TCYT5C2WWXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBWHE2TMMZYGA2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4869563804], or unsubscribe [https://github.com/notifications/unsubscribe-auth/BNWBZ5ZT4JPLXQCUGI5E7ZL5C2WWXAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGOJXGI3TIMBWHA42C5QC]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [https://github.com/notifications/mobile/ios/BNWBZ52OBRDEKBHUJDZJVNT5C2WWXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBWHE2TMMZYGA2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y] and Android [https://github.com/notifications/mobile/android/BNWBZ56HK3GVQNRUTA7U2N35C2WWXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBWHE2TMMZYGA2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI]. Download it today! You are receiving this because you commented.[https://ci3.googleusercontent.com/meips/ADKq_Naj6rZiOKcjgaRnwsB3kRBqlQMSU5UjLmx32-DsgXYggsbELl1Fx8NH7Hl97CO1xxRc5fhWB_sj7fX_oGRqlok6NqICvCDXlb6Dn-FCn01emn1i87ZdhH0MKo2RbJgPLq4XAbtF8ZgHQ8H8QiUKwoh9BnxJVIZt-vhKVCQmeNbjyq-oY1g4oidSV562KPAqH3cx2kCHh8VpsgURqV26qCcfu5MUo9mSR53CakTVqniJHnwCwUIlrrZ6qP_qwzABIE0nR-rQsbGlZD4F5gDNj8WZULxCO4S6=s0-d-e1-ft#https://github.com/notifications/beacon/BNWBZ56UQH3JFYNLSEPRTT35C2WWXBFCNFSM6AAAAACV3PXPR6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACIR7UWOKM4TFMFZW63VHMNXW23LFNZ2A.gif]Message ID: @.***>

Tony Teegarden

raoulvdberge · 6 days ago

I was able to bypass this issue by configuring a MCP server via claude_desktop_config.json rather than using a .mcpb file.

silentwater · 6 days ago

Problem still exist. I configured different mcp servers like for confluence and jira using uvx in the claude_desktop_config.json. I get the message all the time when starting up Claude Desktop. The mcp servers are working, even so I get those error messages. It is not just related to Cowork, also in the normal Chat. My Colleagues all get the same error messages.

Nubaeon · 5 days ago

You will have noticed that Cowork moved into the cloud and I'm certain any previous local MCP conections will no longer work as intended. You need Oauth based custom connectors. The others will not work in my experience. We had to move our whole fleet of mcpb / local mcp server setups to Oauth with custom connectors and remove any legacy / redundant local or cached instructions.

Even with the MCP connectors showing working if there are any local configs or instructions Claude will not connect to the tools lists, especially when they send a sub agent to do that.