hermes - 💡(How to fix) Fix [Bug]: OAuth provider 'google-gemini-cli' silently unusable as fallback chain entry

Bug Description

When google-gemini-cli is configured as a fallback_providers entry in a profile's config.yaml, resolve_provider_client() in agent/auxiliary_client.py silently returns (None, None) because the provider name is not in the OAuth-direct-supported whitelist (only nous, openai-codex, and xai-oauth resolve via the OAuth path).

The fallback chain skips the entry with only a WARNING-level log line — the user-visible result is that the entire fallback hop is invisible at runtime. With a valid google-gemini-cli OAuth credential present in the auth pool and a configured fallback chain referencing it, the chain entry never serves a single request.

This affects any profile that relies on Gemini OAuth as a fallback for resilience when the primary provider is throttled.

Steps to Reproduce

1. Add a Gemini OAuth credential:

   hermes auth add google-gemini-cli --type oauth

2. Configure a fallback chain in a profile's config.yaml:

   model:
     provider: anthropic
     default: claude-sonnet-4-6
   fallback_providers:
     - provider: openai-codex
       model: gpt-5.4-mini
     - provider: google-gemini-cli
       model: gemini-3.1-pro-preview

3. Force the primary (and the first fallback) to fail — e.g., rate-limit both Anthropic and Codex simultaneously.
4. Observe that the google-gemini-cli fallback entry is silently skipped.

Expected Behavior

With a valid google-gemini-cli OAuth credential in the auth pool, fallback to that provider should succeed via the existing Code Assist code path (Hermes already ships agent/gemini_cloudcode_adapter.py, agent/google_code_assist.py, and agent/google_oauth.py — the adapters exist; only the resolver wiring is missing).

Actual Behavior

Gateway/agent logs show, for every attempt to use the fallback entry:

WARNING agent.auxiliary_client: resolve_provider_client: OAuth provider google-gemini-cli not directly supported, try 'auto'
WARNING root: Fallback to google-gemini-cli failed: provider not configured

hermes fallback list continues to display the chain as if all entries are functional. There is no error surface telling the operator that the entry is dead.

Source Reference

agent/auxiliary_client.py:3663-3674 on main (commit 7f7245b):

elif pconfig.auth_type in {"oauth_device_code", "oauth_external"}:
    # OAuth providers — route through their specific try functions
    if provider == "nous":
        return resolve_provider_client("nous", model, async_mode)
    if provider == "openai-codex":
        return resolve_provider_client("openai-codex", model, async_mode)
    if provider == "xai-oauth":
        return resolve_provider_client("xai-oauth", model, async_mode)
    # Other OAuth providers not directly supported
    logger.warning("resolve_provider_client: OAuth provider %s not "
                   "directly supported, try 'auto'", provider)
    return None, None

Suggested Fix

Add a fourth branch to the OAuth-direct whitelist that routes google-gemini-cli through the existing Code Assist adapter:

if provider == "google-gemini-cli":
    return resolve_provider_client("google-gemini-cli", model, async_mode)

(assuming resolve_provider_client has a corresponding provider == "google-gemini-cli" branch elsewhere, or wiring through gemini_cloudcode_adapter).

Alternatively, raise a clear configuration-time error when an unrecognized OAuth provider name appears in fallback_providers, so the silent-skip behavior becomes a loud failure during validation instead of being discovered only when the chain is actually reached at runtime.

Workaround

Use provider: auto for the Gemini fallback entry — but this loses per-entry control over Gemini model selection inside the chain and routes through Hermes' generic auto-resolver instead of the explicit Code Assist adapter.

Affected Component

Agent Core (conversation loop, context compression, memory) — resolve_provider_client is core to provider selection.

Environment

• Hermes Agent: v0.14.0 (build 2026.5.16), HEAD 7f7245b (latest at time of filing)
• Python: 3.11.15
• OS: macOS 15 (Darwin 25.5.0)

Debug Report

The bug is reproducible from a minimal config and the WARNING line above; the full hermes debug share bundle would expose unrelated profile telemetry (cron schedules, skill outcomes, etc.) without adding diagnostic value. Happy to provide redacted log excerpts on request.