fix(gemini-cli): use backend project ID from onboarding response by kslamph · Pull Request #2416 · router-for-me/CLIProxyAPI

kslamph · 2026-03-30T11:50:41Z

Summary

Simplify Gemini CLI project ID selection to always use the backend project ID returned by the onboarding response, removing the free/pro user distinction that caused authentication failures for some users
Update Gemini CLI version from 0.31.0 to 0.34.0
Add 'terminal' to User-Agent string for better client identification

Test plan

Verify Gemini CLI login works correctly with the updated project ID handling
Confirm authentication errors ("缺少验证") are resolved
Test with both free and pro tier accounts

🤖 Generated with Claude Code

- Simplify project ID selection to always use the backend project ID returned by Gemini onboarding - Update Gemini CLI version from 0.31.0 to 0.34.0 - Add 'terminal' to User-Agent string for better client identification Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

gemini-code-assist

Code Review

This pull request updates the .gitignore file, increments the GeminiCLIVersion to 0.34.0, and modifies the User-Agent string. It also simplifies the project ID mapping logic in performGeminiCLISetup by removing user-tier checks and interactive prompts. Feedback suggests refactoring the duplicated performGeminiCLISetup function into a shared package and simplifying the project ID assignment logic to eliminate redundant conditional branches.

gemini-code-assist · 2026-03-30T11:52:22Z

internal/cmd/login.go

 				if explicitProject && !strings.EqualFold(responseProjectID, projectID) {
-					// Check if this is a free user (gen-lang-client projects or free/legacy tier)
-					isFreeUser := strings.HasPrefix(projectID, "gen-lang-client-") ||
-						strings.EqualFold(tierID, "FREE") ||
-						strings.EqualFold(tierID, "LEGACY")
-
-					if isFreeUser {
-						// Interactive prompt for free users
-						fmt.Printf("\nGoogle returned a different project ID:\n")
-						fmt.Printf("  Requested (frontend): %s\n", projectID)
-						fmt.Printf("  Returned (backend):   %s\n\n", responseProjectID)
-						fmt.Printf("  Backend project IDs have access to preview models (gemini-3-*).\n")
-						fmt.Printf("  This is normal for free tier users.\n\n")
-						fmt.Printf("Which project ID would you like to use?\n")
-						fmt.Printf("  [1] Backend (recommended): %s\n", responseProjectID)
-						fmt.Printf("  [2] Frontend: %s\n\n", projectID)
-						fmt.Printf("Enter choice [1]: ")
-
-						reader := bufio.NewReader(os.Stdin)
-						choice, _ := reader.ReadString('\n')
-						choice = strings.TrimSpace(choice)
-
-						if choice == "2" {
-							log.Infof("Using frontend project ID: %s", projectID)
-							fmt.Println(". Warning: Frontend project IDs may not have access to preview models.")
-							finalProjectID = projectID
-						} else {
-							log.Infof("Using backend project ID: %s (recommended)", responseProjectID)
-							finalProjectID = responseProjectID
-						}
-					} else {
-						// Pro users: keep requested project ID (original behavior)
-						log.Warnf("Gemini onboarding returned project %s instead of requested %s; keeping requested project ID.", responseProjectID, projectID)
-					}
+					log.Infof("Gemini onboarding: requested project %s maps to backend project %s", projectID, responseProjectID)
+					log.Infof("Using backend project ID: %s", responseProjectID)
+					finalProjectID = responseProjectID
 				} else {
 					finalProjectID = responseProjectID
 				}


This logic is also present in internal/api/handlers/management/auth_files.go. In fact, the entire performGeminiCLISetup function is duplicated across both files.

With the changes in this PR, the logic has become identical. To improve maintainability and avoid having to apply the same changes in multiple places, this function should be extracted to a shared package (e.g., within internal/auth/gemini) and reused. This would prevent future inconsistencies and simplify maintenance.

gemini-code-assist · 2026-03-30T11:52:22Z

internal/api/handlers/management/auth_files.go

 				if explicitProject && !strings.EqualFold(responseProjectID, projectID) {
-					// Check if this is a free user (gen-lang-client projects or free/legacy tier)
-					isFreeUser := strings.HasPrefix(projectID, "gen-lang-client-") ||
-						strings.EqualFold(tierID, "FREE") ||
-						strings.EqualFold(tierID, "LEGACY")
-
-					if isFreeUser {
-						// For free users, use backend project ID for preview model access
-						log.Infof("Gemini onboarding: frontend project %s maps to backend project %s", projectID, responseProjectID)
-						log.Infof("Using backend project ID: %s (recommended for preview model access)", responseProjectID)
-						finalProjectID = responseProjectID
-					} else {
-						// Pro users: keep requested project ID (original behavior)
-						log.Warnf("Gemini onboarding returned project %s instead of requested %s; keeping requested project ID.", responseProjectID, projectID)
-					}
+					log.Infof("Gemini onboarding: requested project %s maps to backend project %s", projectID, responseProjectID)
+					log.Infof("Using backend project ID: %s", responseProjectID)
+					finalProjectID = responseProjectID
 				} else {
 					finalProjectID = responseProjectID
 				}


