openclaw - 💡(How to fix) Fix Bug: resolveConfiguredProviderFallback replaces explicit provider/model with wrong provider when default provider is unconfigured [3 pull requests]

Bug Description

When the configured default provider (e.g., openai) does not exist as a key in models.providers (because the actual provider key is different, e.g., openai-codex), resolveConfiguredProviderFallback replaces BOTH the provider AND the model with the first available provider's first model. This produces incorrect model refs like ollama/kimi-k2.6:cloud when the user explicitly configured openai/gpt-5.5.

Reproduction

Config:

{
  "models": {
    "providers": {
      "ollama": { "models": [{ "id": "kimi-k2.6:cloud" }, { "id": "glm-5.1:cloud" }] },
      "openai-codex": { "api": "openai-codex-responses", "models": [{ "id": "openai-codex/gpt-5.5" }] },
      "sage-router": { "models": [{ "id": "frontier" }] }
    }
  }
}

Call:

resolveConfiguredProviderFallback({ cfg, defaultProvider: "openai", defaultModel: "gpt-5.5" })

Expected: null (caller preserves openai/gpt-5.5) Actual: { provider: "ollama", model: "kimi-k2.6:cloud" } (completely wrong provider and model)

Production Evidence

The gateway logs from our deployment show the downstream effect:

2026-05-31T14:57:25.881Z [agent/embedded] embedded run agent end: isError=true model=gpt-5.5 provider=ollama error=404 {"error": "model 'gpt-5.5' not found"}
2026-05-31T14:57:26.129Z [agent/embedded] embedded run failover decision: decision=surface_error reason=model_not_found from=ollama/gpt-5.5
2026-05-31T14:57:26.137Z [model-fallback/decision] model fallback decision: decision=candidate_failed requested=ollama/gpt-5.5 candidate=ollama/gpt-5.5 reason=model_not_found next=none

The model gpt-5.5 is sent to the ollama API endpoint (which only hosts ollama models), producing a 404. The correct behavior would route to openai-codex (which has gpt-5.5).

Key observations from the log:

• next=none: The fallback chain has no more candidates — the entire chain collapsed to the single wrong candidate ollama/gpt-5.5
• This error repeated 5+ times across an hour until the user manually switched models

Root Cause

In src/agents/configured-provider-fallback.ts, the function falls through to:

const availableProvider = Object.entries(configuredProviders).find(
  ([, providerCfg]) => providerCfg && Array.isArray(providerCfg.models) && ...
);

when:

1. The defaultProvider (e.g., "openai") is not a key in configuredProviders
2. defaultProviderConfig is undefined, making the early-exit condition undefined && (...) falsy

The function then returns the first provider's first model, regardless of whether it matches the user's intent.

Proposed Fix

1. Model-first lookup: When defaultModel is specified, search all configured providers for one that carries that exact model ID. If found, return that provider with the same model (provider switch only, model preserved).
2. Unknown provider → null: When the default provider is not configured at all, return null so the caller preserves the user's explicitly-specified provider/model pair.
3. Existing fallback preserved: Only fall back to the first available provider's first model when the default provider IS configured but doesn't have the model and no other provider has it either.

Impact

• Users with custom provider keys (e.g., openai-codex instead of openai) are currently broken when their fallback chain includes openai/gpt-5.5
• The resolveConfiguredModelRef caller at model-selection-shared.ts:864 correctly handles a null return by using { provider: defaultProvider, model: defaultModel }, so the fix is safe
• The codex-route-warnings.ts and status.summary.runtime.ts callers also handle null gracefully