I thought adding another account type to my local AI gateway would be a small job.

Open the browser. Get the OAuth code. Exchange it for tokens. Save the account. Done.

That was the theory.

In practice, wiring Antigravity into CliGate turned into a chain of problems that all looked solved until the next request failed.

This is the kind of integration bug that feels trivial from a distance:

• the login window opens
• Google sign-in succeeds
• the success page closes
• and then your app still doesn't actually have a usable account

If you've ever built a local developer tool around browser OAuth, this pattern will probably feel familiar.

The Setup

CliGate is a local gateway for AI coding tools.

It lets tools like Claude Code, Codex CLI, Gemini CLI, and OpenClaw talk to one local control plane on localhost, while CliGate handles account pools, API key routing, protocol translation, dashboard chat, and tool-specific config.

The goal for Antigravity support sounded simple:

• add Antigravity accounts to the dashboard
• let users sign in with Google
• persist the account locally
• expose that account as a selectable chat source
• route chat requests through the Antigravity upstream

That is not one problem.

It's at least four.

Problem 1: "Login" Worked, Token Exchange Didn't

The first bug looked like this:

Google token exchange failed: 400
error_description: "client_secret is missing."

The browser login itself was fine. The failure happened after the redirect, when CliGate tried to exchange the authorization code for tokens.

That distinction matters.

Opening the Google consent screen does not prove your OAuth flow is valid. It only proves your authorization URL is valid enough to get a user to log in.

The actual gate is the token exchange.

I tried the clean version first:

• remove the local pre-check for missing secret
• add PKCE
• send code_verifier during token exchange

That got rid of the obvious local error handling problem, but Google still responded with:

client_secret is missing

That told me the current OAuth client was still being treated as a confidential client.

PKCE is great, but it doesn't magically convert a client that Google expects to use a client_secret.

So the local integration had to stop pretending the browser redirect was the hard part. The real constraint was the OAuth client registration.

Problem 2: A Saved Account Still Could Not Refresh

After getting the token exchange path working, the next issue was more subtle.

An account added through the browser could work once, then fail later during refresh because the original OAuth client context had effectively been forgotten.

That was a persistence bug, not an auth bug.

The fix was to save the OAuth client information with the account itself, instead of assuming one global runtime default would always be enough later.

So each Antigravity account now keeps its own OAuth client context for refresh:

{
  "email": "user@example.com",
  "oauthClientKey": "antigravity-enterprise",
  "oauthClientConfig": {
    "key": "antigravity-enterprise",
    "clientId": "...",
    "clientSecret": "..."
  }
}

That way, a browser-added account can still refresh after restart instead of silently depending on whatever happens to be in the environment at that moment.

Problem 3: OAuth Success Still Didn't Mean the Account Was Usable

Then came the bug that surprised me most.

The account could be added successfully, but the next failure was:

ANTIGRAVITY_PROJECT_ERROR: cloudaicompanionProject missing

This one wasn't about OAuth anymore.

It was about the post-login platform metadata the upstream wanted before serving actual requests.

I compared CliGate with another Antigravity-focused open-source project and found a useful design difference:

• my first implementation treated a missing cloudaicompanionProject as a fatal login failure
• their implementation treated it as a recoverable state

That turned out to be the right approach.

So the flow changed from:

1. login succeeds
2. project ID missing
3. fail hard

to:

1. login succeeds
2. save the account anyway
3. try loadCodeAssist
4. if project ID is missing, keep going with a fallback path
5. resolve or persist a usable project ID later

This matters because "cannot resolve everything immediately" is normal in real integrations. Product code needs a degradation path.

Problem 4: The Account Existed, But Users Still Couldn't Select It

This one was completely different again.

The account showed up in the Accounts tab.

But it did not show up in the dashboard chat source selector.

That meant the bug wasn't OAuth, token storage, or upstream auth at all. It was just UI source wiring.

CliGate's chat source selector was still only returning:

• ChatGPT accounts
• Claude accounts
• API keys

Antigravity accounts had been integrated into account management, but not into the chat source catalog.

So the user experience was:

• account added successfully
• visible in Accounts
• invisible in Chat

The fix was straightforward once the real cause was clear:

• include Antigravity accounts in /api/chat/sources
• surface their available model list
• add chat send branches for Antigravity in both regular and streaming chat paths

This is the kind of bug that wastes a lot of time because the user-facing symptom sounds like "login is broken", even though login already succeeded.

The Real Lesson

I keep running into the same pattern when building local developer tools:

People talk about "adding OAuth" like it's one checkbox.

It isn't.

In this case, the real work was:

1. getting the browser flow to start
2. getting token exchange to match the actual OAuth client constraints
3. persisting enough client context for refresh to keep working later
4. tolerating missing upstream metadata like project IDs
5. wiring the new account type into the actual product surfaces people use

Only after all of that does the user experience become:

"I clicked sign in, picked the account in chat, and sent a message."

That's the part users should see.

The rest is the invisible engineering work that makes "simple" integrations stop failing one step later.

A Small Before/After

Before:

• browser login opened
• token exchange failed
• or account saved but couldn't refresh
• or account saved but had no project ID
• or account existed but wasn't selectable in chat

After:

• account login completes
• client context persists with the account
• project ID resolution degrades gracefully
• Antigravity appears as a first-class chat source
• chat requests can actually be routed through it

That is a much better definition of "support added" than a green success popup after OAuth.

If You're Building Something Similar

The biggest mistake is treating authentication as the whole integration.

It usually isn't.

If your app adds a new account type, ask these questions before you call it done:

• Can the token refresh after restart?
• Does the upstream require extra metadata after login?
• Does the account appear in every relevant selector and route?
• Can a successful sign-in still lead to a failed first real request?

If the answer to any of those is "yes", you're not done when OAuth works.

You're done when the user can actually use the account where they expected to use it.

Link

CliGate is here if you want to look at the project:

github.com/codeking-ai/cligate

If you've had to debug a "successful" OAuth integration that still wasn't actually usable, I'm curious what the second failure was in your case.