Google Cloud BigQuery connector: redirect_uri_mismatch, and the pasted OAuth Client ID appears unused (reopening #43959 / #48957 / #62271 with a full repro)

Summary

The Google Cloud BigQuery directory connector fails OAuth with Error 400: redirect_uri_mismatch, and the Client ID / Client Secret the install dialog asks for do not appear to change the outcome. Other Google connectors (Gmail, Google Calendar, Google Drive) connect normally on the same account and machine.

This has been reported at least three times — #43959, #48957, #62271 — all closed as not planned. I am reopening it with a full reproduction because those reports were closed without one, and the failure is total: there is no way to use this connector.

Environment

• Claude Desktop (Windows 11 x64), installed fresh from the official download during this test
• Plan: Max
• Google Cloud project with BigQuery enabled; user has roles/bigquery.jobUser and dataset-level dataViewer
• Same account and machine: Gmail / Calendar / Drive connectors all connect successfully

Steps to reproduce

1. Settings → Connectors → Add → Browse connectors → search bigquery → Google Cloud BigQuery
2. The install dialog asks for four things: get an OAuth Client ID from Google, paste it, get a Client Secret, paste it
3. Paste a Client ID and Secret from an OAuth client in your own Google Cloud project
4. Continue → sign in with Google

Expected: the Google consent screen for the pasted OAuth client.

Actual: Access blocked: This app's request is invalid — Error 400: redirect_uri_mismatch. Error details give only flowName=GeneralOAuthFlow.

What I tried, and what it ruled out

I assumed this was my misconfiguration and worked through it systematically:

| Attempt | Result |
|---|---|
| OAuth client of type Desktop app | redirect_uri_mismatch |
| OAuth client of type Web application, with https://claude.ai/api/mcp/auth_callback in Authorized redirect URIs (the URI Anthropic's own docs specify) | redirect_uri_mismatch, identical |
| Re-run via the connector's retry / Connect button after registering the new client | identical error — the flow appears to reuse credentials cached from the first attempt rather than re-reading the dialog values |

The second row is the important one: a Web-application client with the documented redirect URI registered is exactly the configuration the docs describe, and it fails the same way.

I could not find any UI to clear or re-enter the stored credentials for an already-installed connector, so I could not force a clean retry with the new client. If that path exists, pointing me at it would let me narrow this further.

The likely cause, from the earlier reports

I did not capture the client id from the failing request myself, so I am citing rather than asserting: reporters on #43959 and #62271 state the failing request carries Anthropic's own OAuth client id (699272716442-c8vv4tojssh38erhltaj70k0lmi7p449.apps.googleusercontent.com) rather than the pasted one. That would explain why the pasted credentials make no difference, and why the redirect URI on our client is irrelevant.

If that is right, the dialog is asking users for credentials it does not use, and the fix is on the server side.

Impact

• The connector is unusable — not degraded, unusable.
• The dialog actively misleads: it asks for a Client ID and Secret, so every user reasonably concludes the failure is their Google Cloud configuration and goes looking there. I spent about an hour creating and re-creating OAuth clients before checking the issue tracker.
• Three separate people filed this and were closed as not planned, so the next person will also start by assuming it is their own setup.

Suggestions, in order of cost

1. If the pasted credentials genuinely are not used, remove or disable those fields for this connector, or label them clearly. That alone would save every future user the hour.
2. Surface the actual client_id and redirect_uri in the error surface so a user can tell in one glance whose client failed.
3. Register the correct redirect URI on the connector's OAuth client, if that is all this is.
4. If the connector is not currently supported, marking it as such in the directory would be kinder than an install flow that cannot complete.

Workaround for anyone who lands here

Skip the directory connector. A ~250-line stdio MCP server calling bq with your own gcloud credentials works today, on any plan, with no OAuth involved:

claude mcp add bigquery \
  -e BQ_PROJECT=your-project \
  -e BQ_DATA_PROJECT=project-that-owns-the-data \
  -e BQ_LOCATION=your-location \
  -- /path/to/bigquery_mcp.py

Points worth building in if you write your own: enforce read-only in code rather than in the prompt (asked to delete rows, a model will write DELETE FROM), --dry_run every query first and refuse above a byte cap, and grant the identity bigquery.jobUser + dataViewer and not dataEditor so the warehouse refuses writes even if the code is wrong.