openclaw - 💡(How to fix) Fix [Bug]: (regression) with complete, stock extensions directory per-turn delay back up to 8+ seconds

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After gateway restart, first turn delay from pressing Enter to LLM activity is about 12 sec. Per-turn it's 8-9 sec. That's with the stock extensions directory containing all plugins.

Steps to reproduce

1. Start OpenClaw 2026.5.22 in stock form
2. Run a short chat turn.
3. Wait (I see ~12 sec to LLM activity)
4. Run another short turn
5. Wait (8-9 sec to LLM activity)

Expected behavior

Before 2026.5.22, with the extensions directory there, waits were about 5 sec after gateway restart, and ~2 sec on subsequent turns. That's reasonable and acceptable behavior (for me).

Actual behavior

See summary. Approximately same also happens through 2026.5.24-beta.2. My workaround is to "pare" the extensions directory by deleting all plugin directories except those actively being used, or are required by other core functions. For me that's around 8-10 directories remaining. Then the response time immediately (on the next turn) jumps back to the lower levels seen in earlier versions.

OpenClaw version

2026.5.22

Operating system

Ubuntu 24.04

Install method

npm global

Model

Qwen3.6-35B-A3B

Provider / routing chain

openclaw -> openai-completions API -> llama.cpp

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: unknown but certainly includes control/webchat UI Severity: annoying, enough that if there was no workaround I wouldn't be using OpenClaw Frequency: always, reliably reproducible Consequence: subjective response time extreme slowness

Additional information

I don't recall the details but there was an earlier similar behavior where I found and it was also detailed in a fix that the extensions/plugins directory for was being walked and repeatedly stat()-ed not only at gateway startup but for each turn, around 360K calls IIRC. It's acting identically again, so I speculate the same cause may have crept back in, or maybe a cache invalidation bug - I don't know. The initial slower startup is tolerable if it has to be that way, but not the per-turn.