Venv breaks on Microsoft Store Python patch updates; pin a uv-managed interpreter instead

[bokology]

Windows-MCP log excerpts — venv broken by Store Python patch update

Extension: ant.dir.cursortouch.windows-mcp (windows-mcp 3.2.0)
Host: Claude Desktop, Windows 11
Interpreter: Microsoft Store Python (PythonSoftwareFoundation.Python.3.13)

All excerpts are verbatim from mcp-server-Windows-MCP.log. Ellipses ([...])
mark omitted repetitive lines only.

---

1. Baseline: earlier healthy venv rebuilds install the full dependency set

2026-04-14 (interpreter: CPython 3.13.12):

Using CPython 3.13.12 interpreter at: C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.13_qbz5n2kfra8p0\python.exe
Creating virtual environment at: .venv
   Building windows-mcp @ file:///C:/Users/<user>/AppData/Roaming/Claude/Claude%20Extensions/ant.dir.cursortouch.windows-mcp
[...]
      Built pyperclip==1.9.0
      Built windows-mcp @ file:///C:/Users/<user>/AppData/Roaming/Claude/Claude%20Extensions/ant.dir.cursortouch.windows-mcp
Installed 113 packages in 31.76s

2026-05-04 (interpreter now CPython 3.13.13 — previous Store patch update, rebuild succeeded):

Using CPython 3.13.13 interpreter at: C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.13_qbz5n2kfra8p0\python.exe
Creating virtual environment at: .venv
[...]
Installed 114 packages in 48.47s

---

2. Trigger: Store Python patch update to 3.13.14 invalidates the venv; rebuild completes partially (1 package)

2026-07-21, 20:35–20:39 UTC:

2026-07-21T20:35:56.415Z [Windows-MCP] [info] Initializing server... { metadata: undefined }
2026-07-21T20:35:59.311Z [Windows-MCP] [info] Server started and connected successfully { metadata: undefined }
2026-07-21T20:36:00.869Z [Windows-MCP] [info] Message from client: method="initialize" id=0 params { metadata: undefined }
Using CPython 3.13.14 interpreter at: C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.13_qbz5n2kfra8p0\python.exe
Removed virtual environment at: .venv
Creating virtual environment at: .venv
warning: Failed to hardlink files; falling back to full copy. This may lead to degraded performance.
         If the cache and target directories are on different filesystems, hardlinking may not be supported.
         If this is intentional, set `export UV_LINK_MODE=copy` or use `--link-mode=copy` to suppress this warning.
2026-07-21T20:37:01.313Z [Windows-MCP] [info] Message from client: method="notifications/cancelled" params { metadata: undefined }
2026-07-21T20:37:01.314Z [Windows-MCP] [info] Client transport closed { metadata: undefined }
2026-07-21T20:37:01.314Z [Windows-MCP] [info] Server transport closed (renderer released port) { metadata: undefined }
[...]
Installed 1 package in 39.54s
2026-07-21T20:39:25.058Z [Windows-MCP] [info] Message from client: method="notifications/cancelled" params { metadata: undefined }

Note: the rebuild installed 1 package where every previous rebuild installed
113–114. pywin32 (a declared dependency, pywin32>=311 at pyproject.toml:40)
was left out of the environment.

---

3. Result: every launch fails on import before the MCP handshake completes

First occurrence, 2026-07-21 ~20:39 UTC (identical tracebacks repeat on every
launch attempt through 2026-07-22 09:02 UTC):

Server exiting due to unhandled exception
Traceback (most recent call last):
  File "C:\Users\<user>\AppData\Roaming\Claude\Claude Extensions\ant.dir.cursortouch.windows-mcp\src\windows_mcp\__main__.py", line 193, in main
    _run_local_mode(transport=transport, host=host, port=port)
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\<user>\AppData\Roaming\Claude\Claude Extensions\ant.dir.cursortouch.windows-mcp\src\windows_mcp\__main__.py", line 118, in _run_local_mode
    local_mcp = _build_local_mcp()
  File "C:\Users\<user>\AppData\Roaming\Claude\Claude Extensions\ant.dir.cursortouch.windows-mcp\src\windows_mcp\__main__.py", line 44, in _build_local_mcp
    from windows_mcp.desktop.service import Desktop
  File "C:\Users\<user>\AppData\Roaming\Claude\Claude Extensions\ant.dir.cursortouch.windows-mcp\src\windows_mcp\desktop\service.py", line 1, in <module>
    from windows_mcp.desktop.utils import (
    ...<3 lines>...
    )
  File "C:\Users\<user>\AppData\Roaming\Claude\Claude Extensions\ant.dir.cursortouch.windows-mcp\src\windows_mcp\desktop\utils.py", line 13, in <module>
    from win32com.shell import shell
ModuleNotFoundError: No module named 'win32com.shell'

Host-side view of the same failure (repeats on each attempt):

2026-07-22T09:00:30.210Z [Windows-MCP] [info] Server transport closed unexpectedly, this is likely due to the process exiting early. If you are developing this MCP server you can add output to stderr (i.e. `console.error('...')` in JavaScript, `print('...', file=sys.stderr)` in python) and it will appear in this log. { metadata: undefined }
2026-07-22T09:00:30.210Z [Windows-MCP] [error] Server disconnected. For troubleshooting guidance, please visit our [debugging documentation](https://modelcontextprotocol.io/docs/tools/debugging) { metadata: { context: 'connection', stack: undefined } }

User-visible symptom in Claude Desktop: toast "Could not attach to MCP server
Windows-MCP" with no cause or remediation shown. The broken state persisted
across every restart from 2026-07-21 20:39 to 2026-07-22 09:02 with no
automatic re-sync or recovery.

---

4. Resolution (manual)

With Claude Desktop fully quit:

cd "$env:APPDATA\Claude\Claude Extensions\ant.dir.cursortouch.windows-mcp"
Remove-Item -Recurse -Force .venv
uv sync
uv run python -c "from win32com.shell import shell; print('pywin32 OK')"
# -> pywin32 OK  (pywin32 311 present; pyproject.toml:40 declares "pywin32>=311")

Server attaches normally after relaunch.

---

Suggested fix

Since uv is already the launcher, pin a uv-managed interpreter (uv python install 3.13 + a version pin resolved against uv's own toolchain)
instead of resolving the Microsoft Store Python. The Store interpreter is the Windows 11 default and changes its versioned install path on silent patch updates (observed here at 3.13.12 → .13 → .14), so venv invalidation on update is the common case on stock machines, not an edge case. Secondarily, a startup guard that catches ImportError for required modules and emits a clear "environment broken — re-run sync" message would make the host-side error actionable.