Summary

On Native Windows, restarting the gateway via /restart (or gateway restart commands) stops the existing gateway process but fails to relaunch it, leaving the gateway offline. (which this is definitely a known bug... it is literally unimplemented lmao)

Steps to reproduce

1. Install and run Clawdbot Gateway.
2. Trigger a restart (e.g., /restart in chat or clawdbot gateway restart).
3. Wait for the gateway to 'restart'.

Expected behavior

The restart should stop the existing gateway and reliably start a new gateway process. The old gateway console window should close, and only the new gateway window should remain.

Actual behavior

The gateway process stops, but the scheduled task does not reliably start a new process (task shows Ready, Last Result: 1). The gateway remains offline.

Environment

• Clawdbot version: 2026.1.24-3 (from gateway.cmd)
• OS: Windows (non-WSL, frick wsl)
• Install method: npm global install (npm -g)

Logs or screenshots

• schtasks /Query /TN "Clawdbot Gateway" /V /FO LIST shows:
  • Status: Ready
  • Last Result: 1
  • Next Run Time: N/A
• Gateway logs show restart intent, then no relaunch.

Suggested implementation (that works on my machine)

1. Add a helper scheduled task for restart:
   • Create restart-helper.cmd in the gateway state dir.
   • The helper performs: /End, kill gateway node PID, kill any lingering gateway process, then /Run the main task.
2. Ensure the old gateway console window is closed:
   • In the helper script, kill the cmd.exe that launched gateway.cmd
3. Windows-specific restart routing:
   • On Windows, skip SIGUSR1 and always call the scheduled-task restart path.
   • This avoids in-process SIGUSR1 flow that is unreliable on win32.

How it fits into this codebase

• The gateway is already managed as a Scheduled Task on Windows (dist/ daemon/schtasks.js).
• The restart logic lives in dist/infra/restart.js, which already handles:
  • launchctl on macOS
  • systemd on Linux
  • now schtasks on Windows
• Existing commands (/restart, config reload) route through triggerClawdbotRestart() and scheduleGatewaySigusr1Restart(), so adding the Windows restart path here keeps behavior centralized and consistent.

Why not a “native Windows service” rewrite?

• The gateway is currently installed as a Scheduled Task, not a Windows Service.
• Switching to Windows Service control APIs would require a different install mechanism and is out of scope for a fix.
• schtasks is already used by the codebase to manage Windows startup, so extending it for restart is aligned with existing design.