Cursor 3.19.7 on Windows: stdio MCP servers never start: `MCP stdio sandbox unavailable: MCP server requires sandboxing because MCP Network Controls are enabled` (unsupported_platform)

发生场景

Source(s): https://forum.cursor.com/t/3-19-7-regression-windows-stdio-mcp-fails-sandbox-unsupported-platform/170634 Signal: 326 views, 8 likes; staff answered twice; a second Enterprise organization reported the same problem across all its Windows users (September 2026). Status: reported working by source, not reproduced by us (workaround only; staff's admin-side fix was not confirmed by a user in the thread).

问题

After Cursor auto-updates from 3.18.25 to 3.19.7 on Windows, every local command-based (stdio) MCP server shows an error or 0 tools and never starts, while remote HTTP/OAuth MCP servers keep working. The same server binaries run fine outside Cursor.

报错原文（已脱敏/规范化）

MCP stdio sandbox unavailable: MCP server requires sandboxing because MCP Network Controls are enabled, but the sandbox is not supported on this platform or system. The server was not started.; sandboxFailureReasonClass=unsupported_platform

Sandbox prerequisites configured for stdio MCP: supported=false

适用环境

Windows 10/11 x64, Cursor 3.19.7, a Cursor Enterprise team with MCP Network Controls enabled ("User MCP extensions" also enabled).

如何确认是这个问题

1. The MCP logs contain the error above with sandboxFailureReasonClass=unsupported_platform. → expect: the server is never launched.
2. Your Cursor account belongs to a team that has MCP Network Controls turned on (staff said the team policy, not the app version, triggers it).

不是这个问题时 / 边界

You are not on a team with MCP Network Controls, or you are on macOS/Linux; staff tied the block to Windows plus the team policy (our inference from the staff replies). Staff also said they are working on removing the per-command allowlist requirement on Windows, so a later version may behave differently.

根因

Staff said that with the team's MCP Network Controls on, user-added stdio servers that are not on the team allowlist must run in a sandbox that Cursor does not support on Windows yet, so Cursor blocks them; remote HTTP servers skip the sandbox. Users pointed out the same setup worked on 3.18.25, so the change shipped with 3.19.7.

修复步骤

1. Staff fix (admin-side, not confirmed by a user in this thread): a Cursor team admin adds the local servers under Team Settings → MCP Configuration as Command entries with network mode "No sandbox"; wildcards work (staff examples: *github-mcp-server.exe*, *postgres*). Staff said those then start normally on Windows.
2. Workaround: go back to Cursor 3.18.25 and set "update.mode": "none" in user settings. → expect: the original poster and a second Enterprise user said stdio MCP servers work again on 3.18.25.

如何验证

The stdio servers show their tools again in Customize → MCPs, and the log no longer shows MCP stdio sandbox unavailable.

试过没用的办法

Downgrading is described by staff as "a temporary stopgap, not a fix", because the block is driven by team policy.

风险提示

"No sandbox" means those commands run without the MCP network sandbox. Keep the allowlist to commands you trust and avoid broad patterns that let any package run unsandboxed (our inference). Staying on 3.18.25 with updates off means missing later fixes; turn updates back on once a fixed version is out (our inference).

验证范围

Cursor 3.19.x on Windows for Enterprise teams with MCP Network Controls enabled, September 2026.

何时失效

Cursor supports the stdio MCP sandbox on Windows, or no longer requires per-command allowlisting there.