Bug: Gemini CLI Enterprise (Workspace) OAuth bypasses Admin API controls & fails project linking, causing /privacy error [#2407]

[jclicky]

What happened?

Our Google Workspace Enterprise Plus organization has our Google Admin console "API controls" set to "Don't allow users to access any third-party apps” (https://support.google.com/a/answer/7281227) & “Allow users to request access to unconfigured third-party apps” at this Admin Console Endpoint (https://admin.google.com/ac/owl/settings) to enforce a default-deny security posture.

Despite this, our enterprise users (with Workspace Enterprise Plus licenses) are able to successfully authenticate to the Gemini CLI using "Option 1: Login with Google (OAuth)". Users reach this endpoint when they ought to be redirected to a GCP-project-specific endpoint to confirm if they have access to a specific GCP account with the right permissions to bill calls to the appropriate Gemini APIs (if activated on that GCP Project) & bill to that GCP project. No check or handshake occurs & end-users (after ONLY selecting their Google Workspace account via OAuth) reach this screen:

See: https://google-gemini.github.io/gemini-cli/docs/get-started/authentication.html & https://github.com/google-gemini/gemini-cli

The authentication is being granted to a global, Google-owned OAuth Client ID: 681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com. This Client ID has not been configured or trusted in our Google Admin console's "App access control" list.

This appears to be a critical administrative governance failure, as this Google-owned application is bypassing the explicit API controls set by our administrators here at this endpoint: https://admin.google.com/ac/owl/list?tab=configuredApps.

This flawed authentication flow has two significant side-effects:

1. No GCP Project Selection: The authentication flow never prompts our enterprise users to select a Google Cloud Platform (GCP) Project. This is in direct conflict with the enterprise setup documentation for Gemini Code Assist and the CLI's own documentation, which states enterprise users must "remember to set the Google Cloud Project".

   • As a matter of fact, whenever end-users manually navigate to goo.gle/set-up-gemini-code-assist, as found on line 75 here: https://github.com/google-gemini/gemini-cli/blame/cb0947c5019ae6b6251199a9a3b9ac6b6c8ce3ef/docs/quota-and-pricing.md#L75 within the https://github.com/google-gemini/gemini-cli/blob/main/docs/quota-and-pricing.md documentation in the Gemini CLI repo), and those users OAuth with their Google Workspace Enterprise Plus accounts, the page correctly returns an error similar to (https://developers.google.com/gemini-code-assist/resources/faqs):
   

2. Broken Privacy State: Once authenticated (again, ONLY to a Google Workspace Enterprise Plus account), running the /privacy command in the CLI fails [similar to /privacy: Error loading Opt-in settings: User does not have a current tier #2407] with the error: Error loading Opt-in settings: User does not have a current tier. Pres Esc to exit. This suggests the backend (er, frontend?) recognizes the user has authenticated with enterprise account (which has no consumer "tier") vs. a Google One account, but is stuck in a broken state because the authentication path / OAuth was incorrect and/or incomplete.
   

What did you expect to happen?

We expected one of two outcomes:

Expected Outcome A (Policy Enforced):
The OAuth attempt should be blocked by our Google Workspace policy. The user should receive an admin_policy_enforced error because the Client ID 681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com is an "unconfigured third-party app" and should be blocked per our Admin console settings.

For example, the CLASP CLI (https://github.com/google/clasp), a Google Application, also specifically required our Google Workspace Administrators to whitelist it's corresponding Client ID 1072944905499-vm2v2i5dvn0a0d2o4ca36i1vge8cvbn0.apps.googleusercontent.com for the CLASP tool to be available to end-users, as does the multitude of Google Event pages / interfaces / applications for Cloud Next + I/O, etc.

Expected Outcome B (Correct Enterprise Auth Flow):
Alternatively, if Google-owned apps are intended to bypass this third-party app block (unlikely, again, given the CLASP CLI & other Google Apps Governance):

1. The authentication system should still detect if the user has a "paid Code Assist License from [their] organization" - it should have a methodology via redirect to see if the User has such a license & the authorities to commit expenses to it vs. the current OAuth flow.
2. The OAuth flow should then force the user down the enterprise authentication path (documented as the "Vertex AI" path), unless the OAuth is intentionally & expressly permitted to Google Workspace Enterprise end-users at the OAuth-tier (unlikely given that Gemini CLI is absent from Gemini AI Ultra tier documentation for business), in which case the API governance should still enable admins to either permit or block the Gemini Code Assist and Gemini CLI app
3. If Google envisions for all Workspace Enterprise end-users to only ever authenticate via GCP, then the enterprise OAuth path should mandate that the user "set the Google Cloud Project" and verify they have the correct IAM roles and that the geminicloudassist API is enabled on that project before authentication succeeds. This is the end-user OAuth behavior we see in the Gemini Code Assist IDE plugin (an OAuth event to Workspace Enterprise account still forces the user to set a specific GCP project, after which the plugin confirms that end-user has the appropriate permissions for said GCP Project and that it has the requisite APIs activated), but the Gemini CLI is failing to follow that same flow. https://docs.cloud.google.com/gemini/docs/discover/set-up-gemini

Client information

Client Information

Run gemini to enter the interactive CLI, then run the /about command.

> /about

╭────────────────────────────────────────────╮
│                                            │
│ About Gemini CLI                           │
│                                            │
│ CLI Version    0.10.0                      │
│ Git Commit     5d92b507                    │
│ Model          gemini-2.5-pro              │
│ Sandbox        no sandbox                  │
│ OS             darwin                      │
│ Auth Method    OAuth                       │
│                                            │
╰────────────────────────────────────────────╯

Login information

We are using Option 1: Login with Google (OAuth login using your Google Account), as described in the authentication guide.
A.) Enter command /auth
B.) Open OAuth session via browser (initiated from within Gemini CLI on Google account in browser, select correct specific account
C.) Redirected to this endpoint: https://developers.google.com/gemini-code-assist/auth/auth_success_gemini

We are not using Option 2 (Gemini API Key) or Option 3 (Vertex AI / gcloud auth).

The core issue is that our Enterprise users are being incorrectly funneled down this "Option 1" consumer-style path, which is where the governance failures (bypassed API controls, no project linking) are happening, then when they try using /privacy they receive an error, leading to open-questions about our data governance.

Anything else we need to know?

This appears to be a critical gap in administrative governance with serious data privacy implications. Our primary concern is that if our enterprise users - who are contractually guaranteed "no training, no human review" data protections - are being authenticated through a consumer-facing, global Client ID, we have no way to audit or verify that these enterprise protections are being technically applied. The /privacy error is our only indication that the system recognizes the user's non-consumer status.

This issue is compounded by conflicting documentation:

• Google One (consumer) documentation explicitly lists "Gemini CLI" as a feature of its AI Premium plans in two places here (“Gemini CLI and Gemini Code Assist”) for the features of AI Ultra and AI Pro, respectively:
  1. https://support.google.com/googleone/answer/16286513
  2. https://support.google.com/googleone/answer/14534406
• Google Workspace for Business (enterprise) Gemini Ultra documentation does not list Gemini CLI as a feature here:
  1. https://support.google.com/a/answer/16345165
• When our enterprise users click official setup links for Gemini Code Assist (like goo.gle/set-up-gemini-code-assist, as found on line 75 here: https://github.com/google-gemini/gemini-cli/blame/cb0947c5019ae6b6251199a9a3b9ac6b6c8ce3ef/docs/quota-and-pricing.md#L75 within the https://github.com/google-gemini/gemini-cli/blob/main/docs/quota-and-pricing.md documentation in the Gemini CLI repo), the page correctly returns an error similar to (https://developers.google.com/gemini-code-assist/resources/faqs).

This creates an incoherent experience where our users are (correctly) told they are ineligible (if they proactively check via an esoteric link buried in GitLab quota documentation at all), but the CLI still authenticates them (incorrectly) by bypassing our admin controls, landing them in a broken, semi-authenticated state where effective data-privacy / governance controls for the session are unclear and inconsistent with available public documentation.

Google Workspace Enterprise Plus End-users reasonably expect for data-governance to apply to any authenticated Google service using their Workspace account, preventing data retention and/or the use of data to train models, but this may or may not be in-effect for end-users in this incomplete (current) OAuth flow, leading to a sub-standard developer experience and inability to enforce disciplined data-governance at an organizational level.

The only functional (but complex) workaround is to manually force the enterprise path (Option 3: Vertex AI) by running gcloud auth application-default login and setting the GOOGLE_CLOUD_PROJECT environment variable. The default "Login with Google" (Option 1) should not be available as a bypass for enterprise accounts whose admins have blocked third-party apps.

Corresponding Google Issue Tracker (Buganizer) Issue (Number 455605678): https://issuetracker.google.com/issues/455605678

Implicated Code:

1. gemini-cli/packages/cli/src/ui/commands/privacyCommand.ts

   Line 4 in 6db64aa

   * SPDX-License-Identifier: Apache-2.0

2. gemini-cli/docs/cli/commands.md

   Line 200 in 6db64aa

   - **`/privacy`**

3. gemini-cli/docs/cli/commands.md

   Line 200 in 6db64aa

   - **`/privacy`**

Related Issues:

• /privacy: Error loading Opt-in settings: User does not have a current tier #2407 - Error loading opt-in settings even when google_cloud_project is set
• [Bug] privacy command becomes unresponsive on error #2404 - /privacy command not functioning
• Unclear relations to privacy policy and terms #1454 - Privacy paradigm unclear amidst incomplete / inconsistent / deficient documentation
• No Privacy Data Collection Notice or Opt-Out – GDPR Non-Compliant #1489 - GDPR non-compliance without a fully-functional /privacy command
• Clarify use of user's code for training within the free quota on paid service #1472 - Use of user's code for training is unclear - here (in this issue) it's unclear when/if an Enterprise End-user authenticates via OAth
• Need more clarification on Terms of Service and Privacy Notice on default vs. opt-in setting and data of interest #3851 - As here, ToS was unclear - in this specific case, is the Client ID for Gemini Code Assist and Gemini CLI (this one here: 681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com) intentionally permitted to bypass Google Workspace Enterprise API controls, and if so, can we confirm which ToS applies to such a bypassed authentication?
• Failed to login. Message: Failed to exchange authorization code for tokens https://oauth2.googleapis.com/token failed, reason #8170 - possible that fixing this ability for this end-user to authenticate broke a OAuth stage-gate / check that is needed to force appropriate Enterprise-grade authentication.
• Account login not possible from headless machine #1833 - public end-user reports the same Client ID we never whitelisted in our Google Workspace API controls: (client_id=681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com)
• Cannot login using Google Account on terminal only environment #1443 - public end-user reports the same Client ID we never whitelisted in our Google Workspace API controls: (client_id=681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com)
• Using Gemini with sandboxing enabled results in no editor being found #5134 - public end-user reports the same Client ID we never whitelisted in our Google Workspace API controls: (client_id=681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com)

[jclicky]

For readability / ease of access, directly posting a link to the corresponding / matching Buganizer Issue I submitted here: https://issuetracker.google.com/issues/455605678

[gsquared94]

Tagging @cornmander for privacy and security implications.

[codeblooded]

I am a workspace customer impacted by this issue. The CLI let me use it on my workspace account, and I believed I was under the protections of the Workspace Cloud Processing Data Addendum and Enterprise Code Assist Terms. Notably, I did not & do not consent to the individual/consumer terms for data processing under my workspace account. Nor did my organization.

I have not used Gemini code assist in any editors, but I subscribed to Code Assist on GCP Console with automatic licensing. It did not automatically activate my license, despite that setting. I completed several sessions with Gemini CLI before it asked me for a GCP Project environment variable, and I realized something was wrong. I downloaded the extension in VS Code, signed in with the same account, and it said my workspace account was ineligible (see screenshot).

The FAQ says:

If you're encountering a message saying you are not eligible for Gemini Code Assist for individuals, then it's mostly likely because of the type of Google Account you're using.

The free version of Gemini Code Assist, Gemini Code Assist for individuals, is not yet available for Google Workspace accounts or people under the age of consent in their jurisdictions.

I would really like to escalate the severity of this vulnerability. As a cloud customer, I...

• Do not know which terms and policies my gemini-cli data was processed under
• Never consented to any individual/consumer processing terms
• Believed to be using the tool under the Cloud Data Processing Addendum & Code Assist terms

Can we get assurances that data mistakenly processed under this (Workspace & Enterprise agreements) is (1) not used for human review, annotation and training; and (2) will honor the deletion terms of our workspace accounts?

I'm happy to connect personally and provide session IDs that may be misclassified.

[codeblooded]

The authentication docs are also ambiguous on this issue.

(Optional) Set your GOOGLE_CLOUD_PROJECT
When you log in using a Google account, you may be prompted to select a GOOGLE_CLOUD_PROJECT.

This can be necessary if you are:

Using a Google Workspace account.
Using a Gemini Code Assist license from the Google Developer Program.
Using a license from a Gemini Code Assist subscription.
Using the product outside the supported regions for free individual usage.
A Google account holder under the age of 18.

https://google-gemini.github.io/gemini-cli/docs/get-started/authentication.html

[jclicky]

I am a workspace customer impacted by this issue. The CLI let me use it on my workspace account, and I believed I was under the protections of the Workspace Cloud Processing Data Addendum and Enterprise Code Assist Terms. Notably, I did not & do not consent to the individual/consumer terms for data processing under my workspace account. Nor did my organization.

I have not used Gemini code assist in any editors, but I subscribed to Code Assist on GCP Console with automatic licensing. It did not automatically activate my license, despite that setting. I completed several sessions with Gemini CLI before it asked me for a GCP Project environment variable, and I realized something was wrong. I downloaded the extension in VS Code, signed in with the same account, and it said my workspace account was ineligible (see screenshot).

The FAQ says:

If you're encountering a message saying you are not eligible for Gemini Code Assist for individuals, then it's mostly likely because of the type of Google Account you're using.
The free version of Gemini Code Assist, Gemini Code Assist for individuals, is not yet available for Google Workspace accounts or people under the age of consent in their jurisdictions.

I would really like to escalate the severity of this vulnerability. As a cloud customer, I...

• Do not know which terms and policies my gemini-cli data was processed under
• Never consented to any individual/consumer processing terms
• Believed to be using the tool under the Cloud Data Processing Addendum & Code Assist terms

Can we get assurances that data mistakenly processed under this (Workspace & Enterprise agreements) is (1) not used for human review, annotation and training; and (2) will honor the deletion terms of our workspace accounts?

I'm happy to connect personally and provide session IDs that may be misclassified.

Thank you for underscoring the divergent behavior I had observed on the Gemini Code Assist OAuth flow (wherein the UX / UI is correctly recognizing the need to set GCP projects to establish an enterprise-grade session).

This, to me, is dispositive evidence, though the documentation is, as you correctly point out, unclear, that it's possible our sessions may be falling back into a public-tier privacy session with these half-authenticated sessions.

One other point (feature request?) that would aid in the Google Workspace Documentation:
Google needs to separate out the Application used to authenticate into an independent App / Client ID exclusively for Gemini CLI, independent of Gemini Code Assist

While I appreciate that Google's product leads view this as one & the same, it robs us Google Workspace Admins of the ability to deploy specific governance controls:

• If we were to whitelist the ability of individuals to authenticate for Gemini CLI, we also are granting permissions for users to use separate products, namely the Gemini Code Assist product(s) - i.e. the Gemini Code Assist VSCode plugin
• Workspace Admins, for proper data governance / controls / safety, deserve the ability to deploy granular permisions at the API / OAuth whitelisting settings for our end-users
• That need is especially important here given that Gemini Code Assist VSCode plugin application appears to be handing OAuth better for me / my users vs. Gemini CLI (which let me / users send chats / context / code to Gemini APIs w/out a GCP Project); the VSCode Gemini Code Assist plugin correctly enforced a discipline for end-users to set a specific GCP project after they authenticated to a Workspace account via OAuth
• Given the better stability / governance cooperation / rails set in the Application (the VSCode plugin) vs. Gemini CLI, workspace admins might be required by cybersecurity policy / governance requirements / stakeholders to whitelist one and not the other, to ensure their end-users are reliably sending data / chats / prompts / context to/from Gemini APIs in a secure method vs. this partially authenticated / incomplete / unsecure method that these partial OAuths are permitting.

[jclicky]

Hey @gsquared94 disappointing to see my corresponding buganizer was erroneously closed as infeasible given that here (as of 10.30.25) we have this issue marked as a p0 & on the roadmap for Gemini CLI. Can you help us ensure that Buganizer ticket isn't prematurely & inappropriately closed?

https://issuetracker.google.com/issues/455605678

My primary concern here is multifold:

• Gemini CLI team can do some work here to partially remediate issues, ensuring no Gemini API calls are able to be sent to/from a Gemini CLI session & Google's servers on a partial / incomplete auth and/or whenever someone ineligible for personal/free-tier Gemini Cloud Assist licenses (read: if they are a Google Workspace Enterprise Plus user) has OAuthed

• Rightsizing the API governance for Workspace Customers who restrict all apps (even Google Ones, like us, CLASP, which we had to manually approve, good thing), for the Gemini Cloud Assist and Gemini CLI app (Client ID 681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com) which Gemini CLI uses to confirm an end-user's OAuth & activate calls is - in my mind - ABSOLUTELY feasible for a Buganizer ticket for the GCP team to ship a fix for; regardless of the independent behavior of the Gemini CLI as an effective front-end, how can we be sure to have proper governance at the Workspace level to control access to this tool if API / App zero-trust policies aren't respected for the Gemini Cloud Assist and Gemini CLI app?

• Further, exporting logs of OAuth applications, either Google affiliated ones or inclusive of ALL apps authorized by my users in Google Workspace, returned a log devoid of the Gemini Cloud Assist and Gemini CLI app (Client ID 681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com) which Gemini CLI uses. I had to run logs specifically targeting the Client ID 681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com in the Google Workspace Admin Console to reveal the activity.

I'm very grateful we got your eyes on this bug immediately here thru this methodology in the open-source repo, as I am concerned the all-too-common mark as infeasible move in Buganizer would have otherwise relegated this this wide open bug to the waste-bin.

To summarize, here's what I am hoping will happen to rightsize potential leaking & bypassing of confidential workspace enterprise users' confidential IP / code / chats / data / etc. in incompletely authenticated Gemini CLI sessions that shouldn't have been active:

• The Gemini CLI team here will work to fix the OAuth logic (thank you) for the Option 1: Login with Google flow for customers ineligible for a personal/free-tier Gemini Code Assist license (on Google One) because they have a business and/or Enterprise license preventing their data from being retained / reviewed / used in Model training.
• Concurrently, via the concurrent Buganizer 455605678 I submitted, the GCP team will fix the behavior of the the Gemini Cloud Assist and Gemini CLI app (Client ID 681255809395-oo8ft2oprdrnp9e3aqf6av3hmdib135j.apps.googleusercontent.com) so it respects to Workspace Customer's zero-trust governance settings, our cloud service agreements, permits clients to manage users & our data, activates Gemini Cloud Assist licenses set to auto-assign (as it has failed to do so thus far in our environment & GCP org and that of @codeblooded as well)
• Ideally (and happy to submit this as a feature request here, lmk), in concert with the Gemini CLI team, the GCP team can enable us to govern access to Gemini APIs with independent Apps to either allowlist or restrict, each conforming to our Workspace Governance settings & respecting our zero-trust settings, with two apps, each with independent Client IDs to govern with and track in logs independently: (1) Gemini Code Assist (for calling Gemini APIs in the VSCode plugin, in IDEs like Cursor, on GCP Cloud Editor, etc.) & (2) Gemini CLI as a new independent Client ID / App for administrators in workspace to either whitelist or restrict to Groups, User Groups as we seek to control & limit impacts to our companies' PII or other user confidential information, in particular when/if our IT infrastructure is audited and / or Workspace clients are seeking certifications under NIST or ISO standards.

Until these efforts are taken seriously I have to recommend against any adoption internally of Gemini CLI and perhaps any other Gemini product.

One other Point:
Mind you, numerous environments have likely experimented with the Gemini CLI via GitHub actions (which you can also deploy in GitLab via their experimental GitHub actions feature); if any of these sessions were incompletely authenticated with similar / related bugs, entire confidential corporate repos' MRs & code-diffs may have had incorrect and/or no data governance applied.

Please help us escalate this ticket appropriately in the Buganizer system to match the severity the Gemini CLI team (appropriately, thank you) has adjudicated here.