Gateway on Windows goes offline periodically (Scheduled Task) — gateway closed (1006) + Unhandled promise rejection: TypeError: fetch failed

Summary

Running OpenClaw/Clawdbot Gateway on Windows 11 (Node v22.17.0) via the default Windows Scheduled Task results in the assistant appearing “offline” every few hours. When this happens, the Gateway becomes unreachable and needs a manual restart.

Environment

• OS: Windows 11
• Node: 22.17.0
• Gateway bind: loopback (127.0.0.1)
• Gateway port: 18789
• Install/run mode: Scheduled Task (Clawdbot Gateway), interactive logon

Scheduled Task details (current):

• Logon mode: Interactive only
• Stop task if runs longer than: 72:00:00
• Last Result observed: 267009

What happens

• Bot becomes unresponsive in Telegram (appears offline).
• clawdbot gateway status sometimes shows the service loaded but not running and/or probe failures.

Evidence (log excerpts)

File logs:

• C:\tmp\clawdbot\clawdbot-2026-01-30.log
• C:\tmp\clawdbot\clawdbot-2026-01-31.log

1) Gateway abnormal closure + service not running

From clawdbot-2026-01-30.log (around 2026-01-30T23:19:09Z):

RPC probe: failed
RPC target: ws://127.0.0.1:18789
  gateway closed (1006 abnormal closure (no close frame)): no close reason
  Gateway target: ws://127.0.0.1:18789
  Source: cli --url
  Config: C:\Users\phill\.clawdbot\clawdbot.json

Service is loaded but not running (likely exited immediately).

2) Unhandled promise rejection (undici/fetch)

From clawdbot-2026-01-31.log:

[clawdbot] Unhandled promise rejection: TypeError: fetch failed
    at node:internal/deps/undici/undici:13510:13
    at processTicksAndRejections (node:internal/process/task_queues:105:5)

In the same file, this appears shortly before gateway startup logs:

... embedded run done ...
[clawdbot] Unhandled promise rejection: TypeError: fetch failed
... gateway/canvas mounted ...
... telegram provider starting ...
... gmail watcher started ...

Expected

Gateway should be resilient to transient fetch/network failures and not go “offline” (or should self-restart cleanly). Unhandled promise rejections should be caught/handled so they can’t take down the process.

Questions

1. Is TypeError: fetch failed (undici) expected to be fatal? Where should this be caught?
2. Any recommended Windows-native daemon/supervisor path (service wrapper, watchdog) vs. “use WSL2”? (Windows-native seems under-tested.)
3. Is Scheduled Task “stop after 72 hours” an intentional default? (This will force downtime every 3 days.)

Repro notes

Intermittent: appears every few hours. Happy to add more diagnostics if maintainers specify what to capture (more log context around the fetch to identify the URL, Task Scheduler history export, Windows Event Viewer entries, etc.).