feat: Gemini CLI OAuth with Cloud Code API

[Mffff4]

Summary

Integrates the official Gemini CLI OAuth flow into IronClaw, enabling access to latest preview models (gemini-3.x) via Google's Cloud Code Assist API.

Changes

New: src/llm/gemini_oauth.rs

• Full OAuth 2.0 flow with PKCE (same client credentials as google/gemini-cli)
• Token refresh with automatic expiry detection
• Cloud Code project discovery via loadCodeAssist + onboardUser (cloudcode-pa.googleapis.com)
• Dual API routing: preview/gemini-3 models → Cloud Code API, legacy models → generativelanguage API
• SSE stream parsing for Cloud Code responses
• Manual redirect URL paste as fallback when browser redirect fails (tokio::select! race)
• HTTP 429 rate-limit parsing (retry_after from reset after Xs message)

Modified: src/setup/wizard.rs

• setup_gemini_oauth() is now async — triggers full OAuth login during onboarding (not first chat)
• Model list trimmed to gemini-3.x preview models only

Modified: src/config/llm.rs, src/config/mod.rs, src/llm/mod.rs

• Added GeminiOauthConfig with default credentials path (~/.gemini/oauth_creds.json)
• Registered gemini_oauth as a new LLM backend

Testing

1. rm ~/.gemini/oauth_creds.json && cargo run -- onboard
2. Select "Gemini CLI" provider → authenticate in browser
3. Select gemini-3.1-pro-preview → send a message
4. Verify rate-limit errors show proper wait time instead of instant retries

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly expands the application's capabilities by integrating the official Gemini CLI OAuth flow. This enables users to access the latest Gemini preview models (Gemini 3.x) through Google's Cloud Code Assist API, streamlining authentication and model access. The changes ensure a more robust and user-friendly experience for interacting with advanced Gemini models.

Highlights

• Gemini CLI OAuth Integration: Introduced a comprehensive OAuth 2.0 flow with PKCE, mirroring the official Google Gemini CLI, to enable authentication for Gemini API access.
• Cloud Code API Support: Implemented dual API routing to direct requests for preview/Gemini 3.x models to the Google Cloud Code Assist API, while routing legacy models to the Generative Language API. This includes Cloud Code project discovery and SSE stream parsing for responses.
• Enhanced Onboarding Experience: Modified the setup wizard to integrate the full Gemini OAuth login during the initial onboarding process, ensuring users authenticate upfront rather than on their first chat interaction.
• Rate Limit Handling: Added logic to parse HTTP 429 rate-limit responses, extracting retry_after durations from error messages to provide more informative feedback.
• Configuration and Backend Registration: Added a new GeminiOauthConfig struct with a default credentials path and registered gemini_oauth as a new LLM backend within the system.

Changelog

• src/config/llm.rs
  • Added GeminiOauth variant to the LlmBackend enum.
  • Updated FromStr and Display implementations for LlmBackend to include gemini_oauth.
  • Mapped GeminiOauth to use the GEMINI_MODEL environment variable.
  • Introduced GeminiOauthConfig struct for model and credentials path configuration.
  • Implemented logic to load GeminiOauthConfig based on environment variables or default paths.
• src/config/mod.rs
  • Exported the new GeminiOauthConfig struct.
• src/llm/gemini_oauth.rs
  • Added a new module gemini_oauth.rs to encapsulate the Gemini CLI OAuth implementation.
  • Implemented functions for deobfuscating OAuth client ID and secret.
  • Defined OAuthCredential and GoogleTokenRefreshResponse structs for token management.
  • Implemented PKCE parameter generation for secure OAuth flow.
  • Created CredentialManager to handle loading, saving, refreshing, and performing interactive OAuth logins.
  • Included logic for Cloud Code project discovery and provisioning via loadCodeAssist and onboardUser.
  • Implemented GeminiOauthProvider to handle LLM requests, including dual API routing for preview/legacy models.
  • Added SSE stream parsing for Cloud Code API responses.
  • Included functionality to parse rate-limit retry_after durations from Gemini error messages.
  • Provided conversion functions between internal chat message format and Gemini API request/response formats.
