Claude Desktop extension channel still ships v0.7.2 without the #358 comtypes cache-race fix - startup race still killing servers

[Andyvich]

Summary

The comtypes gen-cache startup race reported in #357 / #374 and fixed by PR #358 is still hitting users in the wild, because the Claude Desktop extension directory still distributes v0.7.2, which predates the fix. Please push an updated extension build (current release v0.8.5 already contains uia/comtypes_cache.py / safe_get_module()) to the Claude Desktop extension channel.

Environment

• Windows 11 Home, build 26200
• Windows-MCP installed from the Claude Desktop extension directory: %APPDATA%\Claude\Claude Extensions\ant.dir.cursortouch.windows-mcp
• manifest.json / _update_metadata.json: version 0.7.2, downloadedAt = 2026-07-30 — one day before PR Fix corrupted comtypes.gen cache from concurrent generation #358 was merged (2026-07-31)
• CPython 3.13 (uv-managed), comtypes 1.4.16

Fresh occurrence (2026-08-31)

Claude Desktop spawned three server instances within ~25 s (one per session, plus a shared pool). The comtypes cache was being regenerated at that moment; two instances started fine, the third read a partially written module and died:

ImportError: cannot import name 'PropertyConditionFlags_None'
  from 'comtypes.gen._944DE083_8FB8_45CF_BCB7_C477ACB2F897_0_1_0'

Claude log:

2026-08-31T07:52:13.692Z [Windows-MCP] [error] Couldn't start for Cowork and Code sessions. Error: Connection closed
2026-08-31 15:52:13 [error] [LocalMcpServerManager] Failed to connect to Windows-MCP: Connection closed

The gen-cache files (_944DE083...py, UIAutomationClient.py) have mtime 15:52:13 local — exactly the crash moment. Earlier intermittent Server transport closed unexpectedly → "Server disconnected" alerts on 08-25/08-26 match the same pattern. The user experiences this as random "Server disconnected" popups.

Confirmation that the shipped 0.7.2 lacks the fix

In the installed extension:

• src/windows_mcp/uia/comtypes_cache.py does not exist
• src/windows_mcp/uia/core.py:68 still calls comtypes.client.GetModule("UIAutomationCore.dll") directly, no lock, no corrupt-cache recovery

Checked against the repo: src/windows_mcp/uia/comtypes_cache.py is present at tag v0.8.5, so the fix just never reached the extension channel.

Ask

Publish a current build (v0.8.5 or later) to the Claude Desktop / Anthropic extension directory so DXT users get the #358 fix. Until then, every extension install re-hits the race after each venv rebuild or concurrent cold start.

Workaround for other users landing here

Pre-generate the cache once in a single process (with Claude Desktop closed):

uv --directory "$env:APPDATA\Claude\Claude Extensions\ant.dir.cursortouch.windows-mcp" run python -c "import comtypes.client; comtypes.client.GetModule('UIAutomationCore.dll')"

The crash is transient and self-heals once the cache is complete, but it recurs after extension updates rebuild the venv.

[MilkyWay008]

The ImportError on PropertyConditionFlags_None is the classic half-written comtypes.gen cache, and with three server instances spawning in a ~25s window one of them is always reading it mid-write. Easiest reliable fix until the channel gets the v0.8.5 build: fully quit Claude, delete the _944DE083_8FB8_45CF_BCB7_C477ACB2F897_0_1_0 folder under the comtypes.gen dir so it regenerates clean, then pre-warm the cache once with Claude closed (your own one-liner does exactly that). If you want the fix today instead of waiting on the channel, copy uia/comtypes_cache.py from the v0.8.5 tag into the installed extension and switch core.py to safe_get_module()...... that's the #358 change verbatim, and it makes the cache write race-safe so it stops coming back after every venv rebuild.