[BUG] Cowork on macOS 1.8555.2 — zero MCP tools bind in any install path (.mcpb + SDK bridge + Custom Connectors + project .mcp.json); spawn pipeline missing --mcp-config since 2026-05-23 auto-update

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/26259
2. https://github.com/anthropics/claude-code/issues/36405

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

This is not a duplicate of #26259 or #36405 — the symptom shape is materially different. Tagging @bot to prevent auto-close.

The duplicates suggested describe an intermittent race:

• #26259 / #36405 / robrichardson13 / gileze33 / danielgreane comments: same machine, same user, same config — an extension is present in --mcp-config for some spawns, missing for others. ~50/50 across consecutive sessions. Partial loss, varies per spawn.

This issue is the opposite — deterministic total loss since a specific build:

• 500+ consecutive spawn events in cowork_vm_node.log, cowork_vm_swift.log, and coworkd.log since the 1.8555.2 update on 2026-05-23
• Zero --mcp-config, --allowedTools, or mcpServers references in any of them
• All four MCP install vectors (.mcpb, mcpServers SDK bridge, Custom Connectors, project-local .mcp.json) fail simultaneously
• The in-VM .claude.json is also empty of mcpServers — the wiring isn't being written anywhere downstream of the spawn either
• Chat tab MCPs initialize cleanly (the mcp.log shows all 7 .mcpb extensions doing healthy initialize + tools/list exchanges on every app launch)

The intermittent race in the older issues would have some extensions getting through. This regression has none — across hundreds of spawn attempts over 24+ hours. Different bug, almost certainly different root cause in the spawn-config serializer.

