openclaw - 💡(How to fix) Fix First message after restart stalls ~42s (bundled provider tool factories timeout sequentially) [1 participants]

Bug Description

After a clean gateway startup (~6s), the first user message stalls for ~42-55 seconds before the assistant begins responding. Subsequent messages are fast (~3s API round-trip). The stall occurs in the tool initialization phase where bundled provider plugins run tool factories sequentially, and unconfigured providers timeout one-by-one.

Root Cause

On the first message (embedded run), the gateway initializes tool factories for ALL bundled provider plugins — including providers that are not configured or explicitly disabled. Each unconfigured provider's tool factory makes a network call that times out at ~13 seconds. With 3+ unconfigured providers timing out sequentially, total stall is ~42s.

The root cause is per-embedded-run provider scanning instead of using cached results from startup resolution. The gateway already resolves providers at startup — tool factories should reuse that result rather than re-probing on first message.

Steps to Reproduce

1. Start gateway (completes in ~6s)
2. Send first message via any channel (Telegram, Control UI, API)
3. Observe ~42-55s delay before assistant response begins
4. Send a second message — response in ~3s

Expected Behavior

First message response time should be comparable to subsequent messages (~3-5s), since provider resolution already happened at startup.

Actual Behavior

~42s stall on first message. Tool initialization re-probes all providers including:

• Unconfigured bundled providers (e.g., xai) that timeout at ~13s each
• Providers that were already resolved during startup

Workaround

• Disabling individual bundled providers via config (e.g., xai: { enabled: false }) reduces the timeout count but doesn't eliminate it — other unconfigured providers still scan
• No complete workaround exists short of patching out the tool factory initialization

Environment

• OpenClaw v2026.4.26
• macOS Sequoia 15.x, Mac Mini M4 Pro
• Primary model: openai-codex/gpt-5.5 (Codex OAuth)
• Active-memory plugin disabled (not the cause — disabling it alone didn't fix the issue)

Related Issues

• #73805 — prewarmConfiguredPrimaryModel 30s timeout (same provider resolution code path, but at startup not first-message)
• #62364 — Slow startup with multiple providers

Suggestion

1. Cache provider/tool factory results from startup and reuse on first embedded run (don't re-probe)
2. Skip tool factory initialization for providers that are not configured or have 0 models in registry
3. If re-probing is necessary, run tool factories in parallel rather than sequentially
4. Add a short timeout (2-3s) for non-primary provider tool factories — a 13s timeout per provider is excessive for an optimization step