Summary
The CLI gateway status command incorrectly reports a port conflict ("Port already in use") when the gateway is successfully running as a systemd user service. The CLI seems to confuse its own systemd-spawned process with an external conflicting process. Additionally, the CLI outputs debugging suggestions with invalid flags (e.g., --probe, --error, -n) that return unknown option errors.
Steps to reproduce
Install OpenClaw via package manager (npm) on a Linux VPS.
Configure and run the OpenClaw gateway as a systemd user service (~/.config/systemd/user/openclaw-gateway.service) binding to 127.0.0.1:18789.
During an update or when manually checking status, run the suggested command: openclaw gateway status --probe --deep. (This fails with unknown option '--probe').
Run the fallback command: openclaw gateway status --no-probe --deep.
Observe the status output claiming the port is already in use by another PID.
Run curl -I http://127.0.0.1:18789/ and observe that the gateway is actually perfectly healthy and returning HTTP/1.1 200 OK.
Expected behavior
The status command should correctly identify that the process bound to the port is its own valid systemd process, and report the gateway as healthy.
The CLI error messages and troubleshooting suggestions should only recommend valid flags that are actually implemented in the current version.
Actual behavior
The CLI reports that the port is blocked by a "rogue" process (which is actually just the running gateway) and incorrectly states that the gateway did not become healthy. Furthermore, attempting to use the CLI's suggested debugging flags results in errors:
openclaw gateway status --probe --deep -> error: unknown option '--probe'
openclaw logs --error -> error: unknown option '--error'
openclaw logs -n 50 -> error: unknown option '-n'
OpenClaw version
2026.2.22-2 (45febec)
Operating system
Ubuntu
Install method
npm
Logs, screenshots, and evidence
$ openclaw gateway status --no-probe --deep
🦞 OpenClaw 2026.2.22-2 (45febec) — Meta wishes they shipped this fast.
...
Runtime: running (pid 1037, state active, sub running, last exit 0, reason 0)
Port 18789 is already in use.
- pid 1127 root: openclaw-gateway (127.0.0.1:18789)
- Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
$ curl -I http://127.0.0.1:18789/
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
X-Frame-Options: DENY
...
Impact and severity
No response
Additional information
No response
Summary
The CLI gateway status command incorrectly reports a port conflict ("Port already in use") when the gateway is successfully running as a systemd user service. The CLI seems to confuse its own systemd-spawned process with an external conflicting process. Additionally, the CLI outputs debugging suggestions with invalid flags (e.g., --probe, --error, -n) that return unknown option errors.
Steps to reproduce
Install OpenClaw via package manager (npm) on a Linux VPS.
Configure and run the OpenClaw gateway as a systemd user service (~/.config/systemd/user/openclaw-gateway.service) binding to 127.0.0.1:18789.
During an update or when manually checking status, run the suggested command: openclaw gateway status --probe --deep. (This fails with unknown option '--probe').
Run the fallback command: openclaw gateway status --no-probe --deep.
Observe the status output claiming the port is already in use by another PID.
Run curl -I http://127.0.0.1:18789/ and observe that the gateway is actually perfectly healthy and returning HTTP/1.1 200 OK.
Expected behavior
The status command should correctly identify that the process bound to the port is its own valid systemd process, and report the gateway as healthy.
The CLI error messages and troubleshooting suggestions should only recommend valid flags that are actually implemented in the current version.
Actual behavior
The CLI reports that the port is blocked by a "rogue" process (which is actually just the running gateway) and incorrectly states that the gateway did not become healthy. Furthermore, attempting to use the CLI's suggested debugging flags results in errors:
openclaw gateway status --probe --deep -> error: unknown option '--probe'
openclaw logs --error -> error: unknown option '--error'
openclaw logs -n 50 -> error: unknown option '-n'
OpenClaw version
2026.2.22-2 (45febec)
Operating system
Ubuntu
Install method
npm
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response