Summary

On gateway soft restart (SIGUSR1), OpenClaw does not kill browser processes it previously launched. When the gateway restarts and spawns a new Chrome instance, the old one is still running on the same port. This causes a port conflict where the CDP WebSocket accepts connections but silently drops all commands, making Playwright hang indefinitely on any page operation.

Steps to Reproduce

1. Start the gateway — it launches a Chrome process on port 18800.
2. Call gateway restart (SIGUSR1 / soft restart).
3. The gateway launches a new Chrome process on port 18800, but the old one is still running.
4. You now have two Chrome instances competing for the same port.
5. Any browser tool call that requires Playwright page interaction (e.g., snapshot, navigate, act) hangs for 20 seconds and returns: Can't reach the OpenClaw browser control service (timed out after 20000ms).

Observed Behavior

• browser start and browser status report running: true, cdpReady: true, cdpHttp: true — because the HTTP endpoint still responds.
• browser snapshot, browser navigate, and browser act all time out.
• Chrome's CDP WebSocket connects but never responds to commands (Playwright hangs at the command step).
• Running ps aux | grep chrome reveals two Chrome processes with --remote-debugging-port=18800, using different --user-data-dir paths.

Root Cause

The gateway's soft restart (SIGUSR1) does not track or clean up child browser processes it previously launched. Each restart spawns a new Chrome without killing the old one.

Fix / Suggestion

The gateway should:

1. Track PIDs of browser processes it launches.
2. On any restart (soft or full), kill those tracked processes before spawning new ones.

Workaround

Manually kill all OpenClaw-managed Chrome processes, then call browser start again.

Environment

• OpenClaw version: 2026.3.1
• macOS 25.3.0 (arm64)
• Chrome 145.0.7632.117
• playwright-core 1.58.2