What happened?
When a user with a standard Google Account (e.g., Gemini Advanced / Free Tier) authenticates via LOGIN_WITH_GOOGLE, they encounter a 403 PERMISSION_DENIED (or "Cloud Code Private API" Ghost Project) error if the GOOGLE_CLOUD_PROJECT environment variable is set on their host machine.
This issue was previously raised in #19865 and #26105. It was closed with the note that requiring GOOGLE_CLOUD_PROJECT is intended behavior for Googlers.
However, treating GOOGLE_CLOUD_PROJECT as a strict override for all users breaks the experience for non-Googlers (like Gemini Advanced subscribers) who happen to have this environment variable set locally for their own personal dev projects. The CLI incorrectly attempts to route their Code Assist requests through their personal GCP project, causing an immediate 403 error.
What did you expect to happen?
The CLI should successfully authenticate for Gemini Advanced / Free Tier users even if GOOGLE_CLOUD_PROJECT is set locally. It should gracefully fall back to the environment variable only if the backend requires a specific project (e.g., for Workspace GCA users or Googlers).
Client information
OS: darwin
Auth Method: LOGIN_WITH_GOOGLE
Login information
No response
Anything else we need to know?
I understand the need to enforce GOOGLE_CLOUD_PROJECT for Workspace GCA users and Googlers. Therefore, I have submitted PR #26420 which introduces a Conditional Double-Load Fallback Strategy in setupUser:
- When
authType === LOGIN_WITH_GOOGLE, it initially attempts to authenticate without forcing the envProjectId. This allows Free Tier/Gemini Advanced users to be correctly assigned a server-managed project.
- If the backend responds with a
ProjectIdRequiredError or IneligibleTierError (which is exactly what happens for Googlers / GCA Workspace users who must use a specific project), the CLI safely catches this and falls back to using process.env.GOOGLE_CLOUD_PROJECT.
This gracefully solves the 403 bug for general users while preserving the exact intended behavior for Googlers and COMPUTE_ADC users.
What happened?
When a user with a standard Google Account (e.g., Gemini Advanced / Free Tier) authenticates via
LOGIN_WITH_GOOGLE, they encounter a403 PERMISSION_DENIED(or "Cloud Code Private API" Ghost Project) error if theGOOGLE_CLOUD_PROJECTenvironment variable is set on their host machine.This issue was previously raised in #19865 and #26105. It was closed with the note that requiring
GOOGLE_CLOUD_PROJECTis intended behavior for Googlers.However, treating
GOOGLE_CLOUD_PROJECTas a strict override for all users breaks the experience for non-Googlers (like Gemini Advanced subscribers) who happen to have this environment variable set locally for their own personal dev projects. The CLI incorrectly attempts to route their Code Assist requests through their personal GCP project, causing an immediate 403 error.What did you expect to happen?
The CLI should successfully authenticate for Gemini Advanced / Free Tier users even if
GOOGLE_CLOUD_PROJECTis set locally. It should gracefully fall back to the environment variable only if the backend requires a specific project (e.g., for Workspace GCA users or Googlers).Client information
OS: darwin
Auth Method: LOGIN_WITH_GOOGLE
Login information
No response
Anything else we need to know?
I understand the need to enforce
GOOGLE_CLOUD_PROJECTfor Workspace GCA users and Googlers. Therefore, I have submitted PR #26420 which introduces a Conditional Double-Load Fallback Strategy insetupUser:authType === LOGIN_WITH_GOOGLE, it initially attempts to authenticate without forcing theenvProjectId. This allows Free Tier/Gemini Advanced users to be correctly assigned a server-managed project.ProjectIdRequiredErrororIneligibleTierError(which is exactly what happens for Googlers / GCA Workspace users who must use a specific project), the CLI safely catches this and falls back to usingprocess.env.GOOGLE_CLOUD_PROJECT.This gracefully solves the 403 bug for general users while preserving the exact intended behavior for Googlers and
COMPUTE_ADCusers.