Skip to content

Bug: 403 Permission Denied for Gemini Advanced users with GOOGLE_CLOUD_PROJECT set (Fallback solution proposed) #26564

@AndyAWD

Description

@AndyAWD

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:

  1. 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.
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    status/need-triageIssues that need to be triaged by the triage automation.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions