Hosted Gmail MCP (user-gmail): Tools UI shows connected after logout/toggle, but Agent MCP tool calls return Unauthorized; OAuth reconnect never prompts

Support Bug Reports
,
12

Thanks for looking into mcp-remote, that’s a useful data point.

On the mcp-remote race: yep, that matches what you described. Google MCP returns Unauthorized right away on initialize before mcp-remote has the loopback listener up. Then when the browser redirects to http://localhost:8787/oauth/callback the listener is already gone, so you get connection refused. That’s a bug in geelen/mcp-remote, not something we can patch from the Cursor side. PR #260 looks like it covers a nearby race, but not the redirect-after-auth window you’re hitting. Realistically, the fix needs to land upstream. The port is already pinned positionally in the config I shared, the 8787 after the URL, so there’s nothing to tighten there. If you want more detail on where it tears down, --debug on mcp-remote helps a bit, but I don’t have a workaround that actually closes that race. We’re tracking the broken openExternal path on our side separately, and once that’s fixed you won’t need mcp-remote for this at all.

On Slack, Atlassian, Mixpanel Login working in cloud agents but Google not: that’s the right question, and the difference is architectural, not a bug.

The connectors you see with a Login button in the Tools list are first-party integrations that Cursor manages, the same set you see at cursor.com/dashboard/integrations. Cursor owns the OAuth client for each provider, the consent flow runs once in the IDE or dashboard, and the tokens are stored in Cursor’s backend on your account. When a cloud agent starts, the backend loads those tokens into the run, so there’s no consent UI needed inside the cloud agent.

A hosted Gmail MCP that you set up yourself with your own CLIENT_ID and CLIENT_SECRET env vars doesn’t go through that path. The OAuth tokens only live in your local IDE’s MCP store. The backend doesn’t have a copy, and there’s no interactive consent UI in a cloud agent VM to get them on demand. So even if local IDE OAuth worked perfectly, the cloud agent flow still wouldn’t match Slack or Atlassian. It would need the same managed integration plumbing on our side.

Two paths that work today for cloud agents:

  • Static auth via the SDK. If you’re using Agent.create with mcpServers, you can pass headers: { Authorization: 'Bearer ...' } or an auth block with CLIENT_ID, CLIENT_SECRET, and scopes. Docs: Capabilities | Cursor Docs. This works if you can mint a token outside the interactive consent flow, like a long-lived token your backend issues, or a Google service account if your workflow supports domain-wide delegation.
  • Manage Gmail auth out of band, like service account plus impersonation, or your own token broker, then inject the bearer token via headers.

For interactive per-user Google consent inside a cloud agent run, the answer right now is it’s not supported. It would need Gmail MCP to be added as a managed integration, not a user-configured one. I’ll pass this along as feedback, but I don’t want to set expectations on timing.