Google Cloud BigQuery MCP connector: OAuth redirect_uri_mismatch (Error 400)

[JoyArchivist]

Environment

• Claude Code (CLI), macOS (Darwin 25.5.0)
• Model: Opus 4.7 (1M context)
• Connector: claude.ai Google Cloud BigQuery (claudeai-proxy → https://bigquery.googleapis.com/mcp)

Steps to reproduce

1. From an active Claude Code session, run /mcp
2. Select claude.ai Google Cloud BigQuery
3. Choose authenticate / connect
4. Browser opens to Google OAuth consent
5. Sign in with a Google Workspace account

Expected

OAuth flow completes and the connector's data tools (queries, dataset listing) become available in the session.

Actual

Google returns:

Error 400: redirect_uri_mismatch
Request details: flowName=GeneralOAuthFlow

The redirect URI the connector sends is not registered on the OAuth client Google is matching against.

Notes

• The two visible tools on the connector are authenticate and complete_authentication. The authenticate tool, when called from inside a session, returns "Ask the user to run /mcp and select '…' to authenticate" — so the flow is intended to be driven entirely by the /mcp UI.
• Calling authenticate is not the failure point; the failure is on Google's side after the consent screen attempt, suggesting the connector's registered redirect URI is wrong (or scoped to a different OAuth client than the one being invoked).
• The Google_Compute_Engine connector exposes the same authenticate/complete_authentication pair — untested but likely affected if it shares the same OAuth client config.
• Gmail / Calendar / Drive connectors on the same account work fine, so it's not an account-level issue.

Workaround

None inside Claude Code. Falling back to bq CLI with gcloud ADC.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] BigQuery MCP connector on claude.ai/code fails with redirect_uri_mismatch for Google Workspace accounts #48957
2. [BUG] BigQuery MCP connector OAuth fails with redirect_uri_mismatch (Error 400) #43959
3. [BUG] Error 400: redirect_uri_mismatch when authenticating Google MCP servers #58700

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[mertcanvural]

I ran into a similar connector bug where Google was checking a different callback on the code exchange than on the consent redirect. For this one I'd capture the exact redirect_uri in both steps, then compare it three ways: manual diff of the emitted callback vs the OAuth client allow-list, authproxy.dev if you need to watch the handoff live, or OAuth Redirect Doctor if you want the start-flow and callback-flow URIs laid out side by side. If /mcp is the only entrypoint, the broken value is probably inside the connector registration rather than your local Claude Code config, kinda sounds like the wrong client is wired up.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[maxwang77123]

Same connector, different failure mode — and I have Google-side
audit logs that show the request never reaches Google at all.

Environment

• Surface: claude.ai web (not CLI)
• Plan: Max | Region: Taiwan
• Account: Google Workspace
• Connector: Google Cloud BigQuery → https://bigquery.googleapis.com/mcp
• Error refs: ofid_f65242c3f1fd5d26, ofid_b84d62d5b8ac6d14,
  ofid_58507921973d7d48

What's different from the OP

This connector worked normally for weeks, then died mid-flight on
2026-08-20 ~11:00 UTC+8 with no action on my side. Re-connecting
then fails — but not with redirect_uri_mismatch. I get:

"Your account was authorized, but Google Cloud BigQuery
returned an error when connecting."

and sometimes:

"This connector's server hostname doesn't resolve or isn't
reachable from this network."

The second message is false — see #3 below.

Google Workspace OAuth audit log (2026-08-14 → 08-21, 179 events)

The only Claude entry in the entire week:

[maxwang77123]

Follow-up hypothesis

My grant predates the log window and never traversed the broken
setup flow — existing grants refresh silently and never re-hit
the authorization endpoint. That would explain the asymmetry:
reporters here have been blocked at setup since April, while my
pre-existing grant kept working until its refresh token was
invalidated on 08-20.

If that's right, this isn't a static bug affecting only new
connections. Every user who set up before the regression is one
token rotation away from the same dead end, with no recovery
path. That would also explain the low report volume — users drop
out one at a time and quietly fall back to the bq CLI, so it
never surfaces as a visible cluster.

Worth checking whether the count of working BigQuery connector
sessions has been declining since April.