fix(Oauth): validate client IDs against resolvePublicCred to correctly togg…

[juandisay]

Propblems

When adding a new Antigravity (or Gemini CLI / AGY) provider connection via the dashboard, the OAuth flow failed with a redirect_uri_mismatch error from Google. This happened because hasCustomGoogleOAuthCredentials() treated the default built-in public client IDs (auto-populated by sync-env) as "custom" credentials, which triggered resolveBrowserOAuthRedirectUri() to rewrite the loopback callback URL to a public NEXT_PUBLIC_BASE_URL — producing a mismatch against what Google's OAuth consent screen expected.

The fix compares the env-supplied client ID against the dynamically resolved default from resolvePublicCred() (instead of treating any non-empty value as custom). When the env value matches the embedded public default, the redirect URI stays on loopback as intended.

Related Issues

• Closes #TBD
• Related to redirect_uri_mismatch errors on fresh installs with default .env configuration

Validation

• npm run lint
• npm run test:unit
• npm run test:coverage
• Coverage is still >= 60% for statements, lines, functions, and branches
• SonarQube PR analysis is green or any remaining issues are explicitly documented below

Tests Added Or Updated

• [NEW] tests/unit/oauth-redirect-uri-mismatch.test.ts — 25 fully offline tests covering:
  • Default public credentials correctly identified → loopback preserved
  • Truly custom credentials → public base URL override works
  • agy provider alias inherits antigravity credential detection
  • Incomplete/missing/blank credentials → no override
  • Non-Google providers unaffected
  • Already-remote redirect URIs not double-overridden
  • IPv6 [::1] and localhost loopback variants
  • Path and query string preservation during override
  • Trailing slash normalization on base URL
  • OMNIROUTE_PUBLIC_BASE_URL fallback

Coverage Notes

• src/lib/oauth/providers.ts is the only production file changed. The new test file exercises every branch of hasCustomGoogleOAuthCredentials() and resolveBrowserOAuthRedirectUri() with both default and custom credential combinations. Coverage should increase for this file.

Reviewer Notes

• The fix uses resolvePublicCred("antigravity_id") and resolvePublicCred("gemini_id") to dynamically resolve the default client IDs from the XOR-masked embedded defaults in open-sse/utils/publicCreds.ts. This avoids hardcoding the raw *.apps.googleusercontent.com strings (which would trip pattern scanners) while keeping the comparison accurate even if the embedded defaults are rotated in the future.
• No migration or feature flag required — this is a pure bugfix for the existing credential detection logic.
• The OAuthModal.tsx frontend already uses 127.0.0.1 on main, so no frontend change was needed on this branch.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[diegosouzapw]

Merged into release/v3.8.11 — thank you @juandisay! 🙏

Solid fix: hasCustomGoogleOAuthCredentials() was treating the built-in public client IDs (auto-populated by sync-env) as "custom", which rewrote the loopback redirect URI and triggered Google's redirect_uri_mismatch. Comparing against resolvePublicCred("antigravity_id" / "gemini_id") correctly distinguishes real custom creds from the defaults — and it's the mandated resolvePublicCred pattern (no hard-coded literals).

Verified before merge: 25/25 tests in oauth-redirect-uri-mismatch green, lint clean, Semgrep passed. Ships in the next release.