This if/else block can be simplified. Both branches assign responseProjectID to finalProjectID. You can move the assignment out of the conditional block to make the code more concise, while keeping the logging inside the if.

if explicitProject && !strings.EqualFold(responseProjectID, projectID) { log.Infof("Gemini onboarding: requested project %s maps to backend project %s", projectID, responseProjectID) log.Infof("Using backend project ID: %s", responseProjectID) } finalProjectID = responseProjectID

xkonjin

Code Review: Gemini CLI Project ID Simplification

Good cleanup removing the tier-based branching logic. However, there are concerns:

Critical Issue - Code Duplication:
The performGeminiCLISetup function is duplicated in two files:

internal/api/handlers/management/auth_files.go (lines 2569-2577)
internal/cmd/login.go (lines 333-342)

The PR modifies both but they have diverged in comments and structure. The login.go version previously had interactive prompts that were removed, while auth_files.go had logging-only behavior. This should be refactored into a shared package as suggested by the Gemini Code Assist review.

Bug Risk:

Version Bump (line 15 in header_utils.go): Version bumped to 0.34.0 but no corresponding git tag or release notes. Ensure this matches the actual release version.
User-Agent Change (line 48): Added "; terminal" suffix. This could break API consumers that parse the User-Agent string. Verify this change is intentional and documented.

Missing Test Coverage:

No tests for the project ID mapping logic
No tests for the responseProjectID != projectID branch
No tests verifying free vs pro tier behavior (now unified)

Security Note:
The simplification removes the free/pro tier distinction. Verify this is intentional from a product perspective - previously free users got backend project IDs for preview model access, now everyone does. This could have quota/billing implications.

Recommendation:
Refactor into a shared pkg/gemini package to eliminate duplication before merging.

…ment Both branches assign finalProjectID = responseProjectID, so move the assignment outside the conditional and keep only the logging inside.

luispater

Summary

This PR simplifies Gemini CLI project ID handling by always using the backend project ID returned by the onboarding response (when present), which should avoid the “frontend vs backend project” mismatch that can lead to auth failures. It also bumps the reported Gemini CLI version and adds terminal to the User-Agent for clearer client identification.

Findings

✅ The project ID assignment logic is now deterministic: when responseProjectID is present, it becomes the stored ProjectID regardless of tier.
✅ The previous interactive prompt / free-vs-pro branching is removed, reducing complexity and failure modes.
⚠️ Behavior change: if a user explicitly requests a project ID and onboarding returns a different backend ID, the explicit choice is no longer honored. If this is intentional (per issue), it’s fine, but it’s worth documenting.

Checks / Tests

CI build passed.
No additional tests run locally.

Overall looks correct and low-risk given the small, targeted diff and successful CI.

This is an automated Codex review result and still requires manual verification by a human reviewer.

sususu98 · 2026-04-02T14:21:33Z

Thanks for the fix — the project ID simplification looks correct and aligns with upstream direction. One request before merging:

Please bump GeminiCLIVersion to 0.36.0 (current latest) instead of 0.34.0. The terminal surface identifier in the UA was introduced in v0.35.0, and 0.36.0 is the current stable release, so the fingerprint should match.

Everything else LGTM.

luispater · 2026-04-06T01:02:51Z

This PR is approved but currently has merge conflicts. Please change the base branch to dev, resolve the conflicts, and then wait for merge.

gemini-code-assist bot reviewed Mar 30, 2026

View reviewed changes

xkonjin reviewed Mar 30, 2026

View reviewed changes

refactor(gemini-cli): simplify redundant if/else in project ID assign…

91387ca

…ment Both branches assign finalProjectID = responseProjectID, so move the assignment outside the conditional and keep only the logging inside.

luispater approved these changes Apr 1, 2026

View reviewed changes

luispater added the codex label Apr 1, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(gemini-cli): use backend project ID from onboarding response#2416

fix(gemini-cli): use backend project ID from onboarding response#2416
kslamph wants to merge 2 commits intorouter-for-me:mainfrom
kslamph:fix/gemini-cli-projectid

kslamph commented Mar 30, 2026 •

edited

Loading

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot Mar 30, 2026

Uh oh!

gemini-code-assist bot Mar 30, 2026

Uh oh!

xkonjin left a comment

Uh oh!

luispater left a comment

Uh oh!

sususu98 commented Apr 2, 2026

Uh oh!

luispater commented Apr 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

kslamph commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test plan

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

xkonjin left a comment

Choose a reason for hiding this comment

Uh oh!

luispater left a comment

Choose a reason for hiding this comment

Summary

Findings

Checks / Tests

Uh oh!

sususu98 commented Apr 2, 2026

Uh oh!

luispater commented Apr 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

kslamph commented Mar 30, 2026 •

edited

Loading