Exact error
Match the message before using the fix
Message from client: method="notifications/cancelled"Client transport closedMCP initialize cancelled after 60 secondsQuick answer
Start here
Compare the MCP log timestamps first. If `initialize` is cancelled almost exactly 60 seconds after it starts while the package runner is still downloading dependencies, run the same package command once outside Claude Desktop to warm its cache, then restart Desktop. Pinning the server and dependency versions can reduce repeated cold resolution. The upstream issue remains open and does not confirm a client-side timeout setting.
Diagnosis
Why it happens
- The reported Claude Desktop build cancelled the initialize request at a fixed 60-second boundary.
- For package-runner commands, the server process may not exist yet because uvx, npx, or pipx is still resolving and downloading packages.
- A warm cache can start in seconds while a cold dependency refresh takes longer than the client deadline; ordinary network and server crashes can produce similar UI symptoms without the exact timing.
Safest first
Fixes, in order
Confirm the exact 60-second initialize boundary
Applies when: When an stdio MCP server disappears from Claude Desktop after a slow launch
The source report distinguishes this problem by log timing, not by a generic failed-to-connect badge.
- Open the MCP server log for the affected configuration.
- Find the timestamp for the client `initialize` message and the later `notifications/cancelled` or `Client transport closed` message.
- Check whether the interval is almost exactly 60 seconds and whether package downloads are still in progress.
- If the interval or stage differs, diagnose that error instead of applying this workaround.
Expected: The log shows a cold package install crossing the 60-second initialize boundary.
Pre-warm the package runner cache
Applies when: uvx, npx, or pipx-run configurations that succeed when warm
The reporter measured a cold start around 110 seconds and warm starts of 7–26 seconds.
- Close Claude Desktop so it does not launch competing package downloads.
- Run the exact configured package-runner command manually in a terminal and allow dependency installation to finish.
- Stop the manually started MCP server after it reaches its ready state.
- Restart Claude Desktop and inspect the next initialize timing.
Expected: The warmed server answers initialize before the 60-second cancellation and its tools appear in Desktop.
Pin the server package and volatile dependencies
Applies when: Configurations that repeatedly invalidate their environment after upstream releases
A bounded version reduces surprise resolution work, but the exact pin syntax belongs to the package runner and server you use.
- Record the package versions from a known working warm launch.
- Use the package runner's documented exact-version syntax in the MCP command.
- Test the pinned command manually before changing the Desktop configuration.
- Review the pin intentionally when applying security or compatibility updates.
Expected: Routine Desktop restarts reuse a stable environment instead of resolving a new dependency tree.
Verification
Prove the fix worked
- Restart Claude Desktop with a cold app session but a warmed package cache.
- Confirm the MCP log records an initialize response before 60 seconds.
- Call one harmless tool from the server and confirm it returns normally.
Escalation
If it still fails
- Do not assume `MCP_TIMEOUT` or a `timeout` field changes this initialize deadline; the source did not confirm such an override.
- Capture the package runner, server package, cold and warm timing, and the exact cancellation log.
- If the process fails before `initialize`, investigate spawn, PATH, or package-runner errors instead.
Scope
Environment and version notes
- The detailed reproduction used Claude Desktop 1.25927.0 on macOS with uvx; it does not prove identical Windows behavior.
- The issue remained open on August 20, 2026. Claude Code CLI 2.1.237 was current in npm, but CLI and Desktop version lines are different products.
- Sources rechecked August 20, 2026.
Evidence
Sources
Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.
Exact 60-second initialize timing, cold/warm measurements, and pre-warm/pin workarounds.
Separate Windows UtilityProcess spawn-timeout report; useful for distinguishing the launch stage.
Related package-runner startup timeout evidence.