MCP Store: Supabase template OAuth fails with "Unrecognized client_id"

[KarloAldrete]

Bug Description

Installing the Supabase MCP server template from the MCP Store fails during OAuth authorization. The browser redirects to Supabase with a client_id that Supabase rejects as unrecognized.

How to reproduce

1. Open PostHog Code
2. Go to MCP Servers / MCP Store
3. Click install on the Supabase template
4. Browser opens:

   https://api.supabase.com/v1/oauth/authorize?client_id=18038368-50b4-4095-a1b6-b67b73417452&redirect_uri=https%3A%2F%2Fus.posthog.com%2Fapi%2Fmcp_store%2Foauth_redirect%2F&response_type=code&...
   

5. Supabase returns: {"message": "Unrecognized client_id"}

Expected behavior

OAuth flow should complete successfully and the Supabase MCP server should be installed and connected.

Actual behavior

The client_id embedded in the authorization URL is rejected by Supabase. This means the OAuth app credentials stored in the Supabase template (MCPServerTemplate.oauth_credentials on the PostHog backend) are either stale, incorrect, or the app was never properly registered on Supabase's side.

Environment

• PostHog Code: v0.52.9 (commit 890696c)
• Platform: Linux x86_64
• PostHog region: US (us.posthog.com)

Pointers

The OAuth flow for template-based installs is handled in:

• apps/code/src/renderer/features/mcp-servers/hooks/useMcpServers.ts — installTemplateWithOAuth()
• apps/code/src/renderer/api/posthogClient.ts — installTemplateWithOAuth() API call
• Backend template model: products/mcp_store/backend/models.py in PostHog/posthog — MCPServerTemplate.oauth_credentials

The fix likely requires updating the client_id/client_secret in the Supabase template record via Django admin on the PostHog backend, or re-registering the OAuth app on Supabase.

[lost-particles]

I took a look at this and want to confirm your analysis before any code changes are made: this bug cannot be fixed from PostHog/code. The client_id in the failing URL is supplied entirely by the PostHog backend.

Evidence from the desktop side:

• apps/code/src/renderer/features/mcp-servers/hooks/useMcpServers.ts:38-52 (installTemplateWithOAuth) only sends template_id plus the local callback URL to the backend, then opens whatever redirect_url comes back in the response. It does not construct the OAuth URL.
• apps/code/src/main/services/mcp-callback/service.ts:65 (openAndWaitForCallback) opens that redirect_url in the browser and waits for the callback — again, no construction of OAuth params.

So the client_id=18038368-50b4-4095-a1b6-b67b73417452 is coming from the MCPServerTemplate row for Supabase on the backend (products/mcp_store/backend/models.py in PostHog/posthog, oauth_credentials field) exactly as you described. The fix needs to land there:

1. Re-register (or rotate) the OAuth app on Supabase to get a current client_id / client_secret, and
2. Update the MCPServerTemplate record via Django admin to point at the new credentials.

Could a PostHog/posthog maintainer pick this up? I am happy to mirror this comment over there or open an issue on that repo if that would help triage.

Separately, one thing this exposed on the desktop side: when the provider rejects the OAuth request, the desktop has no signal and just sits for the full 3 minute timeout (OAUTH_TIMEOUT_MS in apps/code/src/main/services/mcp-callback/service.ts) before showing a generic "OAuth authorization timed out". I am happy to open a separate, small PR to shorten that path and surface the redirect host in the error so future provider-side rejections are easier to spot, if that is wanted.

[m13v]

the seam here isn't the stale client_id, it's that the MCP store treats vendor OAuth apps as a static template field but Supabase OAuth apps are tied to one team's account and rotate on that team's lifecycle, not PostHog's. so MCPServerTemplate.oauth_credentials is a shared registration that revocation, team transfer, or a Supabase api migration can kill silently with no signal on the PostHog side. that lifecycle belongs in a per-install OAuth flow where each user registers their own app against their own Supabase org, not a backend column an admin has to refresh whenever a vendor rotates.