[BUG] Desktop Commander MCP fails for Cowork/Code sessions (shared-pool): "Version negotiation failed"

Same failure on Windows (MSIX / Microsoft Store build) — this is not macOS-only.

Environment

• Platform: Windows 11 Pro (build 10.0.26200.0), x64
• Desktop app: 1.52386.6.0 (MSIX package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc)
• Executable: C:\Program Files\WindowsApps\Claude_1.52386.6.0_x64__pzs8sxrjxfjjc\app\Claude.exe

Same app version as the original report (1.52386.6), different OS.

Difference from the original report: this is a built-in connector

The failing server here is the built-in Filesystem connector, not a user-configured third-party extension. claude_desktop_config.json contains no mcpServers key at all, and the log confirms the app launches it with its own bundled Node:

[Filesystem] [info] Using built-in Node.js for MCP server: Filesystem

So the shared-pool probe regression is not specific to Desktop Commander — it also breaks a connector that ships with the app.

Symptom

Two dialogs on every app launch:

MCP Filesystem: Server disconnected. For troubleshooting guidance, please visit our debugging documentation

MCP Filesystem: Couldn't start for Cowork and Code sessions. Error: Version negotiation failed: the connection closed during the server/discover probe (this transport probed in place — the disposable sibling probe requires the SDK's base StdioClientTransport)

Timeline matches the ~Aug 17 regression

Final entries in mcp-server-filesystem.log, dated 2026-08-19. The sibling probe is already failing to complete the exchange here:

2026-08-19T00:27:32.954Z [Filesystem] [info] Initializing server...
2026-08-19T00:27:32.966Z [Filesystem] [info] Using built-in Node.js for MCP server: Filesystem
2026-08-19T00:27:36.970Z [Filesystem] [info] Era probe verdict: legacy (sibling did not complete the exchange)
2026-08-19T00:27:36.992Z [Filesystem] [info] Using built-in Node.js for MCP server: Filesystem
2026-08-19T00:27:37.042Z [Filesystem] [info] Server started and connected successfully
2026-08-19T00:27:37.043Z [Filesystem] [info] Shutting down server...

For comparison, a start on the previous day where the probe completed normally:

2026-08-18T07:03:05.180Z [Filesystem] [info] Era probe verdict: legacy
2026-08-18T07:03:05.587Z [Filesystem] [info] Server started and connected successfully

Additional data point: application logging has stopped entirely

No application log has been written since 2026-08-19, even though the app runs daily and the dialogs appear on every launch.

The logs directory (MSIX-virtualised at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs) contains nothing newer than 2026-08-19. A recursive search of the entire package container for *.log files modified in the last 14 days returns only Chromium/LevelDB internals (IndexedDB, Local Storage, Session Storage, shared_proto_db) — no application logs at all.

Meanwhile claude_desktop_config.json in the same directory is actively read and written by the running app, so the container path itself is correct.

This makes the failure impossible to diagnose locally, and may be worth treating as a separate defect.

Ruled out locally

• Stale allowed-folder paths. 13 of the 16 entries in preferences.localAgentModeTrustedFolders pointed at renamed or deleted directories (verified with Test-Path). Pruning the list to only existing paths and restarting produced no change in the error.
• Reconnecting folders from the project UI. Re-adding a folder does not prune stale entries; the list stays at 16.
• A second installation. Only one Claude process tree is running, from the MSIX package above.

Suggest adding the platform:windows label.

Same shared-pool failure on Windows 11, but here the main connection also times out, not just Cowork/Code. Measurements show the delay is on the Claude Desktop side, not the server.

Env: Claude Desktop (latest auto-updated build as of 2026-09-29) · Desktop Commander 0.2.52 (global npm, launched with system node.exe 24.19.0, not the built-in Node) · other local servers: Filesystem, one custom stdio server

Log under Desktop (failing):

15:31:33.337Z Server started and connected successfully
15:31:42.176Z Message from client: method="initialize" id=0
15:32:27.737Z [error] Couldn't start for Cowork and Code sessions. Error: Request timed out { context: 'shared-pool' }
15:32:42.170Z Message from client: method="notifications/cancelled"
15:32:42.171Z Server transport closed (renderer released port); shutting down server

On a successful launch, initialize took 49.8 s (15:25:44 → 15:26:33), ~10 s under the 60 s cutoff.

Same binary, same node.exe, spawned manually on the same machine:

| Test | initialize reply |
|---|--:|
| Piped stdin, 4 variants (protocol 2024-11-05 / 2025-06-18 × clientInfo) | 5.2–6.7 s |
| 3 instances in parallel (rules out load contention) | 4.6–4.7 s each |
| stdin held open, like an MCP client | 2.6 s |

So the server answers initialize in under 7 s in every configuration I can reproduce, but takes 50 s or more (or never) when Claude Desktop launches it. That points at the Desktop spawn/shared-pool path, e.g. the Era probe ("legacy (exec lane pinned — no sibling probe)" on this machine), not server startup. A fixed 60 s cutoff with no retry turns this into a hard failure.

Follow-up to my comment above: reproduces on a second Windows 11 machine, this time with Desktop Commander installed as a Claude Extension (built-in Node 24.21.0, MCP_DXT=true) instead of global npm + system Node. Same failure: main connection "Not responding", plus the shared-pool toast.

Dating: on this machine the last successful Desktop Commander tool calls were 2026-08-21 01:21Z; the next launch (01:42Z, then launched via cmd.exe from claude_desktop_config.json) already showed Era probe verdict: legacy (exec lane pinned — no sibling probe) → initialize with no reply → cancelled at 60 s. It has failed across three launch methods since (npm/config, cmd.exe/config, extension).

Intermittent, and the probe may be the trigger. Today's log for the extension server:

17:11:37Z Era probe verdict: legacy (sibling did not complete the exchange)
17:11:49Z initialize id=0            -> no reply; shared-pool "Request timed out" 17:12:28Z
17:47:29/33/38Z Era probe ... legacy (sibling did not complete the exchange)   x3
17:47:38Z initialize id=0            -> no reply logged
17:50:19/24/28/32/37Z Era probe ... legacy (sibling did not complete the exchange)   x5
17:50:37Z initialize id=0
17:50:45Z id=0 result                -> connected (8.0 s)

Every Era probe gives up ~4 s after "Initializing server" / the previous probe. Desktop Commander needs ~5–6 s to answer initialize standalone (measured on the first machine), so the sibling probe likely can never complete for it, and every launch falls back to the legacy path, which is where the 60 s timeouts happen. Suggest: a longer probe budget, or not letting a probe timeout push the server onto the path that then hangs.