[3.19.7 regression] Windows stdio MCP fails: sandbox unsupported_platform

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After auto-updating from Cursor 3.18.25 to 3.19.7 on Windows 10 x64, all of my local stdio MCP servers stopped working. They were fine on 3.18.25 with the same ~/.cursor/mcp.json config.

Affected servers are local command-based MCPs (e.g. GitHub MCP via github-mcp-server.exe, Jira via uvx mcp-atlassian). Remote HTTP/OAuth MCP plugins (Slack, Atlassian marketplace) still work.

The servers never start. MCP logs show:

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
Also at startup:

Sandbox prerequisites configured for stdio MCP: supported=false
This looks like a 3.19.7 regression on Windows. On 3.18.25 (same machine, same settings, networkControlsEnabled=true, mcpNetworkMode=allow_all), stdio MCP sandbox spawned and servers connected successfully. The first failure on my machine was ~2 minutes after a background auto-update from 3.18.25 → 3.19.7 on 2026-09-03 evening.

The MCP server binaries themselves are fine — launching github-mcp-server.exe stdio directly outside Cursor works and connects normally. Tokens and config are not the issue; Cursor never gets far enough to start the process.

Workaround: Downgrade to 3.18.25 and set “update.mode”: “none” in user settings.

Steps to Reproduce

On Windows 10/11 x64, install Cursor 3.19.7 (or auto-update from 3.18.25).
Add one or more stdio MCP servers in ~/.cursor/mcp.json, for example:
{
“mcpServers”: {
“github”: {
“command”: “C:\Program Files\GitHub MCP\github-mcp-server.exe”,
“args”: [“stdio”],
“env”: {
“GITHUB_PERSONAL_ACCESS_TOKEN”: “${env:GITHUB_TOKEN}”,
“GITHUB_HOST”: “https://github.com
}
}
}
}
Ensure GITHUB_TOKEN (or equivalent) is set in the environment Cursor inherits.
Restart Cursor.
Open Customize → MCPs (or start an agent session that loads MCP).
Observe the GitHub (and any other stdio) server shows an error / 0 tools.

Expected Behavior

MCP servers connect

Operating System

Windows 10/11

Version Information

IDE 3.19.7

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @Zhou_Fang thanks for the detailed writeup!

This isn’t the 3.19.7 update itself - it’s your team’s Enterprise MCP network controls. Local stdio servers you add yourself get run under a sandbox that isn’t supported on Windows yet, so Cursor blocks them (remote HTTP servers skip the sandbox, which is why those still work). It’s driven by your team’s MCP policy, not the app version, so downgrading isn’t a reliable fix.

Ask your Cursor admin to add your local servers to the team MCP allowlist under Team Settings → MCP Configuration as Command entries (e.g. *github-mcp-server.exe*, uvx mcp-atlassian*) with network mode No sandbox - those start normally on Windows and it fixes it for your whole team at once. Docs: MCP admin controls.

We’ve let the team know about the Windows limitation here. Let me know once your admin adds those entries.