gemini-cli - 💡(How to fix) Fix Google OAuth login for personal accounts may not be reliably mapped to the correct entitlement path in Gemini CLI

What happened?

✕ [API Error: {"error":{"message":"{\n "error": {\n "code": 403,\n "message": "Requests to this API generativelanguage.googleapis.com method google.ai.generativelanguage.v1beta.GenerativeService.StreamGenerateContent are blocked.

Thanks a lot for blocking my account for trying to help out! I will for sure recommend your services to everyone! 😂

"This is incredible. You didn't just get an account ban—you managed to run face-first into a hyper-specific, automated service-level policy enforcement block."

Look at the exact payload signature returned by the edge gateway:

"reason": "API_KEY_SERVICE_BLOCKED", "domain": "googleapis.com", "metadata": { "service": "generativelanguage.googleapis.com", "consumer": "projects/693952434269"

"This error code (API_KEY_SERVICE_BLOCKED) is the absolute smoking gun. It means your API key itself is perfectly valid and authenticated, but Google’s API Gateway (googleapis.com) has put a hard, systemic block on letting any API keys route to the generativelanguage.googleapis.com service endpoint for your consumer profile."

"They didn't just disable the API in your project; they blacklisted the structural pairing of API Keys + Generative Language API for your user identity."

But since I can rinse and repeat this forever, because I'm 100x smarter than you're entire team together I'm already up and running, just new IP, new account. Ever heard of a VM? Spoofing? VPN?

I may be misunderstanding the intended architecture, but after reading the public docs and relevant source files, it looks like Gemini CLI’s Google OAuth login path may not have a clear client-visible mechanism for distinguishing between different kinds of personal Google accounts after login.

Why I’m raising this

The docs indicate that Gemini CLI is intended to support personal Google accounts, including paid personal subscriptions, via Sign in with Google.

However, when looking at the code path around:

• packages/core/src/code_assist/codeAssist.ts
• packages/core/src/code_assist/setup.ts
• packages/cli/src/ui/auth/useAuth.ts

I could not find an obvious client-side branch or function that explicitly identifies:

• free personal account
• personal paid subscription
• enterprise / project-backed account
• unsupported combinations

before deciding how the runtime session should proceed.

Relevant call path

Google OAuth appears to go through this path:

if (
  authType === AuthType.LOGIN_WITH_GOOGLE ||
  authType === AuthType.COMPUTE_ADC
) {
  const authClient = await getOauthClient(authType, config);
  const userData = await setupUser(authClient, config, httpOptions);
  return new CodeAssistServer(
    authClient,
    userData.projectId,
    httpOptions,
    sessionId,
    userData.userTier,
    userData.userTierName,
    userData.paidTier,
    config,
  );
}

This suggests that after OAuth succeeds, the CLI depends on setupUser(...) to resolve the usable runtime state.

What seems unclear in setup.ts

In packages/core/src/code_assist/setup.ts, I can see logic around:

• loadCodeAssist(...)
• currentTier
• paidTier
• allowedTiers
• onboarding
• cloudaicompanionProject

and the fallback:

function throwIneligibleOrProjectIdError(res: LoadCodeAssistResponse): never {
  if (res.ineligibleTiers && res.ineligibleTiers.length > 0) {
    throw new IneligibleTierError(res.ineligibleTiers);
  }
  throw new ProjectIdRequiredError();
}
``
What I **could not find** is an obvious client-side function or branch that says, in effect:

- this is a free personal account
- this is a personal paid subscription
- route these to different post-auth runtime paths accordingly

Instead, it looks like the client may be relying entirely on backend-returned tier/project state.

### Why this may matter
If that reading is correct, then a successfully authenticated personal account could still be routed incorrectly after login if the backend provisioning/tier response is incomplete, ambiguous, or mismatched.

That could explain why some users report cases where:

- OAuth login succeeds
- but the runtime session still behaves as unsupported, under-entitled, quota-limited, or project-misconfigured

### Additional supporting code path
The UI also appears to treat `ProjectIdRequiredError` as a post-auth setup failure rather than a login failure:

```typescript name=packages/cli/src/ui/auth/useAuth.ts url=https://github.com/google-gemini/gemini-cli/blob/main/packages/cli/src/ui/auth/useAuth.ts#L130-L139
} else if (e instanceof ProjectIdRequiredError) {
  onAuthError(getErrorMessage(e));
} else {
  onAuthError(`Failed to sign in. Message: ${getErrorMessage(e)}`);
}

Request

Could you clarify whether the current Google OAuth path is expected to make a reliable distinction between:

• free personal accounts
• personal paid subscriptions
• project-backed / enterprise-style accounts

If that distinction already exists, could you point to where it is implemented?

If it does not exist client-side by design, then it may be helpful to document more clearly that the runtime path depends entirely on backend tier/project provisioning after OAuth succeeds.

Reason for filing

This may just be a documentation gap, but from reading the code, I could not find a clear function or branch that makes the CLI itself able to identify different personal subscription states before choosing the post-auth runtime path.

I've asked both Gemini 3.1 Pro and GPT/CoPilot for confirmation and both replied that this seems to be the case. They couldn't find any function that identified personal accounts to any sub

What did you expect to happen?

Probably any normal person would expect it would make a difference if you're signed in /auth with a free tier or Ultra sub.

I don't auth with personal account atm since then the cli is unusable, it's just an endless spam loop of "Keep crying" before you have even wrote a single character in the prompt.

Client information

│ About Gemini CLI │ │ │ │ CLI Version 0.42.0 │ │ Git Commit 68e2196d5 │ │ Model Auto (Gemini 3) │ │ Sandbox no sandbox │ │ OS win32 │ │ Auth Method gemini-api-key

Login information

No response

Anything else we need to know?

Should probably test your own software with accounts that are like a normal user from outside of your office xD