Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

A gateway tool action: "restart" call that includes continuationMessage can return ok with coalesced: true while silently failing to persist or deliver that continuation after the gateway restarts.

Steps to reproduce

1. Trigger a gateway restart from a config/plugin workflow, for example installing/enabling a plugin or updating plugins.entries.* under the default gateway.reload.mode: "hybrid" path.
2. While that restart is already scheduled or in-flight, call the gateway tool explicitly with an additional restart request that includes a continuation, for example:

{
  "action": "restart",
  "reason": "Load newly installed plugin and channel account",
  "note": "Installed plugin and channel account; restarting gateway to load the plugin.",
  "continuationMessage": "Gateway restart completed. Continue checking whether the new plugin tools are visible; if available, invoke the expected readiness/account tool; otherwise report the missing tool surface."
}

3. Observe the tool response contains mode: "emit" and coalesced: true.
4. Wait for the gateway restart to complete.

Expected behavior

If the gateway restart tool accepts continuationMessage and returns ok, the continuation should be durably queued and delivered exactly once after restart, even when the restart request coalesces with an existing restart. If OpenClaw cannot guarantee delivery in a coalesced path, the tool response should explicitly report that the continuation was not queued instead of returning a normal success shape.

Actual behavior

The gateway restart notification is delivered, but the continuation run is not triggered. In the observed case the user saw only a restart-card style notice similar to:

Gateway restart config-patch ok (config.patch)
Set default model to openai-codex/gpt-5.5 and enable fast mode by default for the main agent.
Run: openclaw doctor --non-interactive

No follow-up agent turn was created from the provided continuationMessage. The user had to manually continue the session.

OpenClaw version

2026.4.26 source checkout at 166a6d9088d0

Operating system

macOS 26.2 (25C56)

Install method

Source checkout / local gateway development workspace. Exact launched gateway install wrapper for the observed run: NOT_ENOUGH_INFO

Model

openai-codex/gpt-5.5

Provider / routing chain

OpenClaw agent -> gateway tool -> local Gateway SIGUSR1 restart path. LLM provider/model under test: openai-codex/gpt-5.5.

Additional provider/model setup details

The observed workflow also changed the main agent default model to openai-codex/gpt-5.5 and enabled fast mode by default. Other provider routing details: NOT_ENOUGH_INFO

Logs, screenshots, and evidence

Observed tool request included action="restart" plus continuationMessage.
Observed tool response included mode="emit" and coalesced=true.
Observed post-restart user-visible notice was the config-patch restart card.
Observed missing behavior: no continuation agent turn was delivered.

Code evidence from current checkout:

• The explicit gateway restart action builds a restart sentinel payload with continuation from continuationMessage, but only writes it inside emitHooks.beforeEmit, not at tool-call time: src/agents/tools/gateway-tool.ts:375, src/agents/tools/gateway-tool.ts:387, src/agents/tools/gateway-tool.ts:401.
• scheduleGatewaySigusr1Restart() returns early with coalesced: true when a restart signal is already in-flight (hasUnconsumedRestartSignal()), before registering or running the caller's emitHooks: src/infra/restart.ts:621.
• Startup only enqueues/drains a continuation when the persisted restart sentinel contains payload.continuation: src/gateway/server-restart-sentinel.ts:485.
• The config-patch restart path writes a restart notification sentinel but does not add a continuation: src/gateway/server-methods/config.ts:353, src/gateway/server-methods/config.ts:583.

Impact and severity

Affected: agent-driven plugin/channel setup flows and any workflow where an agent asks the gateway to restart with a one-shot continuation while another restart is already scheduled or in-flight.

Severity: High for these workflows. The user sees a successful restart notification but the promised follow-up work is silently lost.

Frequency: Intermittent/racy in general, but reproducible when action: "restart" with continuationMessage lands in the already-in-flight coalescing window.

Consequence: plugin installation/channel activation flows can stall after restart; the user must manually send another message to continue and may believe the continuation was queued because the tool returned success.

Additional information

Related but not exact duplicates found during triage:

• Support continuation prompt in restart sentinel #50137 added/supports restart sentinel continuations, but this bug is about losing an already-provided continuation in a coalesced restart path.
• RFC: Task Continuation Across Gateway Restarts (Checkpoint + Auto-Resume) #60864 tracks broader task checkpoint/auto-resume semantics, but this report is narrower: a one-shot continuationMessage accepted by the existing gateway restart tool is silently dropped.
• Gateway restart drops queued and in-flight inbound messages #51620 and openclaw update run mid-turn causes total message loss on Telegram (and likely Discord) #71178 cover broader restart-time message loss and in-flight turn interruption; this report is specifically about the gateway restart tool's continuation contract under coalescing.

A likely fix is to either persist/merge continuation intent when a restart request coalesces with an in-flight restart, or return an explicit continuationQueued: false/error so the agent can choose a different recovery path.