Summary

session-resource-loader consistently takes 5–7 seconds during every agent run's prep stage, blocking the event loop on the main thread. This happens regardless of session size, compaction state, or active agent — it's a constant synchronous I/O overhead.

Environment

• OpenClaw: 2026.5.12
• OS: Windows 11 Pro, i5-13600KF (6P+8E), Node 22
• P-core affinity applied, UV_THREADPOOL_SIZE=20
• qqbot channel disabled

Evidence

1. session-resource-loader is constant ~6s regardless of context size

All traces below are from gengar agent after /new (clean session, minimal context):

prep stages: system-prompt:4ms  session-resource-loader:5793ms  totalMs=9126
prep stages: system-prompt:3ms  session-resource-loader:6154ms  totalMs=9276
prep stages: system-prompt:4ms  session-resource-loader:6337ms  totalMs=9506

system-prompt takes 3-4ms (clean session), but session-resource-loader always takes 5.8-6.3s.

2. Before /new: combined with large context, it's catastrophic

Before clearing gengar's WeChat session (0 compactions, months of history):

prep stages: system-prompt:17700ms  session-resource-loader:5204ms  totalMs=32500
prep stages: system-prompt:7600ms   session-resource-loader:5608ms  totalMs=21300
prep stages: system-prompt:7900ms   session-resource-loader:5775ms  totalMs=21600

3. Event loop saturation (liveness warnings)

eventLoopDelayP99Ms=65000  eventLoopUtilization=0.97  cpuCoreRatio=0.94
eventLoopDelayP99Ms=62000  eventLoopUtilization=1.0   cpuCoreRatio=1.0
eventLoopDelayP99Ms=61500  eventLoopUtilization=0.84  cpuCoreRatio=0.84

7 liveness warnings in 21 minutes, all blocked on gengar's model_call queued behind session-resource-loader.

4. Impact: 14 gateway restarts in one day

When combined with any other work (model_call, cron startup, session switching), the 5-7s synchronous block creates a queue that cascades into complete event loop saturation and watchdog restarts.

5. Normal daily baseline (before any config changes)

Even without the crisis trigger, normal usage over 2 days showed:

• 3 gw=DOWN events (ws_timeout, correlated with CPU 71-84%)
• Memory growing 200-250MB per lifecycle
• tasks% declining from 90% → 72%

Root cause

session-resource-loader reads and parses session/resource files synchronously on the main thread. This blocks the event loop for every agent run, regardless of session size or agent type.

Suggested fix

Replace synchronous file reads in session-resource-loader with async streaming or parallelized Promise.all to keep the event loop responsive during agent startup.