" Error 403 " on cloudcode-pa still happening — checked main branch, two proposed fixes (#25450, #26420) were never merged, users still blocked!!

[AdityaPagare619]

The Problem

Google One AI Pro subscriber here. Sign in with Google OAuth, CLI detects the tier correctly ("Gemini Code Assist in Google One AI Pro"), but every prompt fails:
403 PERMISSION_DENIED
The caller does not have permission
Endpoint: cloudcode-pa.googleapis.com/v1internal:streamGenerateContent
There are 35+ issues reporting this same pattern (#25189, #25226, #25431, #25797, #25954, #26036, #26039, #26080, #26190, #26564 — long list). Most were closed as "not_planned" by automation with boilerplate. But the code hasn't changed.

What I Found In main Branch

Two community PRs were submitted to fix the root causes. Both have the code ready. Neither was merged.
PR #25450 — Ghost project hijacking fix. Submitted Apr 15. loadCodeAssist sometimes returns a phantom cloudaicompanionProject for personal accounts. The CodeAssistServer uses it blindly → 403 because the account has no IAM access on that phantom project. The fix strips the phantom project ID when the user didn't explicitly set one. Never merged.
PR #26420 — GOOGLE_CLOUD_PROJECT override fix. Submitted May 4. If you have GOOGLE_CLOUD_PROJECT set (common for anyone doing GCP dev work), the CLI force-uses it for ALL auth types including OAuth. For personal accounts, this routes through the enterprise Code Assist path → 403. The fix skips the env var for LOGIN_WITH_GOOGLE and falls back to the server-managed project. Never merged.
What did land: PR #20507 (retry logic for OAuth on 429/499) — merged Feb 27. Good fix, but doesn't address the 403.

Code That Still Breaks

packages/core/src/code_assist/setup.ts line 98:

const projectId = process.env['GOOGLE_CLOUD_PROJECT'] || ...

Unconditional read. No auth-type check.
packages/core/src/code_assist/server.ts — loadCodeAssist:
Accepts whatever cloudaicompanionProject the backend returns. No stripping for personal accounts without an explicit project.
The fix code already exists in #25450 and #26420. Small changes — 89 lines and 103 lines.
## What I'm Asking
Can someone review and merge #25450 and #26420? They've been sitting for weeks. Users are still hitting 403 every day because of these two bugs. The fixes are written, tested, and waiting.

[gemini-cli]

Found possible duplicate issues:

• 403 PERMISSION_DENIED with oauth-personal on Google One AI Pro — server-side cloudaicompanionProject ghost binding (additional affected account, related to #25189 / #25425 / #24747) #25431
• 403 PERMISSION_DENIED: cloudcode-pa.googleapis.com SERVICE_DISABLED on user project, account bound to inaccessible phantom project #25226
• escalation packet solution #25449
• • Account: Personal Google account with Google One AI Pro subscription #25379
• Version: 0.40.0-nightly.20260415 #25445
• 403 PERMISSION_DENIED for Google One AI Premium subscriber - VS Code extension auto-injects inaccessible Ghost Project ID after OAuth login #24747
• ✕ [API Error: [{ "error": { "code": 403, "message": "The caller does not have permission", "errors": [ { "message": "The caller does not have permission", "domain": "global", "reason": "forbidden" } ], "status": "PERMISSION_DENIED" } } ]] #25551
• [BUG] Setting GOOGLE_CLOUD_PROJECT env var breaks OAuth-based authentication #19865
• [Bug] oauth-personal login fails with 403 PERMISSION_DENIED — backend returns unexpected cloudaicompanionProject for personal Google AI Pro account #25189
• 403 error #25193

If you believe this is not a duplicate, please remove the status/possible-duplicate label.

[RIDDHIDEV-OPS]

It looks like the issue may come from OAuth/personal-account flows still passing through the GOOGLE_CLOUD_PROJECT resolution path even when no explicit GCP project should be required.

A possible long-term fix could be:

• separating personal OAuth auth flow from enterprise/project-based auth earlier in initialization,
• and adding a fallback resolver before loadCodeAssist.

Might also help to add integration tests covering:

• personal Google One accounts,
• missing GOOGLE_CLOUD_PROJECT,
• and mixed OAuth/API-key setups.

I’d be interested in helping test or prototype a cleaner auth-routing approach here.

[gemini-cli]

Please provide your CLI version (run gemini --version).

[tuapuikia]

it's mean your account is not allow to use gemini cli. you can use gemini.google.com and other services. Please contact Google cloud to resolve this issue.

[gemini-cli]

This item was marked as needing more information and has not received a response in 14 days. Closing it for now. If you still face this problem, feel free to reopen with more details. Thank you!