[BUG] Windows-MCP extension fails with os error 4551 (Application Control Policy) on MSIX build v1.1.4498

Resolved 💬 2 comments Opened Feb 27, 2026 by thomasbay3r Closed Mar 27, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Windows-MCP desktop extension fails to connect with os error 4551 (Application Control Policy blocked). The extension was working correctly on this system at some point before the current version, but it's unclear which update introduced the regression.

Environment

  • Claude Desktop Version: 1.1.4498 (24f768)
  • OS: Windows 11
  • Installation type: MSIX (Store)
  • windows-mcp version: 0.6.0

Error from mcp-server-Windows-MCP.log:

error: Failed to spawn: `windows-mcp`
  Caused by: An Application Control policy has blocked this file. (os error 4551)

Root Cause Analysis

Update: Root cause identified
The blocking is caused by Windows Smart App Control (SAC), not AppLocker or WDAC as initially suspected. Windows 11 shows a notification at startup indicating SAC blocked part of the app, linking to: https://support.microsoft.com/de-de/windows/smart-app-control-hat-einen-teil-dieser-app-blockiert-0729fff1-48bf-4b25-aa97-632fe55ccca2
SAC blocks unsigned executables and cannot be configured with per-file exceptions – it's all-or-nothing. The fix therefore requires Anthropic to code-sign the windows-mcp.exe that gets bundled into the MSIX extension directory. Once signed, SAC will allow execution.
Note: The Schutzverlauf (Protection History) in Windows Security was not accessible to verify the exact blocked file, as a third-party AV (Avira) overrides the Windows Defender UI.
/Update: Root cause identified

Cowork runs as an MSIX/UWP app and attempts to spawn windows-mcp directly (not via uvx). The extension installs windows-mcp.exe into the virtualized MSIX container path:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\...\ant.dir.cursortouch.windows-mcp\.venv\Scripts\windows-mcp.exe

Windows Application Control Policy blocks execution of this unsigned EXE from within the MSIX sandbox context.

Confirmed working: uvx windows-mcp and the EXE installed via uv tools both run without issues from a normal PowerShell session. The problem is specific to the MSIX process context.

Attempted Workarounds (all failed)

This bug report was written with the help of Claude after extensive troubleshooting. The following approaches were attempted and all failed:

  1. Unblock-File on the extension EXE → no Zone.Identifier present, had no effect
  2. AppLocker checkGet-AppLockerPolicy -Effective shows empty rule collections, not the cause
  3. Copying windows-mcp.exe to %USERPROFILE%\.local\bin\ (which is in PATH) → still blocked
  4. Copying uvx.exe to C:\Windows\System32\uvx is not the issue; Cowork spawns windows-mcp directly
  5. Copying windows-mcp.exe to C:\Windows\System32\ → still blocked (unsigned EXE blocked regardless of location)
  6. Toggle extension off/on → no effect
  7. Full app restart via Task Manager → no effect on MCP connection

The core issue is that the EXE installed by Cowork into the MSIX virtualized filesystem is unsigned and cannot be executed from within the MSIX sandbox. A possible fix would be to either sign the bundled EXE, or have Cowork invoke uvx windows-mcp using an absolute path to uvx instead of spawning windows-mcp directly.

What Should Happen?

Windows-MCP extension should connect successfully after one-click installation via the Extensions directory.

Related Issues

  • #27492 (Cowork MCP issues after 1.1.3189)
  • #26073 (MSIX wrong config path)
  • #25385 (Windows installation failures)

Error Messages/Logs

Steps to Reproduce

  1. Install Claude Desktop v1.1.4498 (MSIX) on Windows 11
  2. Open Settings → Extensions → Browse Extensions
  3. Install "Windows-MCP" extension
  4. Observe error toast: "Could not attach to MCP server Windows MCP"
  5. Check log at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\mcp-server-Windows-MCP.log → shows os error 4551

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.50 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