openclaw - 💡(How to fix) Fix prewarmConfiguredPrimaryModel blocks 30s on startup (openai-codex provider name mismatch) [1 participants]

Bug Description

prewarmConfiguredPrimaryModel blocks gateway startup for exactly 30 seconds when the configured primary model uses a provider name that doesn't match the models registry.

Root Cause

The sync path in resolveModel (called with skipProviderRuntimeHooks: true) looks up the provider by the name in config (e.g., openai-codex). If the models registry lists models under a different provider key (e.g., codex — 3 models), the sync path finds 0 models and falls through to resolveModelAsync.

The async path runs prepareProviderDynamicModel hooks on all provider plugins. At least one hook makes a network call that times out at exactly 30 seconds, blocking startup.

Steps to Reproduce

1. Configure agents.defaults.model.primary to use a model like openai-codex/gpt-5.5
2. The internal models registry lists gpt-5.5 under the codex provider (3 models), not openai-codex (0 models)
3. Start/restart the gateway
4. Observe a 30-second gap between "starting gateway" and "ready" in logs
5. The gap is entirely inside prewarmConfiguredPrimaryModel

Expected Behavior

Provider name resolution should canonicalize openai-codex → codex (or vice versa) before the registry lookup, so the sync path succeeds and no async fallback is needed.

Actual Behavior

Sync resolution fails (0 models for openai-codex), async fallback runs all provider hooks including network calls, one times out at 30s, blocking startup.

Workaround

Patching the dist file (server.impl-*.js) to add return; as the first line of prewarmConfiguredPrimaryModel eliminates the 30s delay. This patch is lost on every npm install -g openclaw upgrade.

Environment

• OpenClaw v2026.4.26
• macOS Sequoia 15.x, Mac Mini M4 Pro
• Primary model: openai-codex/gpt-5.5 (Codex OAuth)

Related Issues

• #62364 — Slow startup with multiple providers (symptom overlap, different root cause)
• #32892 — models auth login --provider openai-codex fails with "No provider plugins found" (confirms the 0-models state)
• #19124 — Unknown provider 'openai-codex' (same provider name confusion)

Suggestion

Either:

1. Canonicalize provider aliases in resolveModel before the registry lookup, or
2. Skip the async fallback in prewarmConfiguredPrimaryModel (prewarm failure should not block startup — it's an optimization, not a requirement), or
3. Add a timeout cap to the prewarm function (e.g., 3s instead of 30s)

The 4.27 changelog mentions "reuse current plugin metadata snapshot for provider discovery" which may address this indirectly.