What you’re seeing isn’t caused by anything in your setup. The in-app Authenticate button on the Cloud row sends a cursor:// redirect address, and Google doesn’t accept that style of address for this kind of sign-in, so it stops the flow before you ever get to the consent screen. That’s why the retry lands in the same place every time.
For Cloud, authenticate from https://cursor.com/agents instead of the in-app button. Open MCP Servers from the + menu, find the plugin, then Login. Sign in with the same Cursor account you use in the app. That path uses a different callback address and is the one that can complete Cloud auth. You’ll need to do this once per plugin, so four times for Calendar, Docs, Drive, and Sheets.
If you’d rather use these plugins in the editor rather than in the cloud, the Local option authenticates through a different address that Google does accept, so that route works today as well.
This is an issue we’re tracking and it isn’t something you need to reconfigure on your end. No timeline to share yet, but I’ll post here when there’s an update.
Adding a data point that may help narrow this down: I’m seeing the same Error 400: invalid_request / “Access blocked” page when authenticating Gmail, Google Calendar, and Google Drive plugins, on the latest desktop build (3.15.6, macOS).
Notably, this isn’t limited to the manual “Authenticate” button — it also breaks Remote Control / Cursor Cloud sessions, since Remote Control authenticates through the same Cloud OAuth path. Clicking “Login” from the agents page produces the identical Google “Access blocked” error (so the cursor.com/agents workaround mentioned above doesn’t unblock Cloud auth on my end).
Workaround confirmed on my end: switching the plugin’s environment from Cloud to Local in the “Configure [plugin]” dialog restores functionality — Local shows “Connected” and tool calls (e.g., reading Gmail) work fine. But this only helps for local/in-app usage; anything routed through Remote Control or Cloud remains broken since it can’t use Local auth.
For context, unrelated integrations (e.g., Notion) re-authenticate normally, so this does appear isolated to the Google Workspace plugins’ Cloud redirect handling specifically.
Would appreciate an update if there’s a Cloud-specific workaround, since Local mode isn’t viable for Remote Control workflows.
The cursor.com/agents workaround does not work for me. Using MCP Servers → Google Drive → Login produces the same Google 400: invalid_request authorization error.
Local authentication does not help with Cloud Agents. Is there a working Cloud-specific workaround or an update on the OAuth callback fix?
Confirming this on Windows 11, Cursor desktop, current version, individual paid plan.
Same failure for Gmail and Google Calendar. Both authenticate fine in Local and both fail in Cloud with Access blocked, Error 400 invalid_request, “doesn’t comply with Google’s OAuth 2.0 policy for keeping apps secure”.
Two extra data points that may help narrow it.
It is not specific to the marketplace plugins. I configured Gmail manually in ~/.cursor/mcp.json pointing straight at Google’s own remote MCP server at https://gmailmcp.googleapis.com/mcp/v1 with type http. Local authenticated and gave me 29 tools. Cloud fails with the identical error. So the problem sits in the Cloud OAuth flow rather than in the plugin definitions.
A manually configured server initially shows no Cloud environment at all until git is installed and the plugin system initialises, which made this hard to diagnose. Before that, the Gmail entry only offered Local, with no indication a Cloud path existed.
Worth flagging the impact: Grok Bot runs on the cloud VM, so the Cloud environment is the only one its agents can use. With this broken, every Google connector is unusable for Bot work and the fallback is browser sign-in, which is much slower. This affects paid tiers.
