## TL;DR
`unrecognized client_id` means the OAuth client id your tool is sending was never registered with Supabase (or was deleted), so Supabase cant match it to any integration. Fix it by re-creating the OAuth app / MCP integration in the Supabase dashboard and copying the fresh client id into your tool config, exactly, with no extra whitespace.

```text
{"message":"unrecognized client_id"}
```

## Use this when
- A Supabase MCP client fails at connect time with this JSON message
- An OAuth login flow against Supabase errors with unrecognized client_id
- The integration worked before and broke after dashboard changes

## Not for this skill when
- The error is about an invalid API key or anon key (thats the project key, not OAuth)
- You get row-level security denials (thats policy, not identity)
- PostgREST or the database itself returns the error

## Steps

1. Confirm where the client id comes from. In your MCP or tool config, find the Supabase entry and read the client id value:

```bash
grep -r "supabase" ~/.config | head -5
```
Expected output: the config file and the client id string your tool sends. You need this to compare against what the dashboard shows.

2. Open the Supabase dashboard, go to your project, and check the registered integrations / OAuth apps. If the integration is missing or shows as revoked, create it again:

```text
Dashboard: Project Settings \u2192 Integrations (or OAuth Apps) \u2192 New integration
```
Expected output: a fresh client id. Deleted or rotated apps invalidate the old id permanently, which is the usual cause.

3. Paste the new client id into the tool config, watching for whitespace and quoting:

```json
{
  "client_id": "PASTE_THE_FRESH_VALUE_HERE"
}
```
Expected output: the value matches the dashboard character for character. A trailing space or a stale copy from an old doc page reproduces the exact error.

4. Re-run the auth flow from scratch rather than refreshing:

```bash
# restart the MCP client / tool so it picks up the new config
```
Expected output: the connection succeeds and the unrecognized client_id message is gone. Cached OAuth state can keep sending the old id, so a full restart beats a retry.

## Variant phrasings

### unrecognized client_id only on one machine
That machine has an old config file with a rotated id. Diff its config against a working machine.

### worked yesterday, fails today with no config change
The OAuth app was likely revoked or the project was transferred, which invalidates ids. Re-create the integration.

## Why it happens
OAuth identifies third-party tools by client id. Supabase keeps a registry of issued ids; when an integration is deleted, the project is moved, or the id is simply mistyped, the incoming id matches nothing in the registry and Supabase answers with this generic message. Agents hit it often because they copy client ids from docs or old configs instead of the live dashboard.

## Edge cases
- Organization-level apps vs project-level apps: an id issued at the org level may not be valid for a specific project's flow.
- Multiple Supabase projects: the id is tied to the project where the integration was created; using it against another project fails.
- If the dashboard shows the integration as healthy, the id in your config is stale; trust the dashboard copy, not the file.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Sk9Gr0ycWg-QmNcucf5-8w