[BUG] Claude for Windows: MCP servers fail with UtilityProcess spawn timeout (hardcoded 5s spawn timeout)

Environment

• Product: Claude for Windows 1.8555.2 (a476c3)
• Package: MSIX Claude_1.8555.0.0_x64__pzs8sxrjxfjjc (Microsoft Store)
• OS: Windows 11 Pro build 26200 (x64)
• MCP servers: 5 Node-type extensions, spawned via the built-in Node (Electron run-as-node)
• Disk: SSD
• Antivirus: Norton 360 (real-time protection active; Windows Defender disabled)

---

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:

Root Cause 1 — Hardcoded 5 s spawn timeout

In app/resources/app.asar (.vite/build/index.js), the UtilityProcess spawn timeout is a literal 5e3 ms and is not driven by any environment variable. MCP_TIMEOUT / MCP_CONNECT_TIMEOUT_MS only affect the MCP protocol handshake, not the OS-level spawn:

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

Root Cause 2 — Simultaneous spawn → serialization → queue-position failures

All enabled servers are started simultaneously at startup, but process creation then serializes (~1.8 s per server on a healthy SSD machine). Only ~2 servers fit inside the 5 s window; any server further back in the queue times out. Failure tracks queue position, not server weight — a ~7 MB server fails while a ~92 MB one succeeds in the same run.

Root Cause 3 — Toggling one connector restarts ALL enabled connectors

Opening the Connectors panel or toggling any connector emits Server transport closed (intentional shutdown) for every enabled server, re-initializing them all. This turns the only visible in-app recovery action (toggle the failing server off/on) into a restart storm that knocks out already-connected servers.

Antivirus exclusions (Norton Auto-Protect/SONAR) cut spawn time ~20% (e.g. 2.31 s → 1.85 s) but are not sufficient.

---

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.0 s:
[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 5 s:
[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.0 s.

1. Open Settings → Connectors and toggle a failed connector off then on to recover it.
2. 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.

---

Expected Behavior

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.

---

Suggested Fixes

1. Make the spawn timeout configurable (env var or setting) and/or raise the 5 s default — it is too aggressive for Windows process-creation latency, especially under antivirus or I/O load.
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).

---

Note: This is a Claude Desktop bug; the repo tracks Desktop issues under the area:desktop label (e.g. #51143). This supersedes #61524, which was closed as out-of-scope. Suggested label: area:desktop.