• src/llm/mod.rs
  • Declared gemini_oauth as a public module.
  • Exported GeminiOauthProvider for external use.
  • Added create_gemini_oauth_provider function to instantiate the Gemini OAuth LLM provider.
  • Integrated GeminiOauthBackend into the create_llm_provider function.
• src/setup/wizard.rs
  • Updated the display name for gemini_oauth in the setup wizard to 'Gemini API (OAuth)'.
  • Included gemini_oauth in the list of known LLM providers.
  • Added a new asynchronous setup_gemini_oauth function to guide users through the OAuth authentication process.
  • Modified the model selection step to present a curated list of Gemini 3.x preview models when gemini_oauth is selected.
  • Initialized gemini_oauth configuration to None in the default LlmConfig.

Activity

• The author, Mffff4, provided detailed testing steps, indicating the PR is ready for review and verification.
• The PR description outlines the new features and modifications, serving as a comprehensive guide for reviewers.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a significant feature by integrating Gemini via its official OAuth flow, covering the full OAuth 2.0 flow with PKCE, token refresh, and a clever fallback for browser redirection, alongside well-handled project discovery for Cloud Code. However, a high-severity security vulnerability was identified: OAuth tokens are stored in a file with default system permissions, which may allow other local users to read them. This should be addressed by enforcing restrictive file permissions (0o600) on the credentials file. Additionally, there are a few areas for improvement, including a configuration inconsistency for the credentials path, incomplete support for tool usage, and opportunities to improve maintainability by extracting repeated constants.

[gemini-code-assist]

The save_credential function writes OAuth tokens (including the refresh token) to a file without restricting its permissions. On Unix-like systems, this file will be created with default permissions (typically 0o644), making it readable by other users on the same system. This poses a significant security risk as a local attacker could steal these credentials to gain unauthorized access to the user's Google account.

Recommendation: Set restrictive file permissions (e.g., 0o600) on the credentials file. You can use std::os::unix::fs::PermissionsExt on Unix platforms to ensure only the owner can read or write the file.

        fs::write(&self.profiles_path, updated_content)?;
        #[cfg(unix)]
        {
            use std::os::unix::fs::PermissionsExt;
            let mut perms = fs::metadata(&self.profiles_path)?.permissions();
            perms.set_mode(0o600);
            fs::set_permissions(&self.profiles_path, perms)?;
        }

[gemini-code-assist]

There's an inconsistency in how the default Gemini credentials path is determined. This implementation derives it from ironclaw_base_dir, while GeminiOauthConfig::default_credentials_path (used by the setup wizard) correctly uses dirs::home_dir(). The official Gemini CLI stores credentials in ~/.gemini/, so basing the path on the user's home directory is more conventional and robust.

This implementation also introduces a potential panic with .expect() if ironclaw_base_dir() resolves to a root path. Using GeminiOauthConfig::default_credentials_path will resolve both the inconsistency and the potential for a panic.

                .unwrap_or_else(GeminiOauthConfig::default_credentials_path);

[gemini-code-assist]

The implementation of complete_with_tools appears to be a fallback that doesn't actually support tool usage. It converts the ToolCompletionRequest into a standard CompletionRequest, which discards the tools definitions, and then returns a response with an empty tool_calls vector. Given that one of the available models is gemini-3.1-pro-preview-customtools, it seems that tool support is an intended feature. This implementation should be updated to correctly handle tool calls with the Gemini API.

[gemini-code-assist]

The header value "gl-node/22.17.0" for X-Goog-Api-Client is hardcoded and repeated in multiple places (lines 430, 452, 633). To improve maintainability and avoid magic strings, consider defining this and other repeated header values as constants at the top of the file.

For example:

const GOOG_API_CLIENT: &str = "gl-node/22.17.0";
const CLOUD_CODE_USER_AGENT: &str = "google-cloud-sdk vscode_cloudshelleditor/0.1";

// ...

// Then use it like:
.header(reqwest::header::HeaderName::from_static("x-goog-api-client"), GOOG_API_CLIENT)

References

1. Avoid extracting strings to constants if they are used only once. Constants are beneficial when values need to be synchronized across multiple locations.

