[BUG]

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?

Summary
Since approximately 2026-08-14/18, Claude Desktop intermittently fails to start the Desktop Commander MCP extension. The failure signature is always the same: the app spawns the server, sends the MCP initialize request, receives no response within ~62 s, cancels, and logs:

[error] Couldn't start this server for Cowork and Code sessions (they run their

own copy of it), so they can't use its tools: Request timed out

{ metadata: { context: 'shared-pool', stack: undefined } }

The onset coincides exactly with new launch machinery appearing in the MCP log ("Era probe verdict: legacy (sibling did not complete the exchange)", shared-pool context). The same installed server, launched by hand outside the app, answers initialize in about 1 second, which isolates the stall to the app-spawned execution path.
Environment
Claude Desktop 1.34493.1 (current as of 2026-08-25; "Check for Updates" reports up to date)
macOS 27.0 beta (26A5421a), MacBook Pro (M1 Max, MacBookPro18,2), 64 GB RAM
Desktop Commander 0.2.46, installed as a directory extension (ant.dir.gh.wonderwhy-er.desktopcommandermcp, MCPB downloaded 2026-07-22 — unchanged before/during onset), launched with the app's built-in Node (Electron helper: Node 24.18.1 / Electron 42.9.2)
Only other configured MCP server: @modelcontextprotocol/server-filesystem via /opt/homebrew/bin/npx (no reported trouble)
Log evidence (timestamps UTC, from mcpserverDesktop Commander.log)
Baseline before the regression (2026-04-28, extension v0.2.40): initialize sent 17:17:40.425, response 17:17:40.813 — ~0.4 s.

Failing pattern, 2026-08-18 through 2026-08-25 (eight occurrences: Aug 18 03:09:02, 18:35:02, 18:42:39, 19:52:44; Aug 21 00:13:38, 04:24:23; Aug 25 16:35:01, 17:04:00):

17:02:52.661 [info] Initializing server...

17:02:56.661 [info] Era probe verdict: legacy (sibling did not complete the exchange) <- +4 s

17:02:58.697 [info] Server started and connected successfully

17:02:58.699 [info] Message from client: method="initialize" id=0

17:04:00.693 [info] Message from client: method="notifications/cancelled" <- ~62 s, no response

17:04:00.694 [error] Couldn't start this server for Cowork and Code sessions ... Request timed out

Intermittency: on 2026-08-25 one attempt succeeded — initialize sent 16:35:10.988, response 16:35:54.171 (~43 s, just under the timeout), after which tools/list, prompts/list, and resources/list all completed normally. Retries succeed roughly half the time.
Isolation tests performed on the same machine, same day
The identical installed code (dist/index.js from the extension directory, same user config and caches, MCP_DXT=true NODE_ENV=production) run under system (Homebrew) Node answers initialize in ~1 s.
Two such instances started concurrently: both answer in ~1 s (rules out config/lock contention, including contention with the era-probe sibling).
The server's startup network endpoints (desktopcommander.app, its telemetry hosts) answer from this machine in ~0.2 s over IPv4 (curl). No outbound-filtering firewall is installed; the macOS application firewall is inbound-only.
Desktop Commander 0.2.46's startup network waits are hard-capped at 3–5 s in the shipped code (guards added for wonderwhy-er/DesktopCommanderMCP#465), so they cannot account for a 40–70 s stall.
Analysis
The 40–70 s initialize stall occurs only when the server is spawned by the app's built-in-Node extension launcher, and only since the era-probe/shared-pool machinery appeared in the logs in mid-August. The extension binary itself did not change in that window. This points to a regression in the new launcher path (era probe against a "legacy" server, and/or the shared-pool copy for Cowork/Code sessions) rather than in the server, the user configuration, or the network. The macOS 27.0 beta cannot be fully excluded as a contributing factor.
Related report
An independent report of the same signature on Windows 11 — variable initialize timing (4.9 s to >60 s), the same "Era probe verdict: legacy" line, one response arriving ~2 s after the timeout fired — is wonderwhy-er/DesktopCommanderMCP#645, opened 2026-08-21. Two users on two platforms with the same onset window makes an app-side launcher regression the more likely reading; the Windows report also rules out Defender interference and orphaned processes.

(The above was produced by my Claude app as I tried to debug the problem.)

mcp-server-Desktop Commander.log

What Should Happen?

Initialization should complete without errors

Error Messages/Logs

Steps to Reproduce

This happens repeated when I simply start the app

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Desktop 1.18286.0 (July 5)

Claude Code Version

Claude Desktop 1.34493.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The bug is in the desktop app's extension launcher rather than the CLI.