Summary

When an OpenClaw agent restarts its own gateway from inside a channel-originated chat turn, the restart can succeed at the service-manager level but still drops the current in-flight reply. To the user, this presents as "the bot went silent" even though the gateway later comes back healthy.

We hit this while debugging Telegram forum/Generic topic delivery on OpenClaw 2026.5.4 (325df3e). This is separate from the Telegram forum topic delivery issue in #77248: that issue is about normal finals not always being visibly delivered to Telegram forum topics. This issue is about losing any in-flight channel reply when the agent restarts its own gateway mid-turn.

I first tried to add this evidence to the closest existing restart issues (#40932, #44490, #40275), but those conversations are locked, so I am filing this separately.

Environment

• OpenClaw: 2026.5.4 (325df3e)
• OS: Linux
• Node: 22.22.0
• Gateway: local loopback, user systemd service
• Channels: Telegram enabled, Discord enabled
• Telegram scenario: forum group, Generic topic (topic:1)

What happened

Observed locally:

1. User sends a Telegram forum/Generic topic message.
2. OpenClaw receives it and routes it to the expected topic session, e.g. agent:main:telegram:group:<chat>:topic:1.
3. During that same turn, the agent runs systemctl --user restart openclaw-gateway.service from an exec/tool call.
4. Gateway logs signal SIGTERM received and exits cleanly.
5. The gateway restarts and later reports healthy (openclaw status shows gateway reachable and Telegram ON/OK).
6. The user still receives no reply for that turn, because the restart killed the execution chain before final Telegram delivery happened.

Relevant local log pattern:

16:40:25 systemd: Stopping openclaw-gateway.service
16:40:25 [gateway] signal SIGTERM received
16:40:28 [shutdown] completed cleanly
16:40:29 systemd: Started openclaw-gateway.service
16:40:54 [gateway] http server listening
16:40:59 [gateway] ready
16:41:03 [telegram] [default] starting provider

Important detail: this is not simply "restart does not restart". In this setup, systemd restart works. The problem is that initiating it from the same OpenClaw chat turn kills the reply path before visible channel delivery.

Expected behavior

If a user asks OpenClaw to perform maintenance that requires a gateway restart from Telegram/Discord/etc., the current visible reply should not be lost. The agent should either:

• refuse/block inline self-restart from a channel-originated turn, or
• schedule a delayed/detached restart after the current reply is delivered, or
• convert the inline restart into a safe deferred maintenance action automatically.

Actual behavior

The agent can run an inline gateway restart command during the turn. The gateway terminates, the turn dies mid-flight, and the user receives no final reply.

Local workaround that fixed the operational problem

1. Block inline gateway restarts from OpenClaw exec/tool calls

We enabled a local guard hook that blocks commands such as:

• openclaw gateway restart
• openclaw update unless explicitly no-restart
• systemctl --user restart openclaw-gateway.service
• systemctl --user stop openclaw-gateway.service
• systemctl --user reload openclaw-gateway.service
• systemctl --user kill openclaw-gateway.service

2. Use a detached delayed scheduler instead

On Linux/systemd, this worked reliably:

systemd-run --user \
  --unit openclaw-safe-restart-$(date +%Y%m%d-%H%M%S) \
  --description "OpenClaw delayed safe restart" \
  --on-active=20s \
  /home/ubuntu/.openclaw/workspace/scripts/openclaw-safe-restart.sh

The scheduled script then performs the actual restart and post-restart verification out of band:

systemctl --user daemon-reload || true
systemctl --user restart openclaw-gateway.service
sleep 8
openclaw status

3. Update local agent instructions

We changed local agent instructions to treat direct gateway restarts as forbidden inside a chat turn.

Merely telling the agent to "send a status message first, then restart" was not sufficient in our Telegram/Discord-originated setup, because the visible channel reply is generally delivered at turn finalization. Immediate restart can still happen before the user-visible message is sent.

Suggested upstream direction

• Treat self-restart-from-tool-call as an unsafe operation, even if the service-manager restart succeeds.
• Provide a built-in delayed/detached restart path for chat-initiated maintenance.
• Warn/block inline restart attempts from channel-originated turns, or convert them into scheduled restarts automatically.
• Document that gateway restarts from inside a channel turn can drop the current reply unless deferred.

Related issues

• [Bug]: Telegram Forum Topic Delivery Silently Fails #77248: Telegram forum/Generic topic visible delivery issue. Separate but this was discovered while debugging it.
• [BUG] openclaw gateway restart command fails and Gateway does not restart automatically (macOS LaunchAgent) #40932: openclaw gateway restart via tool call / exec can lose tool result or break the execution chain. Locked, could not comment there.
• [Bug]: openclaw gateway restart fails to restart service (SIGTERM instead of SIGUSR1) #44490: restart/SIGTERM-related issue. Locked, could not comment there.
• [Bug]: openclaw gateway restart fails while user systemd service works via systemctl --user (service shown as disabled/stopped inconsistently) #40275: user-systemd restart inconsistency. Locked, could not comment there.