[zmanian]

The OAuth flow itself is well-implemented -- PKCE with S256, state parameter validation, loopback redirect, offline access. However, there are several issues that need to be addressed before merge.

Critical

1. .expect() panics in production code

• src/llm/mod.rs: config.gemini_oauth.clone().expect(...) -- every other provider factory returns LlmError. Use .ok_or_else()
• src/config/llm.rs: ironclaw_base_dir().parent().expect(...) -- use .ok_or()

2. Credential file written without restrictive permissions (Security)
save_credential() writes OAuth tokens (including refresh tokens) with default umask. On multi-user systems, this is world-readable. Set 0600 permissions on Unix. The file at ~/.gemini/oauth_creds.json contains long-lived Google account access.

3. Credential path inconsistency (Bug)
GeminiOauthConfig::default_credentials_path() uses dirs::home_dir() while LlmConfig::from_env() derives from ironclaw_base_dir().parent(). If IRONCLAW_BASE_DIR is set to a non-home location, the wizard authenticates and saves to one path but runtime loads from another.

Important

4. complete_with_tools silently drops all tools
The implementation converts ToolCompletionRequest to plain CompletionRequest, discarding tool definitions and returning empty tool_calls. This makes the provider effectively useless for the agent's core workflow (tools are fundamental). At minimum add a loud warn!() and document this limitation. Ideally implement Gemini function calling.

5. Zero tests
No tests in the 930-line module. Several pure functions are trivially testable: generate_pkce_params(), parse_callback_params(), parse_retry_after(), deobfuscate().

Minor

• Regex compiled on every 429 response in parse_retry_after -- use LazyLock
• Magic string "gl-node/22.17.0" repeated 4 times -- extract to constant
• let code = code; at line ~484 is a no-op rebinding
• Multiple .unwrap() in generate_pkce_params() on fixed-range indexing -- technically safe but violates project policy
• unwrap_or_default() on response.json().await silently swallows parse failures

[Mffff4]

The OAuth flow itself is well-implemented -- PKCE with S256, state parameter validation, loopback redirect, offline access. However, there are several issues that need to be addressed before merge.

Critical

1. .expect() panics in production code

• src/llm/mod.rs: config.gemini_oauth.clone().expect(...) -- every other provider factory returns LlmError. Use .ok_or_else()
• src/config/llm.rs: ironclaw_base_dir().parent().expect(...) -- use .ok_or()

2. Credential file written without restrictive permissions (Security) save_credential() writes OAuth tokens (including refresh tokens) with default umask. On multi-user systems, this is world-readable. Set 0600 permissions on Unix. The file at ~/.gemini/oauth_creds.json contains long-lived Google account access.

3. Credential path inconsistency (Bug) GeminiOauthConfig::default_credentials_path() uses dirs::home_dir() while LlmConfig::from_env() derives from ironclaw_base_dir().parent(). If IRONCLAW_BASE_DIR is set to a non-home location, the wizard authenticates and saves to one path but runtime loads from another.

Important

4. complete_with_tools silently drops all tools The implementation converts ToolCompletionRequest to plain CompletionRequest, discarding tool definitions and returning empty tool_calls. This makes the provider effectively useless for the agent's core workflow (tools are fundamental). At minimum add a loud warn!() and document this limitation. Ideally implement Gemini function calling.

5. Zero tests No tests in the 930-line module. Several pure functions are trivially testable: generate_pkce_params(), parse_callback_params(), parse_retry_after(), deobfuscate().

Minor

• Regex compiled on every 429 response in parse_retry_after -- use LazyLock
• Magic string "gl-node/22.17.0" repeated 4 times -- extract to constant
• let code = code; at line ~484 is a no-op rebinding
• Multiple .unwrap() in generate_pkce_params() on fixed-range indexing -- technically safe but violates project policy
• unwrap_or_default() on response.json().await silently swallows parse failures

@zmanian Thanks for the detailed review! I've incorporated all your suggestions and pushed the updated version—please take another look when you have a moment.

[ilblackdragon]

Code Review

