Editable build fails with WinError 17 (cross-device move) under MSIX Claude Desktop — recurrence of #225 with a different error signature

[jumoras0000]

Environment

• OS: Windows 10 Pro (build 19045)
• Claude Desktop: MSIX/Store-packaged build (Claude_pzs8sxrjxfjjc), app version 1.24012.9.0
• Windows-MCP extension: 0.7.2
• uv: local install at ~/.local/bin/uv.exe (not on PATH by default — separate minor issue, see note below)
• Python: 3.13.12 (uv-downloaded interpreter, fresh venv)

Symptom

Fresh extension activation. First launch fails to resolve uv (spawn uv ENOENT) because uv's install directory isn't on the PATH Claude Desktop's process inherits. After adding it to the persistent User PATH and restarting Claude Desktop, uv is found and the editable build starts, but fails with:

× Failed to build `windows-mcp @ file:///C:/Users/<user>/AppData/Roaming/Claude/Claude%20Extensions/ant.dir.cursortouch.windows-mcp`
├─▶ The build backend returned an error
╰─▶ Call to `setuptools.build_meta.build_editable` failed (exit code: 1)

    [stdout]
    running egg_info
    writing src\windows_mcp.egg-info\PKG-INFO

    [stderr]
    ...
    error: [WinError 17] Impossible de déplacer le fichier vers un lecteur de disque différent: 'C:\\Users\\<user>\\AppData\\Roaming\\Claude\\Claude Extensions\\ant.dir.cursortouch.windows-mcp\\src\\windows_mcp.egg-info\\tmpfd4baf3h' -> 'src\\windows_mcp.egg-info\\PKG-INFO'

    hint: This usually indicates a problem with the package or the build environment.

Reproduced identically across multiple relaunches (different temp filenames each time, same WinError 17).

Relation to #225

This is the same underlying root cause as #225 ("Extension fails to launch on MSIX-installed Claude Desktop (uv editable build error)", closed as completed with 0 comments): MSIX filesystem virtualization of %APPDATA%\Roaming\Claude\... (backed by %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\...) causes setuptools to fail during the editable build. #225 hit it as error in 'egg_base' option: '.' does not exist; this report hits it as WinError 17 during the egg_info → PKG-INFO rename. Different symptom, same trigger (an atomic file operation inside setuptools' build_editable crossing the MSIX virtualization boundary), so I don't believe #225's fix (if any landed) fully closed this — it was closed with no comments/commit reference, and the failure mode is still present on 0.7.2.

What we tried (from outside the extension) and why it didn't work

Since the failing move is between uv's global cache (%LOCALAPPDATA%\uv\cache\builds-v0\..., real filesystem) and the extension's virtualized directory, we tried redirecting the cache/temp location to somewhere inside the same virtualized tree:

1. Set UV_CACHE_DIR as a persistent User environment variable → no effect, build still used the default %LOCALAPPDATA%\uv\cache.
2. Set TEMP/TMP as persistent User environment variables → no effect either, identical WinError 17.

Both had no effect because Claude Desktop appears to launch extension-managed MCP servers with a curated environment — only the variables declared in the manifest's server.mcp_config.env (MODE, ANONYMIZED_TELEMETRY, API_KEY, etc.) plus PATH are passed through; arbitrary OS-level user env vars are not inherited by the child process. (PATH visibly reaches the child — confirmed via the host's own debug log line Using MCP server command: ... with path: { paths: [...] } — but UV_CACHE_DIR/TEMP changes never showed up in build behavior.)

Suggested fixes (priority order)

1. Best: stop doing an editable/source build on every launch. Publish a wheel and have manifest.json invoke uvx windows-mcp (as already suggested in Windows Store version of Claude: ${__dirname} resolves to wrong path, causing build failure #209, and consistent with server.json's existing runtime_hint: "uvx") or uv pip install a prebuilt wheel. This sidesteps the MSIX virtualization + setuptools interaction entirely.
2. Alternative: point mcp_config.command/args at the prebuilt ${__dirname}/.venv/Scripts/windows-mcp.exe after a one-time sync step, as the Extension fails to launch on MSIX-installed Claude Desktop (uv editable build error) #225 reporter's manual workaround did.
3. If the editable build must stay for now: declare UV_CACHE_DIR (and/or TMPDIR) inside the manifest's own env block, pointed at a subfolder of ${__dirname} (e.g. ${__dirname}/.uv-cache). Since manifest-declared env vars do reach the child process (unlike external OS env vars, per our testing above), this keeps the build's temp/cache files inside the same virtualized tree as the destination and should avoid the cross-device error without changing the install strategy.

Also worth a mention in setup docs: uv's own installer doesn't always land on the persistent Windows PATH (e.g. install via ~/.local/bin), which causes the separate spawn uv ENOENT failure mode on first activation until the user manually restarts their PATH-consuming apps.

Repro steps

1. Install Claude Desktop (MSIX/Store build).
2. Install the Windows-MCP extension (0.7.2).
3. Ensure uv is reachable via PATH.
4. Activate/launch the extension — editable build starts, fails with WinError 17 as above, every time.

[Jeomon]

Applied your suggested incremental fix (option 3) in 7f3c4c8: manifest.json's mcp_config.env now sets UV_CACHE_DIR to ${__dirname}/.uv-cache, keeping uv's build cache on the same side of the MSIX virtualization boundary as the destination directory, instead of the default (a real, unvirtualized path under %LOCALAPPDATA%).

Didn't touch TMP/TEMP — those get inherited by every child process the server spawns (PowerShell, etc.), and redirecting them globally risks the same kind of leak #350 flagged for PYTHONHOME. If UV_CACHE_DIR alone doesn't fully resolve the WinError 17 for you, that's the next thing to try, scoped narrowly rather than globally.

I don't have an MSIX-packaged Claude Desktop + Windows 10 setup to reproduce this against, so I can't confirm this fully closes the loop — could you retest on a fresh activation and report back whether the egg_info/PKG-INFO rename still fails? Leaving this open until confirmed.