Summary

openclaw gateway restart can return a false failure on Linux/systemd even when the gateway restarts successfully and is immediately healthy afterward.

Environment

• OpenClaw: 2026.4.12 and still reproducible after updating to 2026.4.14
• Platform: Linux + systemd user service
• Gateway bind: loopback 127.0.0.1:18789
• Service command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789

Observed behavior

After running:

openclaw gateway restart

I can hit this pattern:

• systemd stop/start succeeds
• openclaw gateway status reports runtime running and RPC probe: ok
• openclaw gateway probe reports connect ok / RPC ok
• dashboard remains reachable
• but the restart command itself still returns a non-zero / failure result

Observed error noise around the failures included:

• exec approval followup dispatch failed
• unknown or expired approval id
• Session followup failed: gateway timeout after 60000ms

Why this looks like a false negative

After the reported restart failure, the gateway is healthy:

• openclaw gateway status -> running, RPC ok
• openclaw gateway probe -> reachable yes, connect ok, RPC ok
• dashboard HTTP checks succeed

I also rebooted the host during investigation, upgraded the kernel, and re-verified the same general pattern on the healthy post-reboot install.

Narrowed code regions

I narrowed the likely reporting path to these areas in the current npm build:

• dist/daemon-cli-87pputG1.js
  • runDaemonRestart(...)
• dist/lifecycle-core-BZacBWkW.js
  • runServiceRestart(...)
• dist/restart-health-CGx4SqG5.js
  • waitForGatewayHealthyRestart(...)
  • inspectGatewayRestart(...)
• dist/bash-tools-CEAaYnEc.js
  • sendExecApprovalFollowupResult(...)
• dist/server.impl-BbJvXoPb.js
  • approval resolution path returning unknown or expired approval id

Specific suspicion

There seem to be two overlapping signals:

1. The CLI restart/post-restart path can throw hard on a post-restart health/reporting branch.
2. The exec approval followup machinery appears to sometimes try to send a completion followup against an approval id that is already resolved/expired, producing:
   • exec approval followup dispatch failed
   • unknown or expired approval id

My working theory is that a successful restart is getting contaminated by a stale/expired exec approval followup path or adjacent post-restart reporting path, which causes the command to surface failure even though the service is healthy.

Workaround

For now, the reliable operator workaround is:

openclaw gateway restart
openclaw gateway status
openclaw gateway probe

and treat status / probe as authoritative if they are healthy, instead of trusting the restart exit code alone.

Additional note

I also confirmed that the systemd restart helper itself looks straightforward (systemctl --user restart ...) and the gateway comes back with a healthy runtime + probe, so this does not look like a real service restart failure.

If useful, I can help test a candidate patch or provide a more surgical repro if you want a build to try.