openclaw node start/stop/restart on Windows host crashes WSL2 Gateway

Environment

Architecture:

Windows Host (RMAY-GRAM)
├── WSL2 (Ubuntu 26.04) — runs OpenClaw **Gateway**
│   ├── gateway.mode = "local"
│   ├── gateway.port = 18789
│   └── gateway.bind = "loopback"  (127.0.0.1 only)
│
├── [Windows] — runs OpenClaw **Node** (connected to WSL2 Gateway)
│   ├── Was started via `openclaw node run` (foreground)
│   └── Later switched to `openclaw node install` (Windows service)
│
└── Browser → http://127.0.0.1:18789 → WSL2 Gateway (via WSL2 auto proxy)

OpenClaw Versions:

• WSL2 Gateway: 2026.5.20
• Windows Node: 2026.5.20

Windows OS: Windows 11 (24H2) WSL2: Ubuntu 26.04

Gateway Port Binding Details

The Gateway in WSL2 is configured as:

{
  "gateway": {
    "mode": "local",
    "port": 18789,
    "bind": "loopback",
    "auth": {
      "mode": "token"
    },
    "controlUi": {
      "allowedOrigins": [
        "http://localhost:18789",
        "http://127.0.0.1:18789"
      ]
    }
  }
}

The Windows Node connects to the Gateway via ws://127.0.0.1:18789 — this works because WSL2 automatically sets up port forwarding for 127.0.0.1:18789 from the Windows side to the WSL2 instance. There is no manual netsh portproxy rule configured — WSL2 does this implicitly.

Steps to Reproduce

1. Set up: WSL2 runs OpenClaw Gateway on port 18789. Windows Node is connected to it (either via node run foreground or node install as a Windows service).
2. On Windows host, run:
   • openclaw node start (if stopped) or
   • openclaw node stop / openclaw node restart
3. Result: The WSL2 Gateway becomes unreachable. Web browser shows connection refused on http://127.0.0.1:18789. The Gateway process itself may still be running inside WSL2.

Expected Behavior

openclaw node start/stop/restart on the Windows node should only affect the node process itself. It should not interfere with the Gateway process running inside WSL2 or with the WSL2 auto port forwarding.

Actual Behavior

Running openclaw node start/stop/restart on Windows causes one or both of:

1. The WSL2 Gateway becomes unreachable from the Windows side (browser 127.0.0.1:18789 returns connection refused even though the Gateway process is still running inside WSL2).
2. The WSL2 auto port forwarding for 127.0.0.1:18789 gets disrupted. Access to the Gateway requires wsl --shutdown and a full restart.

Suspected Root Causes

We believe one of the following is happening:

1. Port conflict during node lifecycle: When openclaw node start/restart runs on the Windows side, the Windows OpenClaw process briefly tries to bind to port 18789 (perhaps because it tries to start its own mini-Gateway or validation check), which creates a conflict with the WSL2 auto forwarding of that port. This disrupts WSL2's internal proxy mechanism at the VM/kernel level, making Windows-side fixes ineffective.

2. WSL2 auto proxy disruption (kernel-level): The Windows openclaw node start process may inadvertently trigger WSL2's internal vSwitch or port proxy to re-evaluate, causing the existing forwarding for 127.0.0.1:18789 → WSL2 to be permanently disrupted at the WSL2 VM level — not just at the Windows netsh portproxy layer.

3. node run vs node start path differences: Previously node run (foreground) did not cause this issue, but node start/node restart (background service) does, suggesting the service startup sequence or lifecycle hooks differ in a way that triggers the problem.

Workaround

If this occurs, the only working recovery method is a full WSL2 restart:

wsl --shutdown

Then restart WSL2 (open a new WSL terminal) and re-launch the Gateway and Node processes.

netsh interface portproxy reset was attempted but did not restore connectivity — confirming the issue is deeper than Windows-side port proxy rules. The disruption likely occurs at the WSL2 VM/network stack level.

Additional Context

• The publicUrl configured in device-pair plugin is ws://127.0.0.1:18789.
• Since the node install command was recently used to register OpenClaw as a Windows service, this bug may also affect the service lifecycle management if the Windows service auto-starts/stops and disrupts the Gateway.
• Previously, running the Node with node run (foreground mode, which keeps the process interactive in a terminal window) did not cause this issue.