openclaw - 💡(How to fix) Fix Bug: google-gemini-cli runtime ignores selected OpenClaw OAuth profile [1 pull requests]

Summary

OpenClaw Gemini CLI OAuth profiles can authenticate and refresh successfully, but the google-gemini-cli CLI runtime launches the external gemini binary with ambient Gemini CLI state instead of the selected OpenClaw auth profile. This lets openclaw models auth list / status show expired or selected OpenClaw profiles while execution is governed by ~/.gemini/oauth_creds.json.

Evidence

• The Gemini OAuth flow requests offline access and stores refresh tokens in OpenClaw auth profiles.
• Direct refresh of a stored OpenClaw Gemini refresh token succeeds and returns a fresh one-hour access token.
• Running gemini directly refreshes ~/.gemini/oauth_creds.json, proving the external CLI cache works independently.
• CLI execution currently blocks auth-profile forwarding for CLI providers before calling runCliAgent, so authProfileId can be undefined for the Gemini CLI runtime.
• The Gemini CLI backend has no prepareExecution bridge to materialize a selected OpenClaw OAuth profile into a Gemini-compatible credential home.

Expected

When a run selects a google-gemini-cli:* OAuth profile, the google-gemini-cli runtime should either consume that profile directly or prepare an isolated Gemini CLI credential home for the subprocess. Status should not imply that OpenClaw profile expiry controls execution if the subprocess is actually using ambient ~/.gemini credentials.

Impact

Users can successfully authenticate Gemini accounts in OpenClaw but still see tokens expire and runs fail or use a different account, because the selected OpenClaw profile and the external CLI credential cache are separate auth sources.

Proposed fix

Add a Gemini CLI backend prepareExecution bridge that refreshes the selected OpenClaw OAuth profile and writes a Gemini-compatible oauth_creds.json into an isolated per-run/per-profile home before launching gemini, while preserving cleanup and avoiding token logs.