Local stdio MCP server fails with "access denied for socket file" when spawned by MSIX-packaged Claude Desktop on Windows (works fine under Codex on the same machine)

Title

Local stdio MCP server fails with "access denied for socket file" when spawned by MSIX-packaged Claude Desktop on Windows (works fine under Codex on the same machine)

Summary

On Windows, a local stdio-based MCP server (MATLAB's matlab-mcp-server.exe, part of the MATLAB/Simulink Agentic Toolkit) that uses a Unix-domain socket for internal parent↔watchdog IPC fails to initialize 100% of the time when spawned by Claude Desktop, with the error access denied for socket file. The identical binary, invoked by Codex on the same machine against the same running MATLAB session, connects successfully. This points to a difference in how Claude Desktop (on Windows, MSIX-packaged) spawns/manages child MCP server processes compared to other MCP clients.

Environment

• OS: Windows 11 Enterprise 10.0.22631
• Claude Desktop: installed via ClaudeSetup.exe from claude.com/download (not Microsoft Store)
• Get-AppxPackage shows PackageFullName: Claude_1.17377.2.0_x64__pzs8sxrjxfjjc, SignatureKind: Developer (sideloaded MSIX, not Store-acquired)
• No legacy Squirrel install remnants present (AppData\Local\AnthropicClaude does not exist) — appears to be a clean MSIX install, not a failed Squirrel→MSIX migration
• Claude Code CLI (bundled): C:\Users\<user>\AppData\Roaming\Claude\claude-code\2.1.197\claude.exe
• MCP server: MATLAB/Simulink Agentic Toolkit, matlab-mcp-server.exe v0.11.1 (github.com/matlab/matlab-mcp-server v0.11.1)
• MCP server config (from .claude.json):

``json
"matlab": {
"command": "C:/Users/<user>/.matlab/agentic-toolkits/bin/matlab-mcp-server.exe",
"args": [
"--matlab-session-mode=existing",
"--extension-file=C:/Users/<user>/.matlab/agentic-toolkits/simulink/tools/tools.json"
],
"alwaysLoad": true
}
``

Steps to reproduce

1. Install MATLAB R2026a + the MATLAB/Simulink Agentic Toolkit (which registers a matlab-mcp-server.exe stdio MCP server pointed at an existing/shared MATLAB session).
2. Have MATLAB running with the Connector active (confirmed via the toolkit's own install-check script: MATLAB connector running (port 31516) — PASS).
3. Open Claude Desktop / Claude Code with the matlab MCP server configured as above.
4. Observe the MCP connection fails every time.

Expected behavior

The matlab MCP server connects successfully and exposes its tools, as it does under Codex against the same MATLAB session on the same machine.

Actual behavior

Every connection attempt fails identically. From mcp-logs-matlab/*.jsonl (Claude Code's own MCP client log):

{"debug":"Starting connection with timeout of 30000ms", ...}
{"error":"Server stderr: Failed to initialize MCP Server. For details, see the MCP server log in your AI application.\n", ...}
{"debug":"Connection failed after ~530ms: MCP error -32000: Connection closed", ...}
{"error":"Connection failed: MCP error -32000: Connection closed", ...}

From the MCP server's own structured log (%TEMP%\matlab-mcp-server-<random>\server-<id>.log):

{"level":"INFO","msg":"Initiating application startup","version":"github.com/matlab/matlab-mcp-server v0.11.1"}
{"level":"INFO","msg":"Configuration state", ... "MATLABSessionMode":"existing", ...}
{"level":"INFO","msg":"Application directory state","log-dir":"C:\\Users\\...\\Temp\\matlab-mcp-server-<random>","id":"<id>"}
{"level":"ERROR","msg":"Failed to connect to watchdog socket","error":"access denied for socket file"}
{"level":"INFO","msg":"Initiating application shutdown"}
{"level":"ERROR","msg":"Server failed with unexpected error","error":"access denied for socket file"}

From the watchdog's own log (watchdog-<id>.log), the watchdog itself starts fine and creates the socket:

{"level":"INFO","msg":"Watchdog process has started"}
{"level":"INFO","msg":"Server started","socketPath":"C:\\Users\\...\\Temp\\matlab-mcp-server-<random>\\watchdog-<id>.sock"}
{"level":"INFO","msg":"Trying to terminate children","count":0}
{"level":"INFO","msg":"Watchdog process has exited"}
{"level":"ERROR","msg":"Failed to stop server","error":"unlinkat ...watchdog-<id>.sock: The file cannot be accessed by the system."}

Timing is remarkably consistent across many independent attempts (534ms, 544ms, 530ms, 527ms) — this does not look like a race against an external scanner, but a deterministic internal failure.

What we ruled out

We suspected antivirus interference (a common cause of "file briefly locked right after creation" symptoms on Windows) and tested extensively:

• Added a Windows Defender folder exclusion for %TEMP% → no change, error identical.
• Confirmed via Defender's own event log (event ID 5007) that the exclusion registered successfully.
• Added a Windows Defender process exclusion for matlab-mcp-server.exe → no change, error identical.
• Paused Dropbox sync (the project directory lives under a Dropbox-synced path, and Dropbox's filesystem filter driver was a suspect) → no change, error identical.
• Confirmed no third-party AV/EDR agent is present (Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct shows only Windows Defender; no CrowdStrike/SentinelOne/etc. processes running).
• Confirmed Controlled Folder Access is disabled, and no ASR rules are configured.

We then suspected MSIX/Desktop-Bridge process sandboxing (since Claude Desktop's GUI process runs from C:\Program Files\WindowsApps\Claude_1.17377.2.0_x64__pzs8sxrjxfjjc\, and the CLI/MCP-spawning process is its descendant) and tested:

• whoami /groups on the process that spawns the MCP server shows no APPLICATION PACKAGE AUTHORITY or CAPABILITY SIDs — it is a normal Medium-integrity token, not an AppContainer.
• The package's AppContainer-redirected temp folder (AppData\Local\Packages\Claude_pzs8sxrjxfjjc\AC\Temp) is empty — the socket/log files are being created in the real %TEMP%, not a virtualized copy, and both the watchdog and main server process clearly agree on and use that same real path (confirmed by reading identical file contents from the real path across every attempt).
• So classic AppContainer sandboxing / per-process filesystem virtualization does not appear to be the direct mechanism, even though it was our leading hypothesis given the MSIX packaging.

Comparative evidence (strongest lead)

The MATLAB/Simulink Agentic Toolkit's own install-check script reports a full PASS on this machine (MATLAB Connector running on port 31516, matlab-mcp-server.exe found, entry points on path). The user confirmed that Codex, run on this same machine against this same MATLAB session, connects to this MCP server successfully. Only Claude Desktop fails. This strongly suggests the root cause lies in how Claude Desktop's Windows build spawns/manages this child process (e.g. CreateProcess flags, handle inheritance, job-object assignment, or some other artifact of being launched from an MSIX-packaged parent) rather than in the MCP server binary itself or the user's environment/security software.

Suggested investigation areas for maintainers

• Compare the exact CreateProcess/child_process.spawn invocation (flags, inherited handles, job object assignment, environment block) Claude Desktop uses to launch stdio MCP servers on Windows against a known-working client (e.g. Codex).
• Check whether Claude Desktop's MSIX packaging places spawned child processes into a Job Object with restrictions that could affect local IPC primitives (Unix-domain sockets are implemented via reparse-point files on Windows; some filter drivers/job-object restrictions are known to interact poorly with reparse-point handling).
• Reproduce with any other local stdio MCP server that uses a Unix-domain socket internally (not just this MATLAB toolkit) to determine whether this is specific to matlab-mcp-server.exe or a general problem for this class of MCP server on Windows.

Attachments available on request

Full raw log files (server-*.log, watchdog-*.log, mcp-logs-matlab/*.jsonl) from multiple reproduction attempts are available.