Skip to content

Bug: google-gemini-cli-auth OAuth fails on Windows (client_secret missing + loadCodeAssist 400) #30403

@HIHOOOOO

Description

@HIHOOOOO

Environment

  • OpenClaw version: 2026.2.26
  • OS: Windows 11
  • Node version: v22.x (npm global install)

Background

Since google-antigravity-auth was removed in 2026.2.23, google-gemini-cli-auth is the only OAuth path for Google models on Windows. However, the plugin fails with two sequential errors.


Error 1 — Token exchange fails: client_secret is missing

Error: Token exchange failed: {
  "error": "invalid_request",
  "error_description": "client_secret is missing."
}
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76

Root cause

extractGeminiCliCredentials() in oauth.ts resolves the Gemini CLI directory by finding the gemini binary in PATH and traversing upward to locate @google/gemini-cli-core/dist/src/code_assist/oauth2.js.

This path resolution fails silently on Windows because the npm global bin structure differs from Mac/Linux. As a result, resolveOAuthClientConfig() falls through without a clientSecret, and Google's token endpoint rejects the request.

The actual file exists at:

%APPDATA%\npm\node_modules\@google\gemini-cli\node_modules\@google\gemini-cli-core\dist\src\code_assist\oauth2.js

but extractGeminiCliCredentials() does not find it.

Workaround

Manually set the env vars that resolveOAuthClientConfig() checks first (per oauth.ts lines 7–10):

OPENCLAW_GEMINI_OAUTH_CLIENT_ID=<client_id from oauth2.js>
OPENCLAW_GEMINI_OAUTH_CLIENT_SECRET=<client_secret from oauth2.js>

Error 2 — After fixing Error 1: loadCodeAssist 400 Bad Request

Error: loadCodeAssist failed: 400 Bad Request

Root cause

discoverProject() calls cloudcode-pa.googleapis.com/v1internal:loadCodeAssist to auto-detect the Google Cloud project. This returns 400 for some account types.

The function has a fallback that works correctly when GOOGLE_CLOUD_PROJECT is set:

if (!hasLoadCodeAssistData && loadError) {
  if (envProject) {
    return envProject; // ← this works
  }
  throw loadError;
}

However, this env var is completely undocumented, so users have no way to know it's an option.

Workaround

GOOGLE_CLOUD_PROJECT=<your-project-id>

The project ID can be found in auth-profiles.json under profileId if a previous google-antigravity session existed.


Suggested Fixes

  1. Fix Windows path resolution in extractGeminiCliCredentials() — add the npm global path pattern for Windows (%APPDATA%\npm\node_modules\@google\gemini-cli\...)

  2. Document the env var workaround (OPENCLAW_GEMINI_OAUTH_CLIENT_ID, OPENCLAW_GEMINI_OAUTH_CLIENT_SECRET, GOOGLE_CLOUD_PROJECT) in the plugin README

  3. Handle loadCodeAssist 400 more gracefully — if the endpoint fails and GOOGLE_CLOUD_PROJECT is set, log a hint to the user instead of silently failing


Related

Metadata

Metadata

Assignees

Labels

No labels
No labels

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