MCP Issues with Cursor SDK

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

HTTP MCP Does not work with cursor SDK sandbox enabled : sandboxOptions: { enabled: true } , Using MCP with Oauth even though its configured and authenticated with Cursor App - is not working - it errors saying

“Local SDK runs cannot request interactive approval”.

It only works when sandboxOptions is set to False.

Tried it with user level and project level mcps both have same issues. Can you fix this please. Its blocking us as we want sandbox to prevent it going out of the current working directory.

We are not allowed to use cursor without Sandboxing.

Steps to Reproduce

Configure Oauth MCP in Cursor Desktop App
add mcp.json to Project directory
Point SDK to project directory and run with sandboxOptions enable to True
MCP Errors out,
Disable sandboxOptions enable by setting to False, Try MCP Again
It should work.

  1. Configure any HTTP MCP server in ~/.cursor/mcp.json OR /.cursor/mcp.json that Cursor desktop has flagged as approval-required (e.g. via OAuth sign-in flow).
  2. Agent.create({ …, local: { sandboxOptions: { enabled: true } } }) and agent.send(“call ”).
  3. Tool always rejected; sandbox can’t surface a UI prompt.

Expected: an option to pre-approve specific MCP servers/tools for sandboxed Local SDK runs, or a mcpServers[…].trust: true (or approvalMode: ‘auto’) flag on the per-server config.

Expected Behavior

MCPs should work from Project level at the least with sandboxOptions set to True

Operating System

MacOS

Version Information

@cursor/[email protected]

For AI issues: which model did you use?

Composer 2.5 - Fast : False

For AI issues: add Request ID with privacy disabled

7b5fc2a3-969e-4cae-9d57-df257a6b86df   2026-05-26 14:06 UTC
e2353ab0-8c4e-46b7-8d14-00222ca29ffa   2026-05-26 13:45 UTC
f4a15aab-0d5d-4071-8035-331bcc15053d   2026-05-26 13:40 UTC

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

This is a known limitation with the local SDK. When you enable sandboxOptions, the SDK runs in headless mode with no interactive approval flow. The sandbox approval provider blocks all MCP tool calls that need approval, not just OAuth ones, and there’s currently no mechanism to pre-approve or trust specific MCP servers within a sandboxed local SDK run.

There’s also a separate gap: the local SDK can’t access OAuth tokens stored by the Cursor desktop app, even though the docs say it should reuse saved logins. The cloud SDK has a fix for this, but the local SDK doesn’t have an equivalent path yet. Our team is aware and tracking both issues.

For your use case (sandbox required for compliance), the recommended path is cloud SDK mode. Cloud agents run inside isolated VMs, which provides sandboxing at the infrastructure level without needing sandboxOptions. Cloud mode also supports OAuth MCP credentials from the backend:

const agent = await Agent.create({
apiKey: process.env.CURSOR_API_KEY,
model: { id: "composer-2.5-fast" },
cloud: {
envVars: { /* any env vars needed */ },
},
mcpServers: {
yourServer: {
type: "http",
url: "https://your-mcp-server.example.com/mcp",
headers: { Authorization: `Bearer ${process.env.YOUR_API_KEY}` },
},
},
});

If cloud mode isn’t viable for your setup, the only current local workaround is disabling sandboxOptions and using inline MCP configs with explicit headers — but I understand that doesn’t meet your compliance requirements.

You may also find this related thread helpful: SDK local agents cannot access HTTP MCPs with OAuth from settingSources

Let me know if the cloud SDK approach works for your team’s requirements.

8

Thanks, Issue with Cloud SDK is that the MCP is only available On-Prem need some kind of tunnel/vpn for cloud to reach Onprem. If we could have something like running “agent worker tunnel” onprem which asks to sign in once and registers available MCPs to cloud. Then have cloud agent sdk tunnel mcp to onprem ? I know this is a feature request but some solution to onprem MCPs will be good.

9

What you’re describing is actually close to an existing feature: Self-Hosted Cloud Agents.

Instead of tunneling MCP calls from cloud VMs back to your network, the agent worker itself runs on your infrastructure. Since the worker is on your network, it can reach your on-prem MCP servers directly.

The SDK supports this via env: { type: "pool" }:

const agent = await Agent.create({
apiKey: process.env.CURSOR_API_KEY,
model: { id: "composer-2.5-fast" },
cloud: {
env: { type: "pool" },
repos: [{ url: "https://github.com/your-org/repo" }],
},
mcpServers: {
yourServer: {
type: "http",
url: "https://your-internal-mcp.corp.example.com/mcp",
headers: { Authorization: `Bearer ${process.env.YOUR_API_KEY}` },
},
},
});

This gives you sandboxing (each worker is isolated), your compliance requirements are met (code and execution stay on your infra), and your on-prem MCPs are reachable since the worker is on the same network.

Setup requires enabling self-hosted agents in the Cloud Agents dashboard and running agent worker start --pool on your machines.

One thing to be aware of: stdio MCPs (local process-based servers) work directly on self-hosted workers with no issues. For HTTP MCPs, routing can behave differently depending on configuration - in some setups, HTTP MCP calls are proxied through Cursor’s backend rather than executed directly on the worker, which would mean your on-prem HTTP endpoints still aren’t reachable. I’d recommend starting with a test pool worker and verifying your HTTP MCP connects before rolling this out. If it doesn’t, converting to stdio transport (running the MCP server as a local process on the worker) is a reliable fallback. Your account team can help troubleshoot if you hit issues with HTTP MCP routing on self-hosted workers.

10

Thanks Mohit, Will give a try..

One small request will you be able to edit your most recent response and remove company name please.