OpenClaw in WSL keeps disappearing and returning a few minutes later

Troubleshooting
, , , ,
1

Adapted community discussion: Translated, paraphrased, and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.

My OpenClaw instance in WSL becomes unavailable, then returns by itself several minutes later. The Linux kernel logs show repeated out-of-memory kills. WSL has roughly 4 GB of RAM and 1 GB of swap, and the Gateway has peaked above 3 GB.

2

The OOM records explain both symptoms: Linux kills the Gateway under memory pressure, and the managed service restarts it later. Capture a baseline in WSL with free -h, Gateway status, and a process list sorted by RSS. In Windows PowerShell, check total physical memory and any existing %UserProfile%\.wslconfig.

3

Can you give me the steps and say exactly whether each command runs in Windows or WSL?

4

With an 8 GB Windows host, start conservatively rather than assigning nearly all memory to WSL. In Windows PowerShell, merge this into %UserProfile%\.wslconfig:

[wsl2]
memory=4GB
swap=4GB

Preserve any other settings already in the file. wsl --shutdown stops every WSL distribution, so apply it only during a maintenance window. Reopen the distribution afterward.

5

I ran wsl --shutdown in PowerShell, reopened WSL, and checked from the Linux prompt. free -h now shows about 4 GB of RAM and 4 GB of swap. openclaw gateway status --deep reports the runtime running and the connectivity probe healthy.

6

That confirms the WSL change applied and the Gateway recovered. Keep monitoring free -h and the largest RSS processes during real workloads. Swap is a safety net, not a substitute for finding a process that grows without bound. The initial post-restart baseline is healthy, so increase limits further only if measured workloads require it.

7

The first measurements remain stable and swap is unused. Should I stress-test the agent now?

8

Use a gradual synthetic workload with no browser, files, messages, tasks, or subagents. Record memory before and after each round. Stop if available memory becomes very low, swap grows continuously, the Gateway RSS spikes toward the WSL limit, or the service disconnects. This confirms stability without manufacturing a dangerous burst on a small host.