openclaw - 💡(How to fix) Fix Provider auth pre-warm blocks gateway event loop for minutes on Windows

Summary

On Windows 10 native, OpenClaw 2026.5.22 can block the gateway event loop for several minutes during startup provider auth pre-warm. While this happens, Telegram polling/reactions and local gateway RPC calls appear stalled or time out.

This is separate from the already-known Codex/OAuth compaction auth class of issues. I worked around the compaction side locally by changing agent model refs from openai/gpt-5.5 with Codex runtime to the explicit codex/gpt-5.5 provider. The startup pre-warm/event-loop starvation remains.

Environment

• OpenClaw: 2026.5.22 (a374c3a)
• OS: Windows 10 native, no WSL
• Node runtime used by OpenClaw: bundled node22 runtime
• Gateway: local loopback, port 18789
• Plugins enabled during reproduction: codex, memory-core, telegram
• Telegram mode: polling
• models.pricing.enabled=false
• commands.native=false
• commands.nativeSkills=false
• env.shellEnv.enabled=false, timeoutMs=1000
• cron.enabled=false

Observed behavior

After starting the gateway:

11:07:24 gateway ready
11:07:24 [telegram] starting provider
11:10:57 fetch timeout reached; elapsedMs=211102 timerDelayMs=201107 eventLoopDelayHint="timer delayed 201107ms, likely event-loop starvation" url=https://api.telegram.org/.../getMe
11:12:29 provider auth state pre-warmed in 303032ms eventLoopMax=209379.7ms

During this window:

• openclaw gateway health --json may timeout or return very slowly.
• Telegram reactions are not visible, so users think the bot is dead.
• Telegram API calls such as getMe hit timeout because timers are delayed by event-loop starvation.
• Once pre-warm completes, health and Telegram recover.

Example health shortly after recovery still showed degraded event loop:

{
  "ok": true,
  "eventLoop": {
    "degraded": true,
    "reasons": ["event_loop_delay"],
    "delayMaxMs": 8334.1,
    "utilization": 0.646
  },
  "plugins": { "loaded": ["codex", "memory-core", "telegram"] },
  "channels": { "telegram": { "running": true, "connected": true, "mode": "polling" } }
}

Expected behavior

Provider auth pre-warm should not block the Node event loop for minutes. Gateway health, WebSocket RPC, and Telegram polling should remain responsive during startup/provider auth checks.

Ideally:

• auth pre-warm should run incrementally/off-thread or with bounded concurrency;
• Telegram channel startup should not be blocked by unrelated provider auth pre-warm;
• there should be a documented config flag to disable heavy startup auth pre-warm on constrained Windows hosts;
• logs should identify which provider/profile/check is responsible for the long pre-warm.

Actual impact

This makes OpenClaw look non-functional after restart for 3-5 minutes. Telegram users send messages and see no reaction or reply, even though the gateway later recovers.

Related context

There are existing issues around OAuth/Codex auth and compaction requesting API keys. This report is specifically about startup event-loop starvation during provider auth pre-warm.

Search found related auth/compaction issues, but I did not find an exact report for provider auth state pre-warmed in ... eventLoopMax=... on Windows.