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.
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.
We are having the same issue across our entire organization (Enterprise) on Windows. User-configured MCPs no longer work and many of our team members depend on them to do their jobs.
We have not changed any MCP controls and “User MCP extensions” is enabled. This appears to be a regression in the latest release because the same MCP servers work correctly when users downgrade to the version mentioned above.
2026-09-04 20:14:29.283 [error] [Shared MCP process] MCP stdio sandbox unavailable: MCP server "user-postgres_tenant::mcpScope:profile:ZGVmYXVsdA:cfg:ZWI1NDdiYzE" 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 undefined
Enabling the MCP allowlist would require us to manually add every user-configured MCP across the organization. That is not a practical solution and defeats the purpose of allowing user MCP extensions.
Please restore the previous behavior. When “User MCP extensions” is enabled users should be able to add and run their own MCP servers without an administrator adding every command to the organization-wide allowlist.
@janjic-ps@jooze fix is admin-side: Team Settings → MCP Configuration, add your local servers as Command entries with network mode No sandbox. Wildcards work (*postgres*, uvx *), so you don’t need every exact path. They’ll start normally on Windows.
On Windows, user-added stdio MCPs that aren’t allowlisted must run in a sandbox Windows doesn’t support yet, so they’re blocked (remote HTTP servers skip it, which is why those still work). Downgrading to 3.18.25 is a temporary stopgap, not a fix. We’re tracking removing the per-command allowlisting need on Windows, and I’ll update here.
Thanks for the update @mohitjain , but I have to disagree with calling the allowlist a “fix”.
If something worked in 3.18.25 and stopped working in 3.19.7, that’s a regression, not a configuration problem on our side. Nothing changed on our end. We did not touch MCP controls and “User MCP extensions” is still enabled. The only variable is the Cursor version.
The workaround also does not really solve it. Asking admins to maintain a list of every command our users might run, even with wildcards, moves the work onto us for something that used to just work.
Hello! IMO, current Cursor behavior is a clear bug: imagine, some company allows any MCP. And now, in order to use stdio-based-MCP-on-Windows they have to explicitly allow that MCP.
Which means communication with IT in order to fix those MCPs that were used before the Cursor update AND a new communication round for any new MCP. So, “allow all local MCPs” mode is broken in Cursor on Windows.