Good feature addition — brings Gemini access with no API key via the official CLI OAuth flow. The PKCE+S256 implementation, Cloud Code project discovery, and SSE parsing are well done. Several issues to address before merge:

Critical

1. Missing cache_read_input_tokens / cache_creation_input_tokens fields — CompletionResponse and ToolCompletionResponse both require these fields (added recently to provider.rs). The code won't compile against current main. Add them with value 0.

2. OAuthCredential stores tokens as plain String with Debug derived — #[derive(Debug)] will print raw access_token and refresh_token to logs. Either manually implement Debug to redact (like OpenAiCodexSession in #744) or remove the derive. The struct also derives Clone which makes accidental token copies easy.

3. Hardcoded /tmp fallback in config (src/config/llm.rs:218):

   .unwrap_or_else(|| PathBuf::from("/tmp"))

   Project rules forbid hardcoded /tmp. Use dirs::home_dir().unwrap_or_else(|| PathBuf::from(".")) — which default_credentials_path() already does correctly a few lines above. Reuse that method.

High

4. Emojis in output — Project convention says "Only use emojis if the user explicitly requests it." The OAuth flow prints 🌐, 💡, ⚠️, 🎉. Replace with plain text markers.

5. unwrap_or_else(|_| Client::new()) appears twice (gemini_oauth.rs:413, gemini_oauth.rs:889) — Silent fallback on client builder failure hides TLS errors and drops configured timeouts. Propagate the error instead or at minimum log a warning.

6. Synchronous file I/O in async context — CredentialManager uses std::fs::read_to_string, std::fs::write, std::fs::create_dir_all directly. These block the tokio runtime. Use tokio::fs equivalents (the methods are already async).

