What happens

When the gateway tries to self-restart on Windows (e.g. after openclaw config patch, or via the dashboard's restart action), the underlying schtasks /Run call fails. The running gateway terminates (WS close 1006) and there's no graceful re-launch — the dashboard disconnects, in-flight tool/agent responses are dropped, and the gateway only comes back when something else (manual openclaw gateway, retry, a fresh config-load cycle) revives it. In my case it recovered roughly 1m20s later via what looked like a fresh loading configuration… cycle, but the gap caused visible mid-turn failures in an attached agent session.

Reproduction

1. Windows 11, OpenClaw 2026.5.28, gateway installed via openclaw gateway install (Scheduled Task registered under the user account, non-elevated).
2. Apply any config patch that requires restart, e.g. openclaw config patch --stdin with a Telegram allowFrom change. CLI confirms "Applied N config update(s). Restart the gateway to apply."
3. Trigger restart (via the dashboard restart action, the gateway MCP/RPC restart method, or whatever the CLI/UI exposes for this).

What the log shows

```
2026-06-04T00:08:46.139-04:00 error gateway connect failed: Error: gateway closed (1006):
2026-06-04T00:08:46.158-04:00 error gateway connect failed: Error: gateway closed (1006):
2026-06-04T00:08:46.207-04:00 error Gateway restart failed: Error: schtasks run failed:
2026-06-04T00:08:46.228-04:00 info Tip: openclaw gateway install
2026-06-04T00:08:46.232-04:00 info Tip: openclaw gateway
2026-06-04T00:08:46.235-04:00 info Tip: schtasks /Run /TN "OpenClaw Gateway"
2026-06-04T00:10:03.922-04:00 info gateway loading configuration…
```

A few things stand out:

• The error message after schtasks run failed: is empty. The underlying schtasks stderr (access denied, task already running, locked, etc.) is not surfaced, which makes self-diagnosis hard.
• The tips printed are sensible operator suggestions, but a non-technical user hitting this from the dashboard never sees them.
• openclaw status immediately after recovery reports: "Gateway service: Scheduled Task installed · registered · running (pid 46848, state Ready, Verified gateway listener detected on port 18789 even though schtasks did not report a running task.)" — that half-state where the listener is verified on port but schtasks says not-running is its own oddity worth investigating.

Asks

1. Surface the underlying schtasks stderr in the Gateway restart failed: Error: schtasks run failed: log line so users can self-diagnose (access denied vs. task already running vs. locked vs. something else).
2. Add a graceful fallback: if schtasks /Run fails, fall back to an in-process restart (or spawn the gateway directly) so a standard non-elevated install survives config.patch-driven restarts without dropping all sessions.
3. Reconcile the half-state: when the listener is verified on port but schtasks reports "not running," openclaw status and the restart path should agree on a canonical truth (probably "if the verified listener is alive, the gateway is up regardless of schtasks").

Environment

• OS: Windows 11 (10.0.26220), single-user, non-elevated shell context
• OpenClaw: 2026.5.28
• Scheduled Task name: OpenClaw Gateway (default), installed under the current user