Fix Cloud MCP OAuth when ${env:CLIENT_ID} stays unsubstituted

Local MCP Authenticate can succeed while Cloud Authenticate or the Grok Bot connect card opens OAuth with client_id=${env:ASANA_CLIENT_ID} (or another ${env:…} name) literally in the URL. The provider then returns invalid_request because the client id is missing. Cursor staff (deanrie, Aug 21, 2026) call the behavior expected on the cloud path: the handshake runs on Cursor’s backend, which cannot read env vars from your Mac. Restarting Grok Bot does not expand those placeholders. Custom remote redirect_uri loopback failures are a different bug: Fix custom MCP OAuth redirect_uri failures in Grok Bot.

Confirm the unsubstituted URL

1. Authenticate the connector Locally in Cursor Customize → MCPs (or your local mcp.json). Note Connected.
2. Click Cloud Authenticate, or open the same connector’s connect card inside Grok Bot.
3. Inspect the authorize URL. If you see ${env:YOUR_CLIENT_ID} unexpanded, you are on this path.

Staff workaround for cloud

Staff’s working setup:

1. In the cloud MCP config, set the real CLIENT_ID value directly — not an ${env:…} reference. Staff note cloud configs are encrypted at rest and CLIENT_SECRET cannot be read back after saving.
2. In the OAuth app at the provider (Asana in the report), add Cursor’s cloud callback to allowed redirect URIs. Copy the exact redirect_uri from the cloud authorize request. Staff have seen https://www.cursor.com/agents/mcp/oauth/callback.
3. Retry Cloud Authenticate / the Grok Bot connect card.
4. For a catalog plugin that still will not authenticate after a revoked grant, official troubleshooting still applies: Settings → Plugins → reopen detail → authenticate in the browser → remove and reconnect if needed.

Staff also filed product feedback that the backend should warn on an unresolved ${…} placeholder before it builds a bad authorize URL.

If static CLIENT_ID still fails

Forum bumps (including Sep 2, 2026) report cloud OAuth still failing after an explicit Client ID. Collect Cursor version, Grok Bot version, connector name, whether Local Authenticate works, the exact authorize error, and whether the cloud redirect URI is registered. File or bump the forum thread. Do not paste the CLIENT_SECRET into chat or a ticket body.

Pitfalls

• Local shell env vars never resolve on Cloud / Grok Bot OAuth by design.
• A working Local Authenticate does not prove Cloud Authenticate will succeed with the same ${env:} config.
• Redirect URI mistakes are separate from unsubstituted env vars — register the cloud callback, not only a localhost URI used for local tools.