[BUG] Windows: MCP extension spawn fails with "spawn UNKNOWN" when command is 'uv' — binary exists but OS denies execution (Smart App Control)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest related: #68858, #38266 — both are about uv build-time failures after successful spawn; this is a failure to spawn at all)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code / Claude Desktop

What's Wrong?

The Windows-MCP extension (ant.dir.cursortouch.windows-mcp, installed via Claude Extensions) fails to start on Windows with:

MCP Windows-MCP: spawn UNKNOWN
Could not connect to MCP server Windows-MCP

Server config (from Claude Desktop's connector panel):

• Command: uv
• Args: --directory C:\Users\<user>\AppData\Roaming\Claude\Claude Extensions\ant.dir.cursortouch.windows-mcp run windows-mcp
• Error: spawn UNKNOWN

This is distinct from #68858 / #38266: those describe uv successfully starting a build and then failing with os error 32 during temp-directory cleanup. Here, the process never gets that far — spawn UNKNOWN indicates the child process could not be created at all.

Diagnosis performed:

• uv.exe is confirmed installed and on PATH (where uv → C:\Users\<user>\.local\bin\uv.exe).
• Attempting to execute uv.exe directly (from a shell) returns "Permission denied" — the binary exists but the OS refuses to execute it.
• This matches Microsoft's documented Smart App Control block behavior (blocking unsigned/unrecognized executables), consistent with the timing: the failure started after a Windows restart, with no changes to the extension or its config.

What Should Happen?

Either:

1. Claude Desktop should surface a clearer error distinguishing "OS refused to spawn the process" (permission/policy block) from other spawn failures, so users aren't left guessing between antivirus, missing PATH entries, or a Claude-side bug, or
2. If uv/extension binaries used by first-party/community extensions are unsigned, consider documenting this as a known Smart App Control conflict so users can self-diagnose, since the current spawn UNKNOWN message gives no actionable information.

Steps to Reproduce

1. Install the Windows-MCP extension (ant.dir.cursortouch.windows-mcp) in Claude Desktop on Windows with Smart App Control enabled.
2. Restart Windows.
3. Open Claude Desktop — the connector panel shows Windows-MCP as failed with error spawn UNKNOWN.
4. Confirm uv is installed and on PATH (where uv succeeds).
5. Attempt to run uv.exe directly from a terminal — execution is denied ("Permission denied" / blocked by OS), even though the file is present.

Claude Model

N/A (connector-level failure, not model-specific)

Is this a regression?

Possibly — same setup worked without issue across several previous restarts; started failing after a subsequent Windows restart with no config changes.

Claude Code Version

Claude for Windows app (desktop), MCP Extensions panel

Platform

Windows

Additional Information

Related but distinct issues:

• #68858 — uv-based MCP servers fail with os error 32 during build cleanup (spawn succeeds, build fails)
• #38266 — similar uv venv build race condition

This report is specifically about spawn-time failure (spawn UNKNOWN) before any uv build activity occurs, most likely caused by Windows Smart App Control denying execution of an unsigned uv.exe/extension binary, not a handle-inheritance or build-cleanup race.