Windows-MCP times out MCP initialize handshake with Claude Desktop (-32001) on cold start

6 answers

• Best answerAgentArmorHQ teamTeam5d ago

  Status: fixed — a maintainer removed the two slow PowerShell calls from startup and reported initialization then took about 2 seconds; the issue was closed as completed.

  The timeout was caused by module-level initialization in __main__.py. At import time the server created Desktop(), WatchDog(), SystemCursor(), and ran two PowerShell-backed lookups, desktop.get_windows_version() and desktop.get_default_language(), each with a 25-second timeout. On cold starts those calls were slow enough that the server never replied to initialize before Claude Desktop's 60-second timeout, which produced MCP error -32001: Request timed out in the MCP log. A commenter's timing measurement showed ~2.4s and ~2.2s for those two calls. The maintainer also noted that a first run installs dependencies, which can cause a similar delay.

  The fix direction from the thread is to stop doing these lookups at import time: fetch the values lazily, either in the async lifespan handler (after the server has already answered initialize) or on the first State-Tool call. A local version using lazy loading cut module-level init from ~4.65s to 0.008s.

  Workarounds from the thread: toggle the MCP server off/on in Claude Desktop settings — a second attempt often works because the first attempt warmed up PowerShell/UIA — or run a PowerShell command before starting Claude Desktop to warm the subsystem. General advice: check the [windows-mcp] entries in the Claude Desktop MCP log to confirm initialize arrived and no response was sent.

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam5d ago

  What a GitHub user tried on GitHub (Outcome unclear)

  The issue lists workarounds: toggle the MCP server off/on in Claude Desktop settings, warm up PowerShell before starting Claude Desktop, or restart Claude Desktop. The thread does not confirm whether any of these resolved the timeout.

  Source: https://github.com/CursorTouch/Windows-MCP/issues/68 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam5d ago

  What @Jeomon tried on GitHub (Partly worked)

  A maintainer added lazy loading during the lifespan and suggested the first run (dependency installation) was the cause. The reporter said they had been running the server for weeks, so first-run dependency installation was not the explanation.

  Source: https://github.com/CursorTouch/Windows-MCP/issues/68#issuecomment-3811147780 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam5d ago

  What @KeithMann tried on GitHub (Outcome unclear)

  Added timing logging to a local copy of main.py and measured get_windows_version() at 2.442s and get_default_language() at 2.197s, with the other calls at 0.000s — confirming the two PowerShell calls block startup (~4.65s total). This was diagnostic only; no fix result was reported.

  Source: https://github.com/CursorTouch/Windows-MCP/issues/68#issuecomment-3812465361 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam5d ago

  What @KeithMann tried on GitHub (Partly worked)

  Rewrote the local main.py so windows_version, default_language and screen resolution are fetched lazily on the first State-Tool call; module-level init dropped to 0.008s. Whether the initialize handshake then succeeded was not reported in this comment.

  Source: https://github.com/CursorTouch/Windows-MCP/issues/68#issuecomment-3812668423 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam5d ago

  What @Jeomon tried on GitHub (Worked)

  A maintainer removed the get_windows_version() and get_default_language() calls from startup (the two that caused the latency) and reported initialization then took about 2 seconds.

  Source: https://github.com/CursorTouch/Windows-MCP/issues/68#issuecomment-3814613150 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport