openclaw - 💡(How to fix) Fix Google Gemini CLI OAuth hangs indefinitely when browser launch silently fails [1 comments, 1 participants]

Environment

• OpenClaw: 2026.4.22 (00bd2cf)
• OS: Windows 11, PowerShell 5.1 (non-elevated user session)
• Node.js: v24.6.0
• npm: 11.11.1
• Install: global (npm install -g openclaw)
• Default browser: set and functional (Start-Process "https://..." launches it reliably)
• BROWSER env var: unset
• Port 8085: free

Summary

Running openclaw models auth login --provider google-gemini-cli hangs indefinitely on my machine because ctx.openUrl(authUrl) in dist/extensions/google/oauth.js silently fails to launch the browser (no tab opens, no exception thrown). The existing fallback code only runs on catch, so when launch fails without throwing, the authorization URL is never shown to the user and the flow deadlocks on the local callback server until timeout.

Reproduction

1. Windows, default browser set, no BROWSER env var.
2. Run from a non-admin PowerShell prompt:

   openclaw models auth login --provider google-gemini-cli

3. Confirm "Yes" when asked.
4. Observe: Waiting for OAuth callback on http://localhost:8085/oauth2callback, no browser tab opens, no URL printed, eventual timeout with Error: OAuth callback timeout.

Confirmed that the underlying callback server is healthy — navigating manually to http://localhost:8085/oauth2callback returns OpenClaw's own "Missing OAuth code or state" page from the expected handler, confirming the server is bound and listening. So the bug is strictly on the browser-launch side.

Root cause

In dist/extensions/google/oauth.js, the non-manual flow has this fallback structure:

try {
    await ctx.openUrl(authUrl);
} catch {
    ctx.log(`\nOpen this URL in your browser:\n\n${authUrl}\n`);
}

The intent is clear: if openUrl fails, print the URL so the user can open it themselves. But ctx.openUrl (presumably wrapping open from npm, or similar) returns a resolved promise even when the underlying spawn doesn't actually launch a browser — a known limitation of that pattern on Windows. The result: no exception, catch never fires, URL never shown, user stuck.

Proposed fix

Print the URL unconditionally before attempting browser launch, so a silent launch failure is never fatal:

ctx.log(`\nOpen this URL in your browser:\n\n${authUrl}\n`);
try {
    await ctx.openUrl(authUrl);
} catch {
    // URL already printed; nothing else to do.
}

If the browser launch works, the user ignores the printed URL (no harm). If it silently fails, the URL is right there. This matches the defensive pattern many CLIs use (gcloud, gh, etc.) and eliminates a whole class of "OAuth just hangs on Windows" bug reports.

Verification

Applied this patch locally. openclaw models auth login --provider google-gemini-cli now prints the auth URL immediately, I paste it into a browser, complete the flow, and OpenClaw's callback server receives the code as expected. Output ends with Gemini CLI OAuth complete. openclaw doctor confirms the profile transitions from expired (0m) + OAuth refresh errors to expiring (40m) with no refresh errors.

Additional notes

• The identical pattern likely exists in other OAuth providers under dist/extensions/*/oauth.js; a grep for ctx.openUrl wrapped in try { ... } catch { ctx.log(...) } would catch them.
• A related improvement: consider always printing the URL at debug or higher log level even when browser launch succeeds, so users on misbehaving setups have a record they can copy.
• The underlying silent failure of ctx.openUrl on some Windows configurations is a separate, harder bug (probably in the npm open package or how it's invoked with Node v24). The fix above sidesteps it entirely without needing to diagnose it.