Summary

On a user-systemd gateway deployment, openclaw gateway status reports:

• Service config looks out of date or non-standard.
• Service config issue: Gateway service PATH is not set; the daemon should use a minimal PATH.
• Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").

In our environment, that warning persisted as an update-safety concern during a broader gateway env normalization effort.

What we observed

Environment:

• OpenClaw v2026.4.9
• user systemd service
• service file: ~/.config/systemd/user/openclaw-gateway.service
• gateway command: /usr/bin/node /home/xadmin/.local/lib/node_modules/openclaw/dist/index.js gateway --port 18789

Current live unit on Nexus:

[Service]
ExecStart=/usr/bin/node /home/xadmin/.local/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Restart=always
RestartSec=5
TimeoutStopSec=30
TimeoutStartSec=30
SuccessExitStatus=0 143
KillMode=control-group
EnvironmentFile=-/home/xadmin/.openclaw/.env

Current openclaw gateway status output still includes:

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH is not set; the daemon should use a minimal PATH.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").

At the same time, the gateway itself is healthy:

• Runtime: running
• RPC probe: ok
• listening on 127.0.0.1:18789

Why this matters

This makes updates/risk assessment harder because the operator is left with a persistent service warning even when:

• the gateway is healthy,
• the service is otherwise functional,
• and env sourcing has already been normalized.

In the same maintenance window, we also had to manually standardize the gateway env source to:

EnvironmentFile=-/home/xadmin/.openclaw/.env

because we wanted one canonical env source instead of older/alternate service env paths.

So from an operator perspective there are two closely-related concerns around service generation/repair:

1. doctor --repair is recommended for the PATH warning, but the PATH warning is not clearly self-healing.
2. service generation/repair behavior around EnvironmentFile conventions is opinionated enough that it creates update anxiety when local env normalization has already been done deliberately.

Repro

1. Install/run OpenClaw as a user systemd service.
2. Use a gateway service unit like:

[Service]
ExecStart=/usr/bin/node /home/xadmin/.local/lib/node_modules/openclaw/dist/index.js gateway --port 18789
EnvironmentFile=-/home/xadmin/.openclaw/.env

3. Run:

openclaw gateway status

4. Observe warning:

Service config issue: Gateway service PATH is not set; the daemon should use a minimal PATH.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").

Expected

One of these should happen consistently:

• openclaw doctor --repair rewrites the unit so the warning is actually cleared, or
• openclaw gateway status should not keep flagging the service if the generated unit is already acceptable for the current install path, or
• there should be a documented/configurable canonical service template that makes PATH + EnvironmentFile expectations explicit.

Suggested direction

• Ensure the generated/repaired user systemd unit always includes the minimal PATH expected by the health checker.
• Make doctor --repair idempotently converge the unit into the same shape that gateway status considers healthy.
• Clarify the intended canonical EnvironmentFile path for user-service installs so operators do not have to guess between ~/.openclaw/.env and other service env locations.

If helpful, I can follow up with the exact systemctl --user cat openclaw-gateway.service and openclaw gateway status output we captured during the maintenance window.