Summary

A Signal final reply can be lost/stranded when the OpenClaw gateway restarts while a send is in progress. The gateway later reports a pending delivery in send_attempt_started and refuses blind replay, but the user-facing outcome is that the assistant never visibly replies on Signal unless a human nudges the session again.

This is especially bad when the reply is an important completion/fix report: OpenClaw can look healthy locally while the phone-visible Signal reply never arrives.

Observed environment

• OpenClaw: 2026.6.1 (2e08f0f)
• Signal transport: native signal-cli
• signal-cli: 0.14.4.1 (latest upstream release at time observed)

Evidence from one local incident

Sanitized timeline:

1. An assistant turn generated a normal final reply after a fix report.
2. Gateway logs recorded Signal send acceptance earlier in the flow with channels/signal delivered reply ...; in the local signal-cli account DB there were matching outgoing send-log rows for the target recipient.
3. The reply did not become visible in the recipient's Signal app.
4. During a later config/plugin flow, gateway restart occurred while at least one delivery was in flight:

02:31:13 gateway: signal SIGTERM received
02:31:13 gateway: received SIGTERM; shutting down
02:31:13 channels/signal: signal-cli: INFO Shutdown - Received SIGTERM signal, shutting down ...
02:31:13 channels/signal: signal daemon exited (source=process code=0 signal=null)
02:31:23 gateway/delivery-recovery: Found 1 pending delivery entries — starting recovery
02:31:23 gateway/delivery-recovery: Delivery entry ... delivery state is send_attempt_started; refusing blind replay without adapter reconciliation
02:31:23 gateway/delivery-recovery: Retry failed for delivery ...: delivery state is send_attempt_started; refusing blind replay without adapter reconciliation

The current behavior is internally conservative, but operationally it silently drops the user-visible completion path.

Expected behavior

When a gateway restart interrupts a Signal delivery after send_attempt_started, OpenClaw should not leave the user in a state where the session appears completed locally but no Signal-visible reply arrives.

Any of these would be better than the current outcome:

• Reconcile with the Signal adapter/send log and mark the delivery as completed only if there is strong evidence.
• Retry safely when the adapter can provide idempotency or message identity guarantees.
• Mark the delivery as failed and surface it to the assistant/session so it can re-send or notify explicitly.
• Before planned gateway/config restarts, drain or fence active reply deliveries so final replies are not interrupted mid-send.
• Change log wording so delivered reply means phone-visible/adapter-confirmed delivery, or use a weaker term such as send accepted.

Acceptance criteria

• A regression test covers a restart between delivery persistence and adapter send completion (send_attempt_started).
• Recovery does not silently strand the final reply.
• The session/assistant receives a durable failed-delivery signal when recovery refuses replay.
• Logs distinguish adapter/send acceptance from confirmed user-visible delivery.
• Planned restarts/config reloads either drain active Signal sends or surface any interrupted sends after restart.

Notes

This does not look like a signal-cli version-skew issue. The observed host was already on signal-cli 0.14.4.1, which was the latest AsamK/signal-cli release at observation time. The failure is in OpenClaw's delivery lifecycle/restart recovery semantics around send_attempt_started.