GitHub issue draft — restart-sentinel turn produces user-facing outbound reply

Repo: openclaw/openclaw
Title: Restart-sentinel turn on channel-bound session emits outbound reply to source chat

Summary

When the gateway restarts, restart-sentinel events posted to a channel-bound main-session (e.g. a WhatsApp group session with key agent:main:whatsapp:group:<id>@g.us) can cause the agent to generate a user-facing assistant reply that is then routed back to the source chat. Sentinels should be system-only and never produce outbound messages.

Impact

A reply intended for a different session/context (the user's TUI/Discord) was emitted into a WhatsApp group chat after the gateway restarted. Content in our case was harmless dev output ("Brew bin is now on my exec PATH...") but the same path could leak arbitrary in-progress assistant text into any channel the session is bound to.

Severity: low data sensitivity in our case, but the leak class is high — outbound messages should never be triggered by system sentinels.

Reproduction (observed, not minimised)

1. Configure WhatsApp inbound such that group messages spawn main-session agents (this itself is arguably a separate bug — see "Related" below).
2. Have an active session bound to a WhatsApp group: session key shape agent:main:whatsapp:group:<id>@g.us.
3. Trigger a gateway restart while there is in-flight assistant context from a sibling session.
4. Restart-sentinel posts to the group-bound session as a user turn.
5. Agent generates a continuation and the runtime routes the outbound reply to the group chat.

Trajectory evidence (sanitised id):

• Session id: c9add990-...
• Sentinel message id: restart-sentinel:agent:main:whatsapp:group:<id>@g.us:agentTurn:<ts>
• trace.artifacts.didSendViaMessagingTool: false — meaning the model did not invoke the message tool; the outbound was the default assistant-reply routing, not an explicit tool call. So suppression has to live in the runtime, not in agent prompt discipline.

Expected behaviour

Restart sentinels should be either:

• Suppressed entirely (no agent turn fired), or
• Fired with outbound routing disabled (assistant reply discarded, only side-effects like state hydration retained).

Suggested fix locations

• Wherever restart-sentinel synthetic user turns are produced, set an "internal turn" flag on the run that causes the messaging/channel router to drop the assistant reply for that turn (logging it to trajectory only).
• Alternative: change sentinel to a non-user-turn event (lifecycle hook) so the agent loop doesn't run at all.

Related (worth a separate issue if confirmed)

• WhatsApp group inbound should not auto-spawn main-session agents by default. Default should be DM-only with an explicit group allowlist, otherwise any group member can wake the agent in the group's session context. The blast radius of bug-1 (this issue) is amplified by bug-2.

Workaround

Pull the WhatsApp integration / restrict its inbound routing so group sessions don't get spawned. We did exactly this — easy because we treated WhatsApp as gimmicky anyway, but not a real fix.

Environment

• OpenClaw runtime via npm global, node 24.x and 26.x in mix
• WhatsApp plugin via Baileys (default setup)
• Host: WSL2 (Ubuntu) on Windows 11
• Date observed: 2026-05-28