[BUG] MCP servers fail with "UtilityProcess spawn timeout" on Windows — hardcoded 5s spawn timeout + simultaneous spawn + full reload-on-toggle make 3+ stdio servers unreliable

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?

On Windows, stdio/extension MCP servers intermittently fail at startup with "Could not connect to MCP server X" and "MCP X: UtilityProcess spawn timeout". After investigation (logs + the bundled app.asar), the root cause is three independent, non-configurable issues:

1. The UtilityProcess spawn timeout is hardcoded to 5000 ms. In app/resources/app.asar (.vite/build/index.js) it is a literal 5e3, not driven by any environment variable (MCP_TIMEOUT / MCP_CONNECT_TIMEOUT_MS only affect the handshake, not the spawn):

await new Promise((i, r) => {
  const n = setTimeout(() => { r(new Error("UtilityProcess spawn timeout")) }, 5e3);
  this.process.once("spawn", () => { /* clearTimeout(n) ... */ });
});

2. All enabled servers spawn simultaneously at startup and then serialize (~1.8 s apart — a single shared bottleneck on process creation). Each cold spawn costs ~1.8 s on a healthy machine and more under load, so only ~2 servers fit inside the 5 s window; the last server(s) in the queue time out. Failure tracks queue position, not server weight (a ~7 MB server fails while a ~92 MB one succeeds in the same run).

3. Toggling any connector in the UI (or opening the Connectors panel) restarts EVERY enabled connector, not just the toggled one. It emits Server transport closed (intentional shutdown) and re-inits all servers, surfacing as "Could not attach to MCP server X" and a self-sustaining restart storm. So the only in-app recovery action makes things worse.

Why current mitigations don't solve it: antivirus real-time exclusions (Norton Auto-Protect/SONAR) cut spawn time ~20% (e.g. 2.31 s → 1.85 s) but not enough; reducing to 2 enabled servers is the only thing that reliably works today; toggling to reconnect is counter-productive (issue #3 above).

What Should Happen?

All enabled MCP servers should connect reliably at startup regardless of how many are configured, and recovering/toggling one connector should not tear down the others. Concretely: the spawn timeout should be configurable (or higher), server spawns should be staggered/serialized with each server's timeout measured from its own spawn request, and connector toggles should be scoped to the affected server only.

Error Messages/Logs

Toasts:
- Could not connect to MCP server Context7
- MCP Context7: UtilityProcess spawn timeout
- Could not attach to MCP server Filesystem

5 servers enabled — only the first connects, the rest hit exactly 5.0s:
[Filesystem] Initializing server...        15:36:20.567
[Affinity]   Initializing server...        15:36:20.570
[Cloudinary] Initializing server...        15:36:20.572
[PDF Tools]  Initializing server...        15:36:20.580
[Context7]   Initializing server...        15:36:20.582
[Filesystem] Server started and connected  15:36:25.362  (~4.79s)  OK
[Affinity]   UtilityProcess spawn timeout  15:36:25.596  (5.0s)
[Cloudinary] UtilityProcess spawn timeout  15:36:25.597  (5.0s)
[PDF Tools]  UtilityProcess spawn timeout  15:36:25.598  (5.0s)
[Context7]   UtilityProcess spawn timeout  15:36:25.600  (5.0s)

3 servers enabled — 2 connect, the last in the queue times out:
[Filesystem] Server started and connected  16:13:33.237  (1.85s)  OK
[PDF Tools]  Server started and connected  16:13:35.037  (3.65s)  OK
[Context7]   UtilityProcess spawn timeout  16:13:36.415  (5.0s)

Toggling one connector restarts ALL enabled servers -> cascade:
[Filesystem] Server started and connected            16:36:46.936  OK
[Filesystem] Server transport closed (intentional shutdown)  16:36:46.936
[Filesystem] Initializing server...                  16:36:46.939
[PDF Tools]  Server started and connected            16:36:48.731  OK
[PDF Tools]  Server transport closed (intentional shutdown)  16:36:48.731
[Context7]   UtilityProcess spawn timeout            16:36:50.188
[Filesystem] UtilityProcess spawn timeout            16:36:51.947
[PDF Tools]  UtilityProcess spawn timeout            16:36:53.743
(cascade continues for every enabled server)

Under transient load, even a single server can exceed 5s:
[Filesystem] Initializing server...        16:24:45.075
[Filesystem] UtilityProcess spawn timeout  16:24:50.089  (5.01s)

Steps to Reproduce

1. On Windows, install 3 or more Node-type MCP extensions/connectors in Claude Desktop.
2. Start Claude Desktop. -> One or more servers fail with "Could not connect to MCP server X" / "MCP X: UtilityProcess spawn timeout". On this machine ~2 of 3 connect; the last in the spawn queue times out at exactly 5.0s.
3. Open Settings -> Connectors and toggle a failed connector off then on to recover it.
4. Observe that ALL enabled connectors restart (Server transport closed / intentional shutdown) and previously-connected ones now show "Could not attach to MCP server X", cascading into more timeouts.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — Claude Desktop 1.8555.0.0 (MSIX/Store). This is a Claude Desktop bug, not the CLI.

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

• OS: Windows 11 Pro 26200 (x64)
• Claude Desktop: 1.8555.0.0 (Microsoft Store / MSIX, Claude_1.8555.0.0_x64__pzs8sxrjxfjjc)
• MCP servers: 5 Node-type extensions, spawned via the built-in Node (Electron run-as-node)
• Disk: system on SSD (not a slow-disk case)
• Antivirus: Norton 360 (real-time protection active; Windows Defender disabled)

Suggested fixes (any one helps; ideally all three)

1. Make the UtilityProcess spawn timeout configurable (env var or setting) and/or raise the 5 s default — it is too aggressive for Windows process-creation latency.
2. Stagger/serialize MCP server spawns at startup (or add a concurrency cap), with each server's timeout measured from its own spawn request rather than a shared start.
3. Scope connector toggles so that enabling/disabling one connector (and opening the Connectors panel) does not tear down and re-spawn already-connected servers.

Related issues

• #57585 — "MCP Connectors failing on Claude Desktop" (same UtilityProcess spawn timeout symptom; closed as invalid, no root-cause analysis).
• #5221 / #22542 — feature requests to make MCP tool-execution timeouts configurable (related but distinct from the spawn timeout described here).