7. credential.project_id consumed by if let Some(pid) (gemini_oauth.rs:917):

   if let Some(pid) = credential.project_id {

   This moves project_id out of credential. If credential is used later (or the code is refactored), this will break. Use if let Some(ref pid) = credential.project_id or .as_ref().

Medium

8. Model routing by string contains is fragile (gemini_oauth.rs:910):

   if self.config.model.contains("preview") || self.config.model.contains("gemini-3")

   This pattern appears twice (also in SSE parsing at line 965). A model named "my-preview-custom" would incorrectly route to Cloud Code. Extract to a helper method like fn uses_cloud_code_api(&self) -> bool and consider a more robust check.

9. Multiple system messages concatenation not handled — to_gemini_request only captures the last system message as systemInstruction. If multiple system messages exist (common in IronClaw — base prompt + skill prompts), earlier ones are silently dropped. Concatenate them like other providers do.

10. Assistant messages with tool_calls lose the function call parts (to_gemini_request) — When an assistant message has tool_calls, only msg.content is emitted as text. The functionCall parts should be included so Gemini sees the full conversation history. Without this, multi-turn tool use may break.

11. No retry-on-auth-failure pattern — Unlike the Codex provider (#744) which has TokenRefreshingProvider, this provider does a single credential fetch before each request. If the token expires mid-request, it gets a 401 with no automatic retry+refresh. Consider adding retry logic on auth failure.

12. tokio::select! with biased may starve stdin reader — The biased directive always tries TCP accept first. If the browser redirect arrives and the stdin task is mid-read, the stdin spawn_blocking task is leaked (never cancelled). This is a minor resource leak but worth noting.

13. Trailing whitespace and double blank lines — Several instances throughout (gemini_oauth.rs:345, 659, 723, 898). Run cargo fmt.

Low

14. context_length: Some(1_000_000) hardcoded — Not all Gemini models have 1M context. Consider making this model-dependent or returning None.

15. GOOG_API_CLIENT: &str = "gl-node/22.17.0" — This spoofs a Node.js client version. If Google checks this header, version 22.17.0 will eventually be outdated. Consider using a more generic value or the actual Rust client info.

16. No list_models() implementation — Returns default Err. Could return the static model list used in the wizard.

Positives

• PKCE with S256 properly implemented with state validation (CSRF protection)
• Cloud Code project discovery with LRO polling is thorough
• Rate-limit parsing (reset after Xh Ym Zs) is a nice detail that will help with backoff
• Manual URL paste fallback for environments where browser redirect doesn't work
• Good test coverage (16 tests covering PKCE, callback parsing, request/response conversion, rate-limit parsing)
• File permissions set to 0o600 on credential file
• Tool response merging logic (consecutive functionResponse parts into single user turn) correctly follows Gemini API requirements

[ilblackdragon]

Re-review (v2)

Good progress — most of the original issues are addressed. Here's what's fixed and what remains:

Fixed from v1

• cache_read_input_tokens / cache_creation_input_tokens — Added to both response structs
• OAuthCredential Debug redaction — Manual Debug impl with [REDACTED] for tokens + id_token. Test added (test_oauth_credential_debug_redaction)
• Hardcoded /tmp fallback — Config now uses GeminiOauthConfig::default_credentials_path()
• Emojis removed — Replaced with [Auth], Info:, Warning:, Success: prefixes
• Client::builder().unwrap_or_else — Both CredentialManager::new and GeminiOauthProvider::new now return Result and propagate errors
• Synchronous file I/O — load_credential and save_credential now use tokio::fs
• credential.project_id ownership — Fixed to if let Some(ref pid)
• Model routing extracted — uses_cloud_code_api() helper with version-based logic (major >= 2), plus test with my-preview-custom → false
• Multiple system messages — Concatenated with join("\n\n"), test added
• Assistant tool_calls in message conversion — functionCall parts now included in model turn
• 401 retry — send_request now has a retry loop on 401 with allow_retry flag
• list_models() — Returns static model list instead of empty error
• Regression test added — tests/gemini_oauth_regression.rs

Remaining issues

Medium:

1. 401 retry doesn't actually force-refresh the token — The retry loop at line 1133-1142 logs "Force-refreshing token" but just calls get_valid_credential() again, which checks the timestamp. If the token is "valid" by timestamp but revoked server-side, it'll return the same stale token and fail again. The comment at line 1137-1140 acknowledges this. You need to either (a) invalidate the cached token before retrying, or (b) add a force_refresh() method that bypasses the timestamp check.

2. Docs model list vs wizard model list mismatch — LLM_PROVIDERS.md lists gemini-3.x preview models (gemini-3.1-pro-preview, gemini-2.5-pro, etc.) but the wizard model selection (setup_model_selection) offers gemini-2.0 and 1.5 models. Neither list matches list_models() which returns yet a third set. Pick one canonical list.

3. thinkingConfig check narrowed too much — v1 had model.contains("thinking") || model.contains("gemini-3"). v2 only checks model.contains("thinking") (line 1318). This means gemini-3.x models that support thinking but don't have "thinking" in their name won't get includeThoughts. The docs say gemini-3 models support it. Either restore the gemini-3 check or update the docs.

4. biased removed from tokio::select! but stdin issue remains — The biased keyword was removed (good), but when the TCP callback wins the race, the read_stdin_line future reading from tokio::io::stdin() is dropped. This is fine (no resource leak with async stdin), but worth noting that on some platforms the terminal may be in a weird state after the read is cancelled.

Low:

5. GoogleTokenRefreshResponse still derives Debug — This struct contains access_token and refresh_token fields. While it's only used internally, a stray tracing::debug! could leak tokens. Consider manual Debug impl like OAuthCredential.

6. GOOG_API_CLIENT updated to "gl-rust/1.0.0 ironclaw/1.0.0" — Better than the Node spoofing, but the version 1.0.0 is hardcoded. Consider using env!("CARGO_PKG_VERSION") for the ironclaw part.

Overall looking good — the 401 retry force-refresh (item 1) and model list consistency (item 2) are the main actionable items before merge.

[zmanian]

Code Review (v3)

Good progress from v1 to v2. The OAuth flow is solid (PKCE+S256, state validation, loopback redirect, offline access). Function calling support, system message concatenation, Debug redaction, and file permissions are all addressed. The test suite (16 unit tests + regression integration test) covers the important pure functions.

ilblackdragon's v2 re-review identified 6 remaining items. After reading the latest diff, I agree with all of them and have additional observations.

Remaining from ilblackdragon's v2 review -- concur on all

1. 401 retry doesn't force-refresh (Medium) -- Lines 1133-1142 acknowledge this in a comment. get_valid_credential() checks the timestamp and returns the cached token if it hasn't expired by clock time, so a server-side revocation results in an infinite retry of the same stale token followed by giving up. Fix: either (a) add invalidate_cached_token() that deletes the in-memory/on-disk credential before retry, or (b) add force_refresh() that bypasses the is_token_valid check and goes straight to refresh_token(). This is the most important remaining issue -- without it, any server-side token revocation (password change, security event, Google session management) will permanently break the provider until the user manually deletes ~/.gemini/oauth_creds.json.

2. Model list mismatch (Medium) -- Three different lists:

• LLM_PROVIDERS.md: gemini-3.1-pro-preview, gemini-3-flash-preview, gemini-2.5-pro, gemini-2.5-flash, gemini-2.5-flash-lite
• Wizard setup_model_selection: gemini-2.0-flash, gemini-2.0-flash-thinking-exp-1219, gemini-1.5-pro, gemini-1.5-flash
• list_models(): gemini-2.0-flash-exp, gemini-2.0-flash, gemini-1.5-flash, gemini-1.5-flash-8b, gemini-1.5-pro, gemini-exp-1206, gemini-2.0-flash-thinking-exp-1219

Pick one canonical list and use it everywhere. The wizard list is the most concerning since it's the user-facing selection and doesn't include gemini-2.5 or 3.x models at all.

3. thinkingConfig narrowed too much (Medium) -- Line 1318 only checks model.contains("thinking"), so gemini-3.x models that support thinking but don't have "thinking" in their name won't get includeThoughts. The v1 code had gemini-3 as an additional check which was correct. Restore it.

4. GoogleTokenRefreshResponse derives Debug (Low) -- Contains access_token and refresh_token. A stray tracing::debug!("{:?}", resp) would leak tokens. Either impl Debug manually with redaction like OAuthCredential, or remove the derive.

5. GOOG_API_CLIENT version hardcoded (Low) -- "gl-rust/1.0.0 ironclaw/1.0.0" -- use env!("CARGO_PKG_VERSION") for the ironclaw part.

Additional observations

6. Decorator/wrapper delegation missing -- Per project rules, when adding a new LLM backend, you must verify all LlmProvider wrapper types delegate correctly. create_gemini_oauth_provider returns an Arc<dyn LlmProvider> that bypasses the provider chain (build_provider_chain in src/llm/mod.rs). This means Gemini OAuth won't get circuit breaker, failover, or recording wrapping. Is that intentional? The function is called directly from create_llm_provider before the chain-building logic. Other backends (nearai, bedrock) have the same pattern, so this may be by design, but it's worth confirming.

7. model_metadata() context length heuristic is fragile -- Lines 1448-1454 use string contains checks ("flash" -> 1M, "pro" -> 2M). A model named "gemini-3.1-pro-flash" (hypothetical) would match "flash" first. Consider checking in order of specificity, or use a map keyed on model family.

8. SSE parsing uses byte-index slicing -- Line 1047: let json_str = line[5..].trim(); -- This is technically safe here because "data:" is 5 ASCII bytes and lines() guarantees valid UTF-8, but per project rules ([.. byte-index slicing on strings), it's worth using line.strip_prefix("data:") instead for clarity and safety.

9. Wizard calls setup_gemini_oauth().await when user keeps existing provider -- Line 1998: if the user selects "Keep current provider?" for gemini_oauth, it re-runs the full OAuth flow. This is unlike bedrock which just prints "Keeping existing configuration." The comment says "Keeping the existing Bedrock config -- no need to re-run the full setup flow." The same logic should apply to gemini_oauth -- if credentials already exist and are valid, don't force re-auth.

Summary

The core OAuth implementation is well-done. The main blocker is the 401 force-refresh issue (#1) which can leave users stuck. Items #2 and #3 are correctness issues that should be fixed. The rest are quality improvements that can be addressed in a follow-up if needed.

[zmanian]

Re-review (v4)

All six items from the v3 review (zmanian + ilblackdragon) have been addressed:

• 401 retry force-refresh -- force_refresh() now bypasses is_token_valid() and goes straight to refresh_token(). The retry loop in send_request() calls it correctly. No deadlock risk since the mutex guard from get_valid_credential() is released before force_refresh() re-acquires it.
• Model list standardized -- Wizard, list_models(), and LLM_PROVIDERS.md all return the same 5 models: gemini-3.1-pro-preview, gemini-3-flash-preview, gemini-2.5-pro, gemini-2.5-flash, gemini-2.5-flash-lite.
• thinkingConfig gemini-3 check restored -- Line 1141: model.contains("thinking") || model.contains("gemini-3").
• GoogleTokenRefreshResponse Debug redaction -- Manual Debug impl at line 115 redacts access_token, refresh_token, and id_token.
• GOOG_API_CLIENT dynamic version -- Line 61 uses concat!("gl-rust/1.0.0 ironclaw/", env!("CARGO_PKG_VERSION")).
• Wizard skip re-auth -- Line 852-854: "Keep existing" for gemini_oauth returns early without re-running OAuth flow.

Remaining issues

Medium:

1. 5x .unwrap() on header .parse() in production code (lines 786, 791, 793, 794, 814) -- Project policy is zero .unwrap() in production. These are on static ASCII strings so they won't panic at runtime, but they violate the project's mechanical check (grep -rnE '\.unwrap\(' <files>). Replace with .expect("static header value") or propagate the error. The pre-commit-safety.sh script will flag these.

2. User-Agent header still spoofs Google Cloud SDK (line 789-790): "google-cloud-sdk vscode_cloudshelleditor/0.1" -- The X-Goog-Api-Client was correctly updated to identify as gl-rust/ironclaw, but the User-Agent header still pretends to be VS Code Cloud Shell Editor. If Google decides to enforce UA-based checks, this could silently break. Consider aligning it with the GOOG_API_CLIENT identity, or using the Gemini CLI's actual UA string if matching their flow is intentional.

3. model.contains("preview") still causes false-positive Cloud Code routing -- The test at line 1671 explicitly shows ("my-preview-custom", true), meaning any model with "preview" in its name routes to Cloud Code API. Since this provider only handles Gemini models, the blast radius is small, but the check could be tightened to model.contains("-preview") (with hyphen prefix) to reduce false matches without losing actual Gemini preview model coverage.

Low:

4. unwrap_or(0) in .parse() for version extraction (line 749) -- model_uses_cloud_code_api parses the major version from the model name and falls back to 0 on parse failure. This means a malformed model name like gemini-abc-flash silently routes to the legacy API. This is probably fine in practice, but a warn!() on parse failure would help debug misconfigured models.

5. model_metadata() context length ordering (lines 1271-1277) -- Still uses contains("pro") and contains("flash") which, as noted in v3, would give the wrong answer for a hypothetical gemini-3.1-pro-flash model. Low risk since no such model exists, but documenting the assumption with a comment would be helpful.

6. Regression test coverage is thin -- tests/gemini_oauth_regression.rs only tests model_uses_cloud_code_api() and ChatMessage helpers (6 lines of assertions). It doesn't exercise the fixes it claims to regression-test (Debug redaction, force_refresh, system message concatenation, etc.). The unit tests in the module itself are much more thorough. Consider either beefing up the integration test or removing the misleading name.

Positive changes since v3

• force_refresh() is a clean addition with proper error handling and login fallback
• GoogleTokenRefreshResponse Debug redaction closes the last token-leak vector
• Wizard early-return for existing gemini_oauth config is a nice UX improvement
• All three model lists being in sync eliminates a class of user confusion bugs

Verdict

The core OAuth flow, credential management, function calling, and API routing are solid. All critical and medium items from v3 are resolved. The remaining .unwrap() calls (item 1) should be cleaned up to pass the project's pre-commit checks, but are not security-sensitive. No blockers -- this is ready to merge after addressing the .unwrap() violations.

[zmanian]

Closing as part of backlog triage. The codebase has diverged significantly since this was opened. If the feature is still needed, please open a fresh PR against staging with updated code. Thank you for the contribution!