OpenClaw Main Tightens Cancellation and Message Delivery Custody

OpenClaw has merged four related repairs that clarify who owns work when cancellation, retries and recovery collide. The common principle is simple: a reported abort must not start fresh queued tool work, and a message must not be dropped or duplicated merely because two recovery paths disagree about custody.

These fixes are on main. They are material, but merged status does not prove an installed package contains them.

Cancellation now settles queued agent work

PR #120856 addresses a particularly dangerous edge. An agent run could report cancellation, then continue an existing steering or follow-up loop. Those later iterations created fresh provider requests without the original abort signal and could execute queued tools.

The repair treats an aborted final assistant turn as settled at the existing post-run owner. Normal successful draining and legitimate handoffs continue, but cancellation no longer becomes a brief pause before un-signalled work resumes.

For operators, this changes the meaning of a stop button from “the current request ended” toward the safer “this run will not restart its queued continuation.” It does not eliminate every external side effect already committed before cancellation.

Delivery identity survives the route to the Gateway

PR #120108 closes three ownership gaps. Host-generated idempotency keys for message-tool sends and polls are now carried to the Gateway; recovery notices use normal outbound delivery on channels such as Signal; and synthetic lifecycle turns no longer force a Claude CLI session to be rebuilt from a lossy text-only transcript.

The idempotency point is the most broadly useful. A retry can only be deduplicated if the same logical delivery identity reaches the component making the send decision. Generating a key and then dropping it at an internal boundary is safety theatre.

Concurrent recovery no longer steals a live send

A one-shot CLI sender and the running Gateway can share the same SQLite state. Before PR #119966, Gateway recovery could claim a queue row while the short-lived sender was still dispatching it, opening a duplicate-send window.

New live deliveries now publish an expiring producer claim with their queue row. The active sender renews that claim through dispatch and settlement; recovery defers to that owner. This narrows a real cross-process race without changing the SQLite schema.

Absence of send evidence keeps the message queued

PR #120031 fixes the opposite failure: loss instead of duplication. A provider abort with no evidence of platform delivery could acknowledge and remove the queue entry when no producer claim ID existed.

The revised policy branches on evidence. If platform-send evidence exists, recovery avoids casually retrying an ambiguous send. If it does not, the message stays failed-for-retry. An explicit operator abort remains a deliberate drop path.

Interpretation: queue custody is now based more consistently on observed delivery facts rather than incidental ownership metadata. That is the correct invariant for at-least-once systems trying to approximate exactly-once user experience.

Test the combined failure modes

Do not validate these changes with a single happy-path message. On a non-production route:

1. Queue a harmless tool action behind a long provider turn, cancel the run, and prove no new provider request or tool execution begins afterward.
2. Send a uniquely identified message through the CLI while the Gateway is running; confirm one provider call and one recipient copy.
3. Simulate a provider abort before any send evidence and confirm the message remains visible for retry.
4. Simulate an ambiguous failure after send evidence and confirm recovery does not blindly duplicate it.
5. Restart the Gateway around each scenario and inspect the final queue or delivery outcome.

Use synthetic recipients and non-consequential tools. Testing cancellation against a payment, deployment or destructive action is a rotten way to discover the remaining boundary.

Bottom line

OpenClaw’s merged fixes move cancellation and delivery toward one coherent rule: ownership must be explicit, evidence must survive process boundaries, and settled work must stay settled. Upgrade when these changes reach your channel, then test cancellation and delivery recovery as one system—not as separate features.