[BUG] Desktop (macOS): "Couldn't start this server for Cowork and Code sessions" raised for every local stdio MCP server at launch, but the logs show no sibling process is ever attempted

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?

Claude Desktop on macOS, 13 local stdio MCP servers declared in
claude_desktop_config.json. All 13 connect and work correctly in Chat,
continuously, and have for months.

Since an update installed on 2026-08-18, every launch raises one modal
error per server:

MCP <server>: Couldn't start this server for Cowork and Code sessions (they run their own copy of it), so they can't use its tools: Connection closed

Dismissing them clears them until the next launch. mcp.log holds 1,286
such lines over a 31-day window.

The logs show no second process is ever attempted. Each server
initialisation emits, in mcp-server-<x>.log:

Era probe verdict: legacy (exec lane pinned — no sibling probe)

Measured across all logs: 832 occurrences, zero variants. Every single
one says legacy. And the verdict is emitted 12 ms before the spawn
command, so it is a decision taken at init, not a reaction to a failure.

So the dialog reports a deliberate internal decision as a failure to start.

Onset is precise. mcp.log covers 2026-07-24T11:31:27Z onward:
first Era probe verdict: 2026-08-18T05:29:42.855Z
first Cowork/Code dialog: 2026-08-18T05:29:44.441Z
1.586 seconds apart, after 24.75 days of log containing neither. Both
arrived with the same update.

What Should Happen?

Either:

(a) If local stdio servers are meant to be available to Cowork/Code, the
sibling process should actually be attempted rather than skipped by
the era probe; or

(b) If the lane is pinned by design, the app should not raise a
per-server modal error for it. One informational note would do — or
wording that is true, e.g. "Local MCP servers configured in
claude_desktop_config.json are not available to Cowork and Code."

In either case the current text is a misleading diagnostic: it asserts an
attempted-and-failed start when none was attempted. It cost me several
hours chasing an unrelated container-name collision.

The volume matters independently. Thirteen dialogs at every launch is
alarm fatigue: a machine that reports thirteen MCP errors per launch is
one where a REAL MCP failure gets dismissed as noise. And the decision is
plainly global, so one message would be more accurate than thirteen.

Error Messages/Logs

~/Library/Logs/Claude/mcp.log
2026-08-18T05:29:44.441Z [error] [server-a] Couldn't start this server for
Cowork and Code sessions (they run their own copy of it), so they can't use
its tools: Connection closed

~/Library/Logs/Claude/mcp-server-<x>.log — one initialisation block:
05:23:45.006Z [info] Era probe verdict: legacy (exec lane pinned — no sibling probe)
05:23:45.018Z [info] Using MCP server command: /usr/local/bin/docker with path: {...}
05:23:45.019Z [info] Server started and connected successfully
05:23:45.678Z [info] Message from client: method="initialize" id=0

Counts (measured 2026-08-24):
  "Era probe verdict"   — one distinct string across every log file, checked
                          with `sort | uniq -c`. Zero variants. All "legacy".
  Cowork/Code dialog    — 1,286 lines in mcp.log over a 31-day window
                          (2026-07-24T11:31:27Z → 2026-08-24T12:35:14Z)
  Servers affected      — 13 of 13

Steps to Reproduce

1. On macOS, create ~/Library/Application Support/Claude/claude_desktop_config.json

with a single local stdio MCP server. Minimal example:

{
"mcpServers": {
"demo": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
}
}
}

1. Quit Claude Desktop fully (Cmd+Q) and relaunch.
2. Observe: the server connects and its tools work in Chat.
3. Observe: a modal error appears — "Couldn't start this server for Cowork

and Code sessions (they run their own copy of it), so they can't use its
tools: Connection closed"

1. Open ~/Library/Logs/Claude/mcp-server-demo.log and search for

"Era probe verdict". Note the verdict is legacy (exec lane pinned — no
sibling probe) and that it precedes the spawn command.

Note: my own servers are docker run … --name mcp-<x> stdio servers. I
have NOT tested whether a non-docker stdio server (such as the npx example
above) is classified differently by the era probe. If it is, that
distinction would itself be useful to know.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — I can't recover the prior version number from the logs. But the onset is exact: the failure first appears at 2026-08-18T05:29:42.855Z, minutes after an app update installed that morning, in a log that contains neither the era probe nor the dialog for the preceding 24.75 days. Per the public changelog the releases at that boundary are v1.32352.0 (2026-08-17), v1.32352.1 (2026-08-18) and v1.32885.1 (2026-08-18); the last working version is whichever preceded the one installed on 2026-08-18.

Claude Code Version

Claude Desktop (macOS): 1.34493.1 Bundled Claude Code: 2.1.237 (This is a Claude Desktop app bug, not a CLI bug — filing here per the precedent of #67432, labelled area:desktop + area:mcp + platform:macos.)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Related but distinct — none of these report the era probe or this dialog:

• #20377 (closed as completed; reporters say it persists)
• #23424 — local MCP servers not working in Cowork; only HTTP remotes work
• #26259 — Desktop Extension servers omitted from the Cowork VM's --mcp-config
• #35511 — Cowork times out at startup when any MCP entry is present in config
• #67432 — spawned Desktop sessions start without local stdio servers

This report is specifically about the Era probe verdict: legacy decision
and the dialog it produces, both of which first appear 2026-08-18.

The documentation points two ways:

• "Get started with custom connectors using remote MCP" states local MCP

servers configured via claude_desktop_config.json "aren't available in
Cowork or claude.ai."

• "Claude Cowork architecture overview" documents an MDM key

isLocalDevMcpEnabled that disables "plugin-bundled AND LOCALLY
CONFIGURED MCP servers" — a switch for something the first article says
never runs.

And the release notes describe the capability as existing:

• v1.28929.0 (2026-08-11): Chat now loads MCP tool schemas on demand

"as Cowork and Code do".

• v1.32352.0 (2026-08-17): Cowork fix for "a tool call hanging for a full

minute when its local MCP server crashed mid-call".

Happy to supply complete logs. Suggested labels: area:desktop, area:mcp,
platform:macos.