### What would you like to be added?
Currently, selecting "1. Sign in with Google" fails for individual Google accounts / Google AI Pro subscribers with:
> `Failed to sign in. Message: This client is no longer supported for Gemini Code Assist for individuals.`
While Enterprise users can sign in via Workspace/GCP, independent developers who want to use the CLI for coding tasks, code reviews, system administration, and CLI tool building are blocked unless they manually configure API keys.
### Why is this needed?
Provide an onboarding option specifically for the developer community:
Developer OAuth Flow:Allow individual Google accounts to sign in and route through Google AI Studio free/metered tier directly.
Custom OAuth / Credential Helper:Allow developers to link their own Google Cloud OAuth Client ID for personal use.
### Additional context
Lowers barrier to entry:Developers can use `gemini` in 1-click without managing environment variables.
Drives adoption & contributions:Enables individual developers to use the CLI for day-to-day coding, terminal automation, and code reviews, growing the `gemini-cli` open-source ecosystem.
Hi! I’m interested in contributing to this feature.
I understand the current problem as a distinction between the existing Google Sign-In flow for Gemini Code Assist and a developer-oriented OAuth flow that would allow individual developers to authenticate for Gemini CLI usage.
From the issue, I think the implementation needs to clearly separate authentication from the backend/product entitlement being used. The goal should be to allow an individual Google account to authenticate without weakening the existing enterprise authentication or credential handling.
I’d be interested in investigating the current authentication architecture and determining:
1. Where the existing “Sign in with Google” flow is initiated and how the OAuth client is configured.
2. How the resulting credentials are stored, refreshed, and selected by the CLI.
3. Whether an AI Studio / developer OAuth flow can be introduced as a separate authentication mode without changing the existing Workspace/GCP flow.
4. How the CLI should distinguish Developer Login credentials from existing Google/enterprise credentials.
5. How users should explicitly select the developer authentication mode during onboarding.
6. How secure credential storage and token refresh should work across Windows, macOS, and Linux.
7. How the authentication flow should behave when a user has multiple Google accounts or existing cached credentials.
For implementation, I would favor an explicit developer authentication path rather than silently changing the behavior of the current “Sign in with Google” option. This should make the security and authentication boundary clear and reduce the risk of changing enterprise login behavior unintentionally.
I’d also want regression coverage for:
- Individual Google account using Developer Login.
- Existing enterprise/Workspace authentication remaining unchanged.
- Expired access token being refreshed correctly.
- Re-running the CLI with existing cached developer credentials.
- Switching between authentication methods.
- Invalid/revoked credentials producing a clear error.
- Ensuring sensitive OAuth tokens are never written to logs or exposed in terminal output.
Before starting implementation, I’d appreciate maintainer guidance on the intended OAuth client/application registration and whether the preferred direction is a dedicated Developer Login flow, a user-supplied OAuth client, or support for both.
I’d be happy to investigate the existing auth code and prepare a scoped implementation once the intended flow is confirmed.