Summary

On Windows, channel-triggered /restart (confirmed via Telegram) still fails to bring the gateway back online, even though the local CLI-managed restart path works.

On this machine:

• openclaw gateway start works
• openclaw gateway restart works
• /restart from a channel stops/drains the gateway, but it does not come back until I manually run openclaw gateway start

This appears to be a remaining divergence between the channel /restart path and the CLI service restart path on Windows.

Environment

• OpenClaw: 2026.3.13
• OS: Windows
• Install method: npm global install
• Channel used for repro: Telegram
• Gateway managed by: Windows Scheduled Task (OpenClaw Gateway)

Reproduction

1. Start the gateway normally via managed service:
   • openclaw gateway start
2. Confirm normal operation.
3. Trigger /restart from Telegram (or another channel surface that hits the same command path).
4. Observe gateway goes away / drains.
5. Observe it does not come back by itself.
6. Manually run:
   • openclaw gateway start
7. Gateway returns.

Expected

Channel-triggered /restart on Windows should restart the managed gateway service and come back online automatically, same as the CLI restart path.

Actual

Channel-triggered /restart does not restore the gateway on Windows, while the CLI restart path does.

Important comparison / narrowing

I verified locally that the CLI-managed path is working:

openclaw gateway start
openclaw gateway restart

Both succeed and the gateway comes back.

So the issue now seems specifically about the channel /restart path on Windows, not the generic CLI-managed restart path.

Installed code observation

On this install, /restart is handled in the reply path and eventually calls:

• triggerOpenClawRestart()
• on Windows: relaunchGatewayScheduledTask(process.env)

Meanwhile the CLI restart path goes through the daemon/service manager path (openclaw gateway restart) and behaves correctly here.

That suggests the remaining bug is likely in the Windows channel-triggered restart/relaunch path rather than the general Scheduled Task restart implementation used by the CLI.

Extra note: Scheduled Task policy

The Windows task on this machine originally had:

<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>

I changed it to:

<MultipleInstancesPolicy>Queue</MultipleInstancesPolicy>

That was worth fixing, but it did not resolve the channel /restart problem.

So IgnoreNew may be a contributing edge case, but it is not the whole issue here.

Workaround

For now, local CLI works:

• openclaw gateway restart
• or if needed, openclaw gateway start

But /restart from Telegram/channel still fails to restore service.