Cursor Cloud Agents bug in OAuth scope handling

[Thomas_Honey]

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Cursor Cloud Agents sends scope: null during OAuth 2.1 authorization requests, resulting in access tokens without API scopes. This prevents Cloud Agents from accessing team-configured MCP servers that use OAuth with scope-based authorization, despite the MCP server correctly advertising available scopes via OAuth metadata.

Impact

• Severity: High - Blocks all team-configured MCP servers using OAuth with scope-based auth
• Affected: Cursor Cloud Agents only (Desktop IDE works correctly)
• Workaround: Server-side scope auto-injection for trusted clients (requires code changes to each MCP server)

Steps to Reproduce

Reproduction Steps

1. Create an OAuth-protected MCP server that advertises scopes via /.well-known/oauth-authorization-server
2. Configure in Cursor Team Dashboard at cursor.com/dashboard → Integrations & MCP
3. Launch a Cursor Cloud Agent that uses the MCP server
4. Observe: OAuth succeeds but access token has no scopes
5. Result: All MCP tool calls fail with “insufficient permissions”

• Cursor Version: Latest as of May 2026

Expected Behavior

The Problem

When a Cursor Cloud Agent authenticates with an OAuth-protected MCP server:

1. MCP server advertises available scopes via /.well-known/oauth-authorization-server
2. Cursor initiates OAuth flow with correct audience
3. Cursor sends scope: null in the authorization request
4. Auth provider (Auth0) issues token with no API scopes
5. MCP tool calls fail with “insufficient permissions”

Evidence from Auth0 Logs

Cursor Cloud Agents (broken):

{
  "client_id": "3yuw7FezTnY2s4uwHTpuVheN0MsTd2yP",
  "audience": "https://api.df.overmind-demo.com",  // ✅ Correct
  "scope": null  // ❌ MISSING - should request advertised scopes
}

Cursor Desktop IDE (working):

{
  "client_id": "3yuw7FezTnY2s4uwHTpuVheN0MsTd2yP",
  "audience": "https://api.df.overmind-demo.com",  // ✅ Correct
  "scope": "openid profile email brent:read brent:write account:read"  // ✅ Correct
}

Expected Behavior Per MCP Specification

According to the MCP OAuth specification:

1. MCP client discovers OAuth metadata at /.well-known/oauth-authorization-server/{server_name}/oauth
2. Server advertises scopes_supported in metadata response
3. Client MUST request those scopes in the authorization request
4. Auth provider issues token with the requested scopes

Our MCP server correctly advertises scopes:

{
  "authorization_servers": ["https://overmind-demo.us.auth0.com"],
  "scopes_supported": ["openid", "profile", "email", "account:read", "brent:read", "brent:write"]
}

What Makes This Worse Than the Related Forum Issue

The existing forum thread “MCP step-up consent not exposed for insufficient scope” describes problems with step-up consent for insufficient scopes.

Our case is more fundamental: Cursor Cloud Agents doesn’t request ANY scopes even on the initial authorization, despite them being advertised in the OAuth metadata. This violates the MCP specification’s OAuth flow requirements.

Operating System

Windows 10/11
MacOS
Linux

Version Information

this happens in cloud agents only Latest as of May 2026
cursor ide works as expected.

Additional Information

Someone even wrote a blog post about it https://medium.com/@george.vetticaden/the-missing-mcp-playbook-deploying-custom-agents-on-claude-ai-and-claude-mobile-05274f60a970

Related Resources

• Related Forum Thread: MCP step‑up consent not exposed for insufficient scope
• MCP OAuth Specification: https://spec.modelcontextprotocol.io/specification/architecture/authentication/

Does this stop you from using Cursor

No - Cursor works, but with this issue

[mohitjain (Mohit)]

This is a known bug. Thanks for the thorough writeup and the Auth0 log evidence.

Cloud Agents don’t discover scopes from the MCP server’s OAuth metadata during authorization. The Desktop IDE handles this correctly, but that fix hasn’t been applied to Cloud Agents yet.

No workaround for Cloud Agents exists right now. If your workflow allows it, the Desktop IDE correctly negotiates scopes for OAuth-protected MCP servers.

Our team is aware of this and I will update this thread when the fix rolls out.

[Thomas_Honey]

Any news on this?

[mohitjain (Mohit)]

No fix has shipped for this yet. The issue is still being tracked internally and our team is aware of the Auth0 evidence you provided.

For now, the Desktop IDE remains the only path for OAuth-protected MCP servers that rely on scope discovery. I’ll update this thread when the fix ships.

[Thomas_Honey]

Just checking in again, we would be happy to beta test this.

[mgyarmathy-pgahq (Michael Gyarmathy)]

Also currently blocked by this. Happy to send agent UUIDs privately where we’re encountering it.

[Thomas_Honey]

I am a bad man, this is working now. Your issue may be different.

[David_at_RentRedi (David Rogers)]

This might be a different class of issue, but we are still experiencing this issue trying to use the BigQuery MCP with Cursor Desktop and Cloud Agents. Because the Google Cloud MCP service only advertizes basic identity scopes, the initial ping appears to work, and the plugin appears “green”. When actually attempting to use the BigQuery tools, however, the OAuth token must be requested with specific scopes for each tool – e.g. https://www.googleapis.com/auth/bigquery for BigQuery – and Cursor doesn’t seem to recognize or use the auth.scopes property correctly.

I’ve even attempted to add a static auth.CLIENT_ID and auth.CLIENT_SECRET with auth.scopes to a local mcp.json file, and the client gets stuck after clicking “Authenticate”. It never opens a window to handle the OAuth dance, and it never passes the defined scopes to the OAuth server, so the tool requests always return 401 Unauthorized.

Please advise if you’d prefer this reported as a separate issue, but it seems related to how Cursor’s OAuth client is mishandling the auth.scopes key.

[mohitjain (Mohit)]

Thanks all, a quick round-up, since this thread now has a couple of different issues in it:

@Thomas_Honey - glad it’s sorted on your end!

@mgyarmathy-pgahq - yours looks like that same Cloud-Agent scope issue, which we’re already tracking on our side - so no need to send UUIDs. I’ll update here when the fix ships.

@David_at_RentRedi - yours is actually a different root cause: Google’s hosted MCP servers don’t support dynamic client registration, advertise a very broad scope set, and only require auth at the moment a tool runs - so the server connects “green” but the BigQuery calls come back 401. Could you open a new bug report so we can track it on its own?
Quick unblock in the meantime: run the BigQuery MCP as a stdio server authed with a GCP service account (e.g. Google’s genai-toolbox) instead of the hosted OAuth endpoint - that sidesteps the OAuth/DCR path and works in both the Desktop IDE and Cloud Agents.

[David_at_RentRedi (David Rogers)]

@mohitjain

Quick unblock in the meantime: run the BigQuery MCP as a stdio server authed with a GCP service account (e.g. Google’s genai-toolbox) instead of the hosted OAuth endpoint - that sidesteps the OAuth/DCR path and works in both the Desktop IDE and Cloud Agents.

Thanks, @mohitjain , and that’s the approach that we’ve been taking. It didn’t work in the Cloud Agent environment, but I think that’s because we didn’t give it a Service Account, preferring individual credentials. I’ll bring this up in my separate bug post.