openclaw - 💡(How to fix) Fix google-gemini-cli OAuth profile is ignored for canonical google/* models when GEMINI_API_KEY is present

Summary

On OpenClaw 2026.5.6 / repo d4e04f33a6, Gemini CLI OAuth can be successfully added with:

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

but canonical google/* models still resolve to source=env: GEMINI_API_KEY in openclaw models status, even when:

• agents.defaults.agentRuntime.id is google-gemini-cli
• a valid google-gemini-cli OAuth profile exists
• docs say canonical google/* refs should reuse Gemini CLI OAuth via the runtime split

This makes the effective auth/routing for Google models confusing at best, and likely wrong.

Why this looks like a bug

The docs/source imply this setup should work:

• canonical model refs: google/gemini-*
• runtime: agents.defaults.agentRuntime.id: "google-gemini-cli"
• auth: openclaw models auth login --provider google-gemini-cli

Relevant local docs/source references from the same build:

• docs/providers/google.md
  • says the runtime option is google-gemini-cli
  • says model refs stay canonical as google/*
  • says google-gemini-cli/* refs are legacy compatibility aliases
• src/commands/doctor-legacy-config.migrations.test.ts
  • explicitly migrates google-gemini-cli/gemini-3.1-pro-preview -> google/gemini-3.1-pro-preview
  • sets agentRuntime.id to google-gemini-cli
• src/agents/model-runtime-aliases.ts
  • maps legacy provider google-gemini-cli -> canonical provider google
  • runtime preserved as google-gemini-cli
• src/plugins/config-state.ts
  • normalizes plugin alias google-gemini-cli -> google

But after logging into Gemini CLI OAuth, openclaw models status still shows the Google provider using the env key:

- google effective=env:AIza... | source=env: GEMINI_API_KEY
OAuth/token status
- none

At the same time, openclaw models auth list --provider google-gemini-cli shows a real OAuth profile:

Provider: google-gemini-cli
Profiles:
- google-gemini-cli:[email protected] (...) [google-gemini-cli/oauth; expires ...]

That suggests one of two bugs:

1. google/* execution is actually still using the env API key instead of the Gemini CLI OAuth profile, despite the runtime/auth setup.
2. execution uses Gemini CLI OAuth correctly, but models status / auth reporting is wrong and ignores the runtime split.

Either way the current UX is misleading and appears inconsistent with docs and migration behavior.

Reproduction

Environment:

• OpenClaw repo: d4e04f33a6
• CLI banner showed: OpenClaw 2026.5.6
• systemd gateway service includes GEMINI_API_KEY in its managed environment

Initial state:

• agents.defaults.agentRuntime.id = google-gemini-cli
• canonical model refs configured under agents.defaults.models:
  • google/gemini-3.1-pro-preview
  • google/gemini-3-flash-preview
  • google/gemini-3.1-flash-lite-preview
• no active OAuth profile shown in models status
• openclaw models status reports:

- google effective=env:... | source=env: GEMINI_API_KEY
OAuth/token status
- none

Then run:

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

Observed success:

Auth profile: google-gemini-cli:[email protected] (google-gemini-cli/oauth)
Default model available: google/gemini-3.1-pro-preview (use --set-default to apply)

Verify profile exists:

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

Observed:

Provider: google-gemini-cli
Profiles:
- google-gemini-cli:[email protected] (...) [google-gemini-cli/oauth; expires ...]

Then run:

openclaw models status

Observed after successful OAuth login:

- google effective=env:... | source=env: GEMINI_API_KEY
OAuth/token status
- none

Expected behavior

One of these should happen clearly and consistently:

Expected option A

When:

• model ref is google/*
• runtime is google-gemini-cli
• a valid google-gemini-cli auth profile exists

then models status should show that the effective Google auth is Gemini CLI OAuth (or otherwise clearly indicate runtime-split resolution instead of reporting the env API key).

Expected option B

If GEMINI_API_KEY is intentionally supposed to override Gemini CLI OAuth for canonical google/* refs, then:

• docs should say that explicitly
• models auth login --provider google-gemini-cli should warn that GEMINI_API_KEY will still win for canonical google/* models
• models status should explain the precedence clearly

Additional notes

The service environment clearly injects GEMINI_API_KEY:

Environment=OPENCLAW_SERVICE_MANAGED_ENV_KEYS=...GEMINI_API_KEY...

So this is very easy to hit on real hosts where both API-key Google access and Gemini CLI OAuth are configured.

Impact

Users can believe they have successfully switched Google models to Gemini CLI OAuth, while OpenClaw may still be using the API key path or at least reporting that it is. That makes auth debugging and cost/control assumptions unreliable.

If useful, I can add more local evidence, but this already looks reproducible from the public docs and the commands above.