Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Bug type

Startup / performance bug

Summary

On Windows 11 with Docker Desktop + WSL, openclaw-gateway cold start takes about 3+ minutes before reaching http server listening.

This does not look like “full npm reinstall every startup”. In my case, bundled runtime deps install finished in about 27 seconds, but the gateway then spent much longer in the bundled runtime mirror path while holding .openclaw-runtime-mirror.lock.

During that time:

• container healthcheck stayed in starting and later became unhealthy
• /healthz checks exceeded the current 5s timeout
• if I manually stopped the container during this phase, a stale .openclaw-runtime-mirror.lock remained in the persisted config volume

Also, on Windows/WSL the persisted plugin-runtime-deps tree could remain undeletable even after containers were removed until I ran:

wsl --shutdown

Steps to reproduce

1. Run OpenClaw via Docker Compose on Windows 11 with Docker Desktop + WSL
2. Mount host config dir into /home/node/.openclaw
3. Delete the existing plugin-runtime-deps/openclaw-2026.4.26-* stage root so startup is cold
4. Start the gateway
5. Observe:
   • bundled runtime deps stage quickly
   • startup then spends a long time before http server listening
   • healthcheck may become unhealthy
6. Stop the container during the slow-start phase and inspect the persisted stage root for stale .openclaw-runtime-mirror.lock

Expected behavior

• cold startup should not block for 3+ minutes in bundled runtime prep/mirror
• healthcheck should not mark the container unhealthy while startup is still legitimately progressing
• interrupted startup should not leave stale runtime mirror locks in persisted state

Actual behavior

Observed startup timeline:

2026-04-28T06:04:48Z [gateway] starting...
2026-04-28T06:04:49Z [plugins] staging bundled runtime deps before gateway startup
2026-04-28T06:05:16Z [plugins] installed bundled runtime deps before gateway startup in 27160ms
2026-04-28T06:08:10Z [gateway] starting HTTP server...
2026-04-28T06:08:11Z [gateway] http server listening (...; 203.3s)

So total startup was about 203 seconds, but actual bundled deps install was only about 27 seconds.

During the long middle phase:

• node_modules already existed
• .openclaw-runtime-deps.lock was already gone
• .openclaw-runtime-mirror.lock still existed
• the staged runtime dist directory kept changing while the mirror lock was held

OpenClaw version

2026.4.26

Operating system

Windows 11

Install method

dcoker

Model

none

Provider / routing chain

none

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: users running OpenClaw via Docker Desktop on Windows with WSL-backed volumes, especially when ~/.openclaw/plugin-runtime-deps is persisted across restarts Severity: moderate to high for self-hosted users, because startup regularly takes minutes and failed/interrupted starts leave behind state that is hard to clean up Frequency: reproducible on cold starts in this environment; stale lock/undeletable stage-root behavior appears whenever startup is interrupted during the bundled runtime mirror phase Consequence:

• gateway readiness is delayed by several minutes
• Docker healthcheck may mark the container unhealthy even though startup is still progressing
• interrupted starts can leave stale .openclaw-runtime-mirror.lock
• cleanup/retry can require wsl --shutdown before the persisted stage root becomes deletable again

Additional information

Environment

• OpenClaw: 2026.4.26
• Host: Windows 11
• Docker Desktop + WSL
• Config mounted from host to /home/node/.openclaw
• Observed on: 2026-04-28

Healthcheck symptom

After the server was already listening, Docker health still reported:

Health check exceeded timeout (5s)

Example state:

Status=running Health=unhealthy FailingStreak=13

Persisted stage root involved

C:\Users\Ryuu\.openclaw\plugin-runtime-deps\openclaw-2026.4.26-f53b52ad6d21

If startup was interrupted, stale mirror lock state could remain there.

A Windows/WSL-specific detail made retries more painful:

after interrupting startup, the persisted staged runtime root under:

C:\Users\Ryuu\.openclaw\plugin-runtime-deps\openclaw-2026.4.26-f53b52ad6d21

could remain undeletable even after all Docker containers were removed and Docker Desktop was closed.

I was only able to delete the directory after running:

wsl --shutdown

So this looks like two layers of trouble interacting:

1. OpenClaw cold startup spends a long time in bundled runtime mirror work
2. if startup is interrupted, Windows/WSL can keep handles on the persisted staged runtime tree, which makes cleanup and retry harder

This does not seem to be the root cause of the slow startup itself, but it makes failed or interrupted startup attempts much more difficult to recover from.

Notes

This feels related to the broader bundled plugin/runtime startup cost issues already reported elsewhere, but this repro is specifically:

• Docker
• Windows + WSL
• persisted plugin-runtime-deps
• long hold of .openclaw-runtime-mirror.lock
• healthcheck timeout after gateway eventually listens