Summary

When an agent task requires restarting the gateway (e.g., applying config changes via config.patch, config.apply, or running updates), the user who initiated the request receives no feedback about whether the operation succeeded, failed, or completed at all.

This is especially problematic when the user communicates through an external channel (Telegram, WhatsApp, Discord, etc.) — from their perspective, they asked for something and the assistant simply went silent.

Current behavior

1. User asks the agent to change a config setting (or any task that requires a gateway restart)
2. Agent applies the change and restarts the gateway
3. Gateway goes down, session is interrupted
4. Gateway comes back up
5. User receives nothing — no confirmation, no error, no status update

The agent can work around this by manually saving pending context to a file and checking it on the next heartbeat, but this is fragile, error-prone, and requires explicit implementation by every agent/user.

Expected behavior

After a gateway restart triggered by an agent action, the system should automatically deliver a completion message to the user on the channel where the request originated. Something like:

• "Gateway restarted successfully. Config changes applied."
• Or if it failed: "Gateway restart failed: [reason]"

Possible approaches

• Post-restart hook: A built-in mechanism where the agent (or the gateway itself) can queue a message to be delivered after the restart completes. The gateway could persist a "pending delivery" payload before shutdown and process it on startup.
• Sentinel message: The gateway could accept a note or postRestartMessage parameter in restart-triggering commands, persist it, and deliver it to the originating channel after successful startup.
• Session continuity: The gateway could track that a session had an in-flight request when it shut down, and prompt the agent to complete/report on it after restart.

Why this matters

This isn't a crash or a technical bug — the gateway restarts fine. But from a user experience perspective, it's a functional gap: the user initiates an action, expects feedback, and gets silence. For users who rely on external channels as their primary interface (which is the whole point of OpenClaw), this creates uncertainty and erodes trust in the assistant.

Workaround

Currently, agents can implement a manual workaround:

1. Before restart: write pending context to a file (e.g., data/pending-reply.json)
2. In HEARTBEAT.md: check for pending replies and deliver them post-restart

This works but is brittle — it depends on the agent remembering to save state, the heartbeat running promptly, and the file not getting corrupted. A first-class solution would be more reliable and wouldn't require per-agent implementation.