openclaw - 💡(How to fix) Fix Telegram restarts should not emit silent-reply filler; expose staged readiness [1 comments, 1 participants]

Summary

When OpenClaw restarts the gateway from inside an active Telegram direct-message turn, the turn can be terminated before a normal final response is delivered. Telegram delivery then treats the turn as having ended without a visible final response, creates a NO_REPLY fallback, and the default direct-chat silent-reply policy rewrites it into a visible filler message such as No extra notes from me.

Separately, gateway startup logs report Telegram native command overflow when more than 100 commands are configured. That warning is not a delivery failure, but it makes restart readiness harder to reason about because "gateway ready" happens before channels/plugins/memory are fully initialized.

Environment

• OpenClaw: 2026.4.23
• Node: 25.9.0
• Channel: Telegram DM
• Gateway service: systemd user service
• Config relevant defaults:
  • commands.native = "auto"
  • commands.nativeSkills = "auto"
  • no local silent-reply override

Observed behavior

During an operator-approved gateway restart from a Telegram interaction:

1. Gateway receives restart/shutdown signal.
2. The active Telegram turn is interrupted.
3. The command/session is aborted by SIGTERM.
4. Telegram delivery sees no visible final response.
5. OpenClaw generates a NO_REPLY fallback.
6. Default direct-chat policy rewrites that fallback into a visible canned message, for example No extra notes from me.

This makes intentional restarts look like the assistant sent a low-quality or irrelevant response.

Relevant local log sequence:

[gateway-tool] gateway tool: restart requested
[gateway] signal SIGUSR1 received
[gateway] received SIGUSR1; restarting
[gateway] ready (...; 0.8s)
[gateway] starting channels and sidecars...
[telegram] [default] starting provider
[telegram] limits bots to 100 commands. 104 configured; registering first 100.
[telegram] menu text exceeded the conservative 5700-character payload budget; shortening descriptions...

On a full systemd restart:

Stopping openclaw-gateway.service...
[gateway] signal SIGTERM received
[gateway] received SIGTERM; shutting down
Stopped openclaw-gateway.service
Started openclaw-gateway.service
[gateway] ready (...; 3.0s)
[gateway] starting channels and sidecars...
[plugins] embedded acpx runtime backend ready
[telegram] [default] starting provider
[gateway] qmd memory startup initialization armed for 3 agents

Expected behavior

Intentional gateway restarts should not produce visible silent-reply filler in direct chats.

Preferably:

1. Send the user-visible restart acknowledgement before initiating shutdown.
2. Mark the current turn as intentionally terminated by restart.
3. Suppress the no-visible-final-response fallback for that restart-owned turn.
4. Report readiness in stages so operators know when the gateway is actually usable again.

Suggested upstream fix

Restart-safe reply handling

• Add an intentional-restart marker to the active turn before SIGTERM / in-process restart.
• If Telegram delivery sees "no visible final response" for a turn marked as intentionally restarting, skip the NO_REPLY fallback/rewrite path.
• Ensure /restart or gateway restart tools deliver an acknowledgement before shutdown when possible.

Staged readiness

Expose/log readiness stages separately:

• process started
• http ready
• plugins ready
• channels ready
• memory ready
• operational

Restart commands should wait for the right stage before saying restart completed. For Telegram-originated restarts, channels ready is the minimum useful stage.

Telegram command overflow UX

Current behavior caps at the first 100 commands and shortens descriptions, which is reasonable. But the log should be clearer that:

• Telegram menu registration was truncated.
• Typed/hidden commands may still work.
• This is a menu/discoverability issue, not a channel delivery failure.

Longer term, OpenClaw should provide deterministic priority/curation for Telegram's 100-command menu instead of relying only on "first 100".

Why this matters

For operators managing OpenClaw primarily through Telegram, gateway restart is a common maintenance action. The current behavior makes a successful/intentional restart appear as an assistant quality failure, because the user sees a generic canned response after restart rather than a clear lifecycle message.