openclaw - 💡(How to fix) Fix High per-turn embedded-run startup/prep overhead on WSL2 even with OpenAI-only plugins [2 comments, 3 participants]

Summary

OpenClaw Gateway on WSL2 shows very high per-turn embedded-run startup/prep overhead before the model starts streaming, even with a fresh/minimal setup and only the bundled OpenAI provider enabled.

Tiny webchat messages regularly take ~35-45s before response streaming begins. During that time the gateway Node process pegs a CPU core and emits liveness warnings for event-loop delay/utilization.

Environment

• OpenClaw: 2026.4.29 (a448042)
• Node: v24.14.1
• OS: WSL2 Linux 6.6.87.2-microsoft-standard-WSL2, x86_64
• Host CPU visible in WSL: AMD Ryzen 5 3400G, 8 logical CPUs
• Memory visible in WSL: ~6.7 GiB total, ~5.5 GiB available during checks
• OpenClaw state/workspace: native WSL ext4 (/dev/sdd), not /mnt/c
• Gateway service: systemd user service
• Model path in use: openai-codex/gpt-5.5 / OpenAI Codex provider auth
• Webchat direct session

Startup optimization env vars are already active in the gateway service:

NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
OPENCLAW_NO_RESPAWN=1

Plugin minimization already tested

Started from a fresh-ish install where openclaw plugins list --enabled reported 48/48 enabled.

Then trimmed to:

1. openai + memory-core only
2. openai only, with memory disabled:

{
  plugins: {
    enabled: true,
    allow: ["openai"],
    slots: { memory: "none" },
    entries: {
      openai: { enabled: true },
      "memory-core": { enabled: false }
    }
  }
}

Current openclaw plugins list --enabled:

Plugins (1/1 enabled)
- @openclaw/openai-provider / id: openai / enabled

This reduced plugin surface but did not materially fix the per-turn delay.

Observed timings

Recent logs after restart with only openai enabled:

[agent/embedded] [trace:embedded-run] startup stages: totalMs=17792
stages=workspace:1ms@1ms,
runtime-plugins:2ms@3ms,
hooks:0ms@3ms,
model-resolution:9739ms@9742ms,
auth:4412ms@14154ms,
context-engine:1ms@14155ms,
attempt-dispatch:3637ms@17792ms

[agent/embedded] [trace:embedded-run] prep stages: totalMs=22546
stages=workspace-sandbox:2ms@2ms,
skills:1ms@3ms,
core-plugin-tools:9008ms@9011ms,
bootstrap-context:12ms@9023ms,
bundle-tools:1428ms@10451ms,
system-prompt:4991ms@15442ms,
session-resource-loader:1326ms@16768ms,
agent-session:4ms@16772ms,
stream-setup:5774ms@22546ms

Other observed ranges while investigating:

• With 48 plugins: prep often ~33-43s, core-plugin-tools ~17-20s
• After NODE_COMPILE_CACHE/OPENCLAW_NO_RESPAWN: prep improved to ~18-23s, but still slow
• With OpenAI only: still ~17-20s startup + ~20-23s prep

Gateway liveness warnings during turns:

[diagnostic] liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu ... eventLoopUtilization=0.999 cpuCoreRatio≈1

CPU observations:

• Gateway Node process commonly hits ~100% CPU during a tiny turn.
• If this were just network/model latency, I would expect CPU to be mostly idle; instead the local event loop appears saturated.

Expected behavior

With a minimal OpenAI-only plugin config and warm service, a tiny webchat message should not spend ~35-45s in local startup/prep before response streaming begins.

Actual behavior

Even with only the openai plugin enabled, per-turn local embedded runner overhead remains high:

• model-resolution: ~9-11s
• auth: ~4-5s
• core-plugin-tools: ~7-9s
• system-prompt: ~5-6s
• stream-setup: ~5-8s

This results in user-visible delayed responses and WSL top showing the gateway Node process pegging CPU.

Mitigations attempted

• Ran openclaw doctor
• Applied startup env vars:
  • NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
  • OPENCLAW_NO_RESPAWN=1
• Reinstalled/repaired systemd service via doctor fix path
• Restarted gateway several times
• Trimmed plugins from 48 enabled to OpenAI-only
• Disabled memory slot (plugins.slots.memory = "none")
• Confirmed OpenClaw is running from WSL ext4, not /mnt/c

Question / request

Is this expected for the OpenAI Codex provider path on WSL2, or is there a regression in the embedded runner/provider setup path?

Specific areas that look suspicious from the timings:

• model-resolution taking ~10s every turn
• core-plugin-tools taking ~9s even with only the OpenAI provider enabled
• stream-setup taking ~6s
• event-loop utilization pegged during these phases

Happy to provide additional logs or run a diagnostic command if useful.