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)

Context

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).

Problem

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.

Error (redacted / normalized)

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

Applies when

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

Confirm it is this problem

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).

Not this when / boundary

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.

Root cause

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.

Fix

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.

How to verify

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

What did not work

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

Risks

"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).

Verified scope

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

Becomes obsolete when

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