Also worth noting: both candidate duplicates (#26259, #36405) are closed and locked, with #26259 closed-for-inactivity rather than fixed. If this gets auto-closed as a duplicate of those, there's no live thread to track the (different + much worse) 1.8555.2 regression.

Please keep this open. Happy to provide a redacted snapshot bundle to an engineer for triage if useful — full evidence chain is in the issue body above.

Update — workaround validated empirically, regression boundary confirmed

Following up after running the same-machine, same-config A/B comparison to nail down whether 1.8555.2 is genuinely the regression point.

Method

• One affected Mac (macOS 15.1.1, Apple Silicon, Team plan)
• Restored /Applications/Claude.app from a Time Machine local snapshot dated 2026-04-26 (version 1.3883.0, codesigned 2026-04-21)
• Set defaults write com.anthropic.claudefordesktop disableAutoUpdates -bool true to prevent auto-upgrade back to 1.8555.2
• Left every other config exactly as-is (same .mcpb extensions, same project files, same connectors, same account)
• The only variable changed: Claude.app version

Result — sharp differential

| MCP install path | In 1.8555.2 (broken) | In 1.3883.0 (restored) |
|---|---|---|
| .mcpb Desktop Extensions → Cowork | ❌ Zero bind across 500+ spawns | ✅ All 7 extensions bind cleanly, mcp.log shows healthy initialize + tools/list for every server |
| Global claude_desktop_config.json::mcpServers SDK bridge → Cowork | ❌ Same — not bridged | ✅ Wired in. Older app's hardcoded PATH search list auto-resolves npx via ~/.nvm/versions/node/*/bin + /opt/homebrew/bin + /usr/local/bin + ~/.local/bin |
| Project-local .mcp.json::mcpServers → Cowork | ❌ Not bridged | ⚠️ Also not bridged — separate / older limitation (workaround: lift entry up into global claude_desktop_config.json) |
| Chat tab (any install path) | ✅ Works | ✅ Works |

~/Library/Logs/Claude/mcp-server-cortex.log had last activity on 2026-04-27 before going silent. After the downgrade + global-mcpServers patch on 2026-05-25, it wrote fresh entries within seconds of the first Cowork tool call. Same backend, same auth, same config — only Claude.app version differs. This is the regression isolated.

End-to-end verification post-fix

Three test calls inside a Cowork session under 1.3883.0, all returned real data:

1. cortex_session_init (no params) → returned user, org, projects[], skills[], voice_profile — full envelope
2. cortex_finding_log → ok:true, persisted:1 (with one separate fallback-bug discovery, internal follow-up)
3. Sub-agent invocation → 3.8s round-trip, correct CLAUDE.md-aligned behavior

Customer-side workaround (for other affected users reading this)

If you have a pre-2026-05-22 Time Machine snapshot containing /Applications/Claude.app:

# 1. Disable auto-updater so the downgrade isn't immediately re-pulled
sudo -u <user> defaults write com.anthropic.claudefordesktop disableAutoUpdates -bool true

# 2. Quit Claude (gracefully if possible, then pkill as fallback)
sudo pkill -f Claude.app

# 3. Move broken app aside, restore older one
sudo mv /Applications/Claude.app /Applications/Claude-BROKEN.app.bak
sudo mount_apfs -o nobrowse,rdonly -s com.apple.TimeMachine.<pre-may-22>.local /System/Volumes/Data /Volumes/TM-old
sudo cp -RPp /Volumes/TM-old/Applications/Claude.app /Applications/Claude.app
sudo xattr -cr /Applications/Claude.app

# 4. If using project-local .mcp.json mcpServers entries, mirror them into the global
#    ~/Library/Application Support/Claude/claude_desktop_config.json::mcpServers
#    (the older versions process the global file but skip project-local for Cowork)

# 5. Re-launch as the GUI user — note 'sudo -u' alone gets OSLaunchdErrorDomain Code=125
sudo launchctl asuser <UID> open /Applications/Claude.app

# 6. On first launch, click "Cancel" on any "Schlüsselbund nicht gefunden" / "Keychain not found"
#    dialog — DO NOT click "Reset to default" (latter wipes the entire user keychain)

Caveats:

• No official older DMG distribution from Anthropic — restoration requires a local backup of the binary (Time Machine, Carbon Copy Cloner, etc.). Without that, downgrade isn't accessible.
• Older versions miss UI polish from intervening releases (in our case: Live Artifacts library-view preview rendering, which is cosmetic — inline artifact usage works).
• The downgrade is a stopgap. The right fix is for Anthropic to ship a corrected spawn-config serializer in 1.8555.x+ — please prioritize.

Why we're confident this is a regression in 1.8555.2 specifically

• Same machine, same config, single variable changed (binary version) → behavior flipped from "zero MCPs bind in Cowork" to "all MCPs bind in Cowork"
• mcp-server-cortex.log going silent 2026-04-27 and resuming 2026-05-25 maps to that boundary
• User's own report: "everything worked great until last week, then connectors stopped suddenly" — consistent with auto-update window for 1.8555.x

Happy to share the redacted snapshot bundle to an Anthropic engineer if it accelerates the fix.

Fleet evidence — three independent machines confirm regression boundary

Since the last comment, ran the same A/B test on two additional machines. Same single-variable change (Claude Desktop binary version), same behavior flip across two operating systems and two architectures:

| # | Machine | OS | Arch | Broken on | Restored to | Outcome |
|---|---|---|---|---|---|---|
| 1 | Apple Silicon MacBook Pro | macOS 15.1.1 | arm64 (M2) | 1.8555.2 | 1.3883.0 (via TM local snapshot) | ✅ Cowork MCP wiring restored |
| 2 | ThinkPad X1 Yoga | Ubuntu 25.10 | x86_64 | 1.8555.2-2.0.12 (community port via aaddrick/claude-desktop-debian) | 1.7196.3-2.0.12 (older .deb from GitHub releases, apt-mark hold to prevent re-upgrade) | ✅ Cowork MCP wiring restored |
| 3 | Intel MacBook Pro | macOS 15.7.7 | x86_64 (Core i9) | 1.8555.2 | 1.3883.0 (cross-Mac tar over tailnet from machine #1) | ✅ Cowork MCP wiring restored |

All three: same .mcpb extensions registered, same claude_desktop_config.json::mcpServers SDK-bridge config (cortex via npx mcp-remote), same mcp.log health pattern post-downgrade. All three saw mcp-server-cortex.log resume writing within seconds of first tool call after restore.

This isn't a Mac-only or arm64-only quirk. The regression is in the shared Electron app code that ships across all three platforms via the same version stream.

Three install vectors confirmed broken in 1.8555.x simultaneously across all three boxes, restored simultaneously on downgrade:

• .mcpb Desktop Extensions → Cowork
• Global claude_desktop_config.json::mcpServers SDK bridge → Cowork
• Project-local .mcp.json::mcpServers → Cowork (this one was already broken in 1.3883.0 too, mitigated by lifting the entry up into the global config)

Sibling regression also worth Anthropic's attention: #61563 (1.8555 — 403 expired token on Cowork auth) — different surface symptom (auth) but same version stream, suggests this version introduced multiple Cowork-side regressions.

Asking for an engineering response on this thread rather than a triage label. Customer-side workarounds are in place across our fleet, but new affected installs are happening every day as users auto-update.

Confirming this on macOS, currently on Claude 1.9255.2 (1dc8f7) built 2026-05-27T01:57:20Z — so this regression is still present on builds shipped after 1.8555.2.

Same fingerprint: zero MCP tools bind in Cowork sessions. Only file tools (Read, Write, Grep, Glob) and the Skill invoker are available. Chrome MCP, computer-use, workspace bash, web_fetch, WebSearch, scheduled tasks, MCP registry search all fail to register. ToolSearch returns nothing for any of these. Connectors panel shows everything as Connected. Chat tab is unaffected — same MCPs work fine there.

Symptom onset matches the May 22 update window for me. Reproduced across three models (Opus 4.7, Sonnet, Opus 4.6) — model choice has no effect, consistent with the root cause being in spawn-config generation rather than the model.

Additional symptom worth flagging: with only file tools + the Skill invoker available, the Skill tool itself misfires. On asking Cowork to fetch a URL, the Skill tool repeatedly auto-triggered a bootstrap skill (setup-cowork in one session, init in another) regardless of the request — looping ~12 times in one case. The model narrated awareness of the loop ("the Skill tool is stuck returning setup-cowork") while continuing to invoke it, before giving up and confirming its only available tools were Read, Write, Grep, Glob, Skill. So the missing --mcp-config binding doesn't just remove the web/browser tools — it also leaves the model attempting to self-recover via bootstrap skills that can't succeed, since the underlying tool binding is what's broken. Loop behavior is non-deterministic (sometimes ~12 calls, sometimes a clean stop), which may point to a timing/race condition in spawn-config generation.

Already tried (no fix): fresh Cowork sessions, full app quit + relaunch, app update check, Settings → Connectors and Settings → Capabilities review, switching models.

Happy to share spawn logs from ~/Library/Logs/Claude/ if useful for confirming the --mcp-config serializer is still returning empty on 1.9255.2.

Cannot believe such a regression gets so little attention from Anthropic on a paid team plan...

This pretty much makes cowork unusable/pointless.

Follow-up: still broken on Claude 1.9659.2 (390d6c) built 2026-05-28T21:50:01Z — the May 28 build, two versions past the original 1.8555.2.

Build history on this account:

• 1.8555.2 (original report) — broken
• 1.9255.2 (May 27 build) — broken
• 1.9659.2 (May 28 build) — still broken

Symptom is also drifting in a way worth flagging. Earlier sessions had Claude visibly loop on bootstrap skills (setup-cowork, init) while narrating awareness of the loop. Today's session presented differently: Claude triggered the init skill once, then confidently pivoted to "I don't have access to a codebase folder" and asked which repo I wanted analyzed — when my actual request was to fetch a contractor's marketing website. Same root cause (no web/browser tools bound), but the failure mode is now masquerading as "wrong question from the user" rather than a visible loop. Easier to miss in QA, harder for end users to diagnose.

Seriously, do no Anthropic Engineers look at these regressions? They have actively crippled the entire product line. All I can say is wtf?

Maybe they should open source Cowork properly so the community can fix what they are actively selling. This is honestly ridiculous. One week has gone by and not a peep.

Update: reinstalling Claude Desktop cleared this on my end. Full app removal + deleting ~/Library/Application Support/Claude/, ~/Library/Caches/Claude/, ~/Library/Logs/Claude/, and ~/Library/Preferences/com.anthropic.claude.plist before a fresh download. Tools now bind correctly in Cowork sessions on build 1.9659.2 — web fetch and Ahrefs MCP both confirmed working. Suggests local state corruption from one of the May 22+ auto-updates rather than (or in addition to) the broken --mcp-config serializer in the build itself.

Similar to #62072 and #62556.
https://github.com/issues/created?issue=anthropics%7Cclaude-code%7C69345

Adding OAuth scope evidence not present in those issues.

Logs from ~/Library/Logs/Claude/main.log confirm
user:mcp_servers is never requested by Cowork sessions:

scope: 'user:inference user:file_upload user:profile'

This is consistent across every Cowork session on this
machine. Claude Code CLI on the same machine works correctly.
App version: 1.13576.4 (414f85) — 2026-06-18

Confirmed: downgrade to April 21 snapshot (equivalent to
~1.3883.0) restored full MCP functionality on macOS.

mcp__workspace__bash, Python, Node, and Pandoc all confirmed
working post-downgrade. All were non-functional on 1.13576.4.

Auto-updater disabled via:
defaults write com.anthropic.claudefordesktop disableAutoUpdates -bool true

Regression is confirmed in builds post-May 22 as described above

Similar to #62072 and #62556. #69345 Adding OAuth scope evidence not present in those issues. Logs from ~/Library/Logs/Claude/main.log confirm user:mcp_servers is never requested by Cowork sessions: scope: 'user:inference user:file_upload user:profile' This is consistent across every Cowork session on this machine. Claude Code CLI on the same machine works correctly. App version: 1.13576.4 (414f85) — 2026-06-18

Quick question on this, are you saying even Oauth scoped remote MCP servers break with the latest versions of Cowork? I was hoping and building towards that as a workaround, but if you can confirm that won't help I'll rethink my strategy for this bug.

> Similar to #62072 and #62556. #69345 > Adding OAuth scope evidence not present in those issues. > Logs from ~/Library/Logs/Claude/main.log confirm user:mcp_servers is never requested by Cowork sessions: > scope: 'user:inference user:file_upload user:profile' > This is consistent across every Cowork session on this machine. Claude Code CLI on the same machine works correctly. App version: 1.13576.4 (414f85) — 2026-06-18 Quick question on this, are you saying even Oauth scoped remote MCP servers break with the latest versions of Cowork? I was hoping and building towards that as a workaround, but if you can confirm that won't help I'll rethink my strategy for this bug.

Yes, confirmed.

On 1.13576.4, all claude.ai-hosted MCP
connectors are broken in Cowork regardless of how they're
configured — the missing user:mcp_servers scope means the
gateway rejects every connector at the auth layer before
any tool registration happens.

The supergateway / streamable-http workaround (converting
local stdio MCPs to HTTP endpoints) does bypass this for
locally-hosted servers — but cloud-hosted connectors going
through claude.ai's MCP gateway are blocked at OAuth
regardless.

Downgrading to the April 21 build (~1.3883.0) fully
restored functionality on my machine — bash, web fetch,
Notion, and all connectors working again. Auto-updates
locked via chown root:wheel to prevent regression.

If you have a pre-May-22 Time Machine snapshot, that's
currently the only working user-side fix.

jeez, that last windows bug showing the same issue is now truly showing the regression is OS agnostic and affects full MCP breakage across the board, Anthropic needs to look into this, anyone here have a line to them? I have some of their contacts but not anyone that could act on this as such, seeing as I'm EU based.

I hit this bug 5 minutes after trying to use Cowork with MCPB extensions. I don't understand how Anthropic didn't do the same.

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.)

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.)

Update: the 1.17377.1+ fix did not work on my machine.

Updated to 1.20186.0 (latest as of July 10) and
mcp__workspace__bash was absent in both new and existing
Cowork sessions. Rolled back to the April 21 build
(~1.3883.0) via Time Machine and bash is restored.

I had already done multiple clean profile wipes before updating,
so the profile wipe was not the missing piece on my end.
The update alone did not restore MCP tool enumeration.

Still confirmed broken on 1.20186.0 (macOS 15, Apple
Silicon, Pro plan). The only working fix for my setup
remains the pre-May-22 build via Time Machine, locked
against auto-updates via root ownership of the app bundle.