What happened?
Authenticated via "Sign in with Google" using a Google One AI Pro account. The CLI banner correctly identifies the tier as "Plan: Gemini Code Assist in Google One AI Pro". However, every prompt — including a single hi — fails immediately with:
[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"}}]
Failing endpoint: cloudcode-pa.googleapis.com/v1internal:streamGenerateContent
After a full local reset (deleted oauth_creds.json, projects.json, google_accounts.json, state.json) and a fresh OAuth login, ~/.gemini/projects.json is immediately re-created by the CLI with a server-returned ghost project ID:
{
"projects": {
"/Users/<me>/Desktop/Obsidian Vault": "obsidian-vault"
}
}
The same pattern repeats across every working directory I've ever opened the CLI in — each one gets a different ghost cloudaicompanionProject value injected by the backend loadCodeAssist call. None of these projects exist in my GCP account, so my OAuth identity has no permission on them → 403 on every request.
This matches the root-cause analysis in #25189 (backend returns cloudaicompanionProject for personal AI Pro accounts; CLI auto-uses it; account has no access to it). Filing as an additional affected account to help Google escalate the server-side reset.
### What did you expect to happen?
For a personal Google account with an active Google One AI Pro subscription using oauth-personal, loadCodeAssist should NOT return a cloudaicompanionProject value. The CLI should route to the standard managed-project personal-account flow and streamGenerateContent should succeed.
### Client information
* **CLI Version:** 0.37.2
* **Git Commit:** 545e956c3
* **Session ID:** 75debace-93f4-4b5c-be2e-c307775758ae
* **Operating System:** darwin v25.9.0
* **Sandbox Environment:** no sandbox
* **Model Version:** auto-gemini-3
* **Auth Type:** oauth-personal
* **Memory Usage:** 271.9 MB
* **Terminal Name:** ghostty 1.3.1
* **Terminal Background:** #282c34
* **Kitty Keyboard Protocol:** Supported
Gemini One Account: boyu94828@gmail.com
### Login information
"Sign in with Google" (oauth-personal mode) using a personal Gmail account with an active Google One AI Pro subscription. No GCP project explicitly configured. No GOOGLE_CLOUD_PROJECT, GEMINI_API_KEY, or GOOGLE_API_KEY set in the environment. gcloud auth list shows the same account is also authenticated to gcloud (independently — not used by the CLI).
### Anything else we need to know?
Workarounds tried — all failed:
- Removed ~/.gemini/projects.json → auto-recreated with same ghost project ID on next launch
- Full local state wipe (oauth_creds.json, projects.json, google_accounts.json, state.json) → ghost project re-injected after fresh OAuth
- Multiple re-auth cycles via /auth → no change
- Confirmed no env contamination (GOOGLE_CLOUD_PROJECT, GEMINI_API_KEY, GOOGLE_APPLICATION_CREDENTIALS all unset)
- brew upgrade gemini-cli blocked at 0.37.2 (Homebrew formula not yet bumped to 0.38.0); per #25189 and #25425, 0.38.0 does not fix the issue either
Control test: API-key mode works (per #25189 reporter and others), confirming the local CLI binary and network path are functional. The failure is specific to the oauth-personal backend entitlement path.
Asks for the team:
1. Reset the server-side cloudaicompanionProject binding for this account so oauth-personal routes to the standard personal-account flow.
2. Investigate why loadCodeAssist is returning ghost project IDs for personal Google AI Pro accounts at all (root cause shared with #25189 / #24747).
3. Provide a documented self-service escalation path — currently Google One support says "this is a Cloud issue" and Cloud support requires a paid plan, leaving affected paying AI Pro subscribers with no working channel.
Related issues:
- #25189 — primary root-cause analysis with source-code trace
- #25425 — April 10, 2026 regression timeline
- #24747 — same symptom in VS Code extension
- #24517 — original p1 report
What happened?
Authenticated via "Sign in with Google" using a Google One AI Pro account. The CLI banner correctly identifies the tier as "Plan: Gemini Code Assist in Google One AI Pro". However, every prompt — including a single
hi— fails immediately with:[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"}}]
Failing endpoint:
cloudcode-pa.googleapis.com/v1internal:streamGenerateContentAfter a full local reset (deleted
oauth_creds.json,projects.json,google_accounts.json,state.json) and a fresh OAuth login,~/.gemini/projects.jsonis immediately re-created by the CLI with a server-returned ghost project ID:{ "projects": { "/Users/<me>/Desktop/Obsidian Vault": "obsidian-vault" } } The same pattern repeats across every working directory I've ever opened the CLI in — each one gets a different ghost cloudaicompanionProject value injected by the backend loadCodeAssist call. None of these projects exist in my GCP account, so my OAuth identity has no permission on them → 403 on every request. This matches the root-cause analysis in #25189 (backend returns cloudaicompanionProject for personal AI Pro accounts; CLI auto-uses it; account has no access to it). Filing as an additional affected account to help Google escalate the server-side reset. ### What did you expect to happen? For a personal Google account with an active Google One AI Pro subscription using oauth-personal, loadCodeAssist should NOT return a cloudaicompanionProject value. The CLI should route to the standard managed-project personal-account flow and streamGenerateContent should succeed. ### Client information * **CLI Version:** 0.37.2 * **Git Commit:** 545e956c3 * **Session ID:** 75debace-93f4-4b5c-be2e-c307775758ae * **Operating System:** darwin v25.9.0 * **Sandbox Environment:** no sandbox * **Model Version:** auto-gemini-3 * **Auth Type:** oauth-personal * **Memory Usage:** 271.9 MB * **Terminal Name:** ghostty 1.3.1 * **Terminal Background:** #282c34 * **Kitty Keyboard Protocol:** Supported Gemini One Account: boyu94828@gmail.com ### Login information "Sign in with Google" (oauth-personal mode) using a personal Gmail account with an active Google One AI Pro subscription. No GCP project explicitly configured. No GOOGLE_CLOUD_PROJECT, GEMINI_API_KEY, or GOOGLE_API_KEY set in the environment. gcloud auth list shows the same account is also authenticated to gcloud (independently — not used by the CLI). ### Anything else we need to know? Workarounds tried — all failed: - Removed ~/.gemini/projects.json → auto-recreated with same ghost project ID on next launch - Full local state wipe (oauth_creds.json, projects.json, google_accounts.json, state.json) → ghost project re-injected after fresh OAuth - Multiple re-auth cycles via /auth → no change - Confirmed no env contamination (GOOGLE_CLOUD_PROJECT, GEMINI_API_KEY, GOOGLE_APPLICATION_CREDENTIALS all unset) - brew upgrade gemini-cli blocked at 0.37.2 (Homebrew formula not yet bumped to 0.38.0); per #25189 and #25425, 0.38.0 does not fix the issue either Control test: API-key mode works (per #25189 reporter and others), confirming the local CLI binary and network path are functional. The failure is specific to the oauth-personal backend entitlement path. Asks for the team: 1. Reset the server-side cloudaicompanionProject binding for this account so oauth-personal routes to the standard personal-account flow. 2. Investigate why loadCodeAssist is returning ghost project IDs for personal Google AI Pro accounts at all (root cause shared with #25189 / #24747). 3. Provide a documented self-service escalation path — currently Google One support says "this is a Cloud issue" and Cloud support requires a paid plan, leaving affected paying AI Pro subscribers with no working channel. Related issues: - #25189 — primary root-cause analysis with source-code trace - #25425 — April 10, 2026 regression timeline - #24747 — same symptom in VS Code extension - #24517 — original p1 report