MCP server hangs on first tool call in second session — Claude Desktop 1.4758, Windows

[Autonomaniac]

Summary

Desktop Commander tool calls work fine in the first chat session after launching Claude Desktop. After that session ends and a new one is opened, the first DC tool call in the new session hangs and eventually times out after ~4 minutes. Full app restart reliably restores DC. Frequency is increasing over recent days.

Environment

• Claude Desktop: 1.4758.0.0 (Microsoft Store / WindowsApps install)
• OS: Windows 11 (UWP-packaged Claude Desktop)
• DC source: This repo, loaded as Anthropic-managed extension ant.dir.gh.wonderwhy-er.desktopcommandermcp via the connector store / mcpb manifest path (not legacy claude_desktop_config.json — that file's mcpServers is empty)
• Other MCPs connected concurrently: PDF Tools (View, Fill, Merge, Split, Manage Pages, Extract), Context7, B12 Website Generator, Claude in Chrome, mcp-registry
• Model in use: Claude Opus 4.7 via claude.ai web client

Symptom (verbatim error returned to Claude)

No result received from the Claude Desktop app after waiting 4 minutes.
The local MCP server providing this tool may be unresponsive, crashed,
or not running. Further calls to this tool are likely to time out the
same way; consider using an alternative approach or ask the user to
restart their local MCP servers.

Reproduction steps

1. Launch Claude Desktop fresh.
2. Start a new chat. Use any DC tool (e.g. read_file, start_process). Works correctly.
3. End the chat session and start a new one in the same Claude Desktop instance.
4. Use any DC tool. The call hangs for ~4 minutes, then returns the error above.
5. Fully quit and relaunch Claude Desktop. DC works again on first call.

Reproduces consistently. The hang is at the first DC tool call of the new session — subsequent calls hang the same way without restart.

Architecture (relevant context)

Claude Desktop 1.4758 launches MCP servers as Electron UtilityProcess instances using the built-in Node, not as separate node.exe processes. Confirmed in main.log:

2026-04-28 07:40:55 [info] Using UtilityProcess for extension Desktop Commander:
  appConfig.isUsingBuiltInNodeForMcp is true and built-in node is compatible

Consequences:

• DC does not appear in tasklist /FI "IMAGENAME eq node.exe". It runs as claude.exe --type=utility --utility-sub-type=node.mojom.NodeService under the master claude.exe.
• Lifecycle is controlled by Electron's UtilityProcess manager.
• "Kill node.exe to clear zombies" is not a workaround on this build.

Evidence

Log rotation shows the previous server WAS torn down

mcp-server-Desktop Commander.log    8.3 MB   2026-04-28 07:38   ← current session
mcp-server-Desktop Commander1.log  10.5 MB   2026-04-27 20:51   ← previous session, rotated
mcp1.log                           10.5 MB   2026-04-27 20:53   ← master, rotated

The 1 suffix indicates a fresh server was spawned for today's session. Rotation happens cleanly.

But there's no shutdown logging at session end

Searching main.log for transport, disconnect, EPIPE, stdio, exited, killed near the end of yesterday's session returns nothing related to MCP server shutdown. There is no logged failure at the point the old session ended — only a silent gap until today's launch. Whatever happens at session-end is not currently observable from logs.

Hypothesis

The Electron UtilityProcess for DC is being put into a half-shutdown state at session-end. The new session's MCP host treats it as alive and routes new calls into it — which never respond because the process is no longer accepting JSON-RPC. Full app restart fixes it because it forces UtilityProcess teardown via Electron's main process exit.

Supporting points:

1. Symptom matches "stdio pipe still open but consumer dead" (call accepted, no response, eventual timeout).
2. Full restart fixes it.
3. Log rotation shows main thinks the previous server is over, but the rotation may be at log-handler level rather than UtilityProcess-handle level.
4. No transport/EPIPE error logged — consistent with "main thinks server is fine, server thinks it's dead."

Why DC and not the other MCPs?

Possible reasons:

• DC writes the most log volume (~8 MB in one moderate session vs ~70 KB for PDF Tools). Larger working set → graceful shutdown more failure-prone.
• DC owns long-running child processes via start_process and exposes their PIDs. If DC holds references to those subprocesses at session end and they outlive cleanup, UtilityProcess shutdown may block.

Bonus bug found while diagnosing — PowerShell stdout capture fails

While running diagnostic commands today, I observed a separate, 100%-reproducible issue:

When start_process is invoked with command="powershell.exe ..." directly (no cmd.exe shell wrapper), the process completes in under 300 ms with zero captured stdout, even when the command is valid and produces output:

start_process({command: "powershell.exe -NoProfile -Command \"Get-CimInstance Win32_Process -Filter \\\"name='claude.exe'\\\" | ...\"", timeout_ms: 20000})
→ "Process started with PID 2068 (shell: powershell.exe)\nInitial output:\n"

read_process_output({pid: 2068, timeout_ms: 15000})
→ "[Reading 0 new lines (total: 0 lines)]\n(No output in requested range)\n✅ Process completed with exit code 0 (runtime: 0.23s)"

Workaround: route through cmd.exe shell, write PowerShell output to a UTF-8 file using [System.IO.File]::WriteAllLines($out, $lines, $utf8), and read the file via DC's read_file. Avoids the stdout pipe entirely.

Suspected cause: PowerShell's default text output is UTF-16 LE with BOM. DC's stdout reader may be discarding the BOM stream as zero-length or treating it as binary.

Possibly a sibling of the cross-session hang — both involve DC's process I/O bridging — but distinct enough to track separately. Happy to file as its own issue if preferred.

Bonus observation — edit_block fuzzy matching reports successful matches as failures

In yesterday's session, ~30 consecutive edit_block calls on a markdown file containing tables all returned:

Exact match not found, but found a similar text with 100% similarity (found in 1055.77ms):

Each fuzzy search took 1010-1185 ms. 100% similarity means the match WAS found, but it's reported as a failure that requires the user to re-supply the "exact" text. Result: 30 seconds of CPU spent on edits that should have been instant exact matches, and the edits never landed.

Workaround: use write_file with full reconstructed content for any markdown containing tables. The whitespace normalisation between read and write appears to differ for table rows, which is what triggers the fuzzy fallback.

Suggested fixes (priority order, my view)

1. High — Add explicit lifecycle logging at MCP UtilityProcess shutdown. Without it, every report like this is guesswork. Cheapest intervention, highest diagnostic yield.
2. High — Replace the 4-minute silent timeout with a heartbeat/readiness probe and fail-fast (~5s). Bad UX as-is.
3. Medium — Investigate whether UtilityProcess recycling across sessions leaves dirty state (file handles? cached subprocess refs?).
4. Medium — PowerShell stdout-capture bug. 100% reproducible on Windows with direct powershell.exe invocation.
5. Low — edit_block fuzzy-match reporting 100%-similarity matches as failures.

Things I think the dev team might want to try

• Reproduce with multiple MCP servers connected (5+ here). May not reproduce with a single MCP server.
• Check whether DC's UtilityProcess is being recycled across sessions vs spawned fresh. Recycled-with-dirty-state fits the symptoms.
• Add a Disconnect/Terminate lifecycle event hook with logging.

Workarounds for users hitting this today

1. Full restart of Claude Desktop between sessions (current reliable fix).
2. For PowerShell-output sub-bug: write PowerShell scripts to .ps1 via DC's write_file, run via cmd.exe shell, output to UTF-8 file, read back via read_file.
3. For edit_block markdown-table issue: use write_file with full reconstructed content rather than chained edit_block calls on table-bearing files.

---

Happy to provide further logs (full main.log, mcp-server-Desktop Commander.log, process tree dumps) if useful — they're large, omitted from this issue body for readability. Diagnostic was run from inside Claude Desktop using DC itself.

[wonderwhy-er]

Thank you, we will take a a look

Very detailed investigation!