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?
