The child task was cancelled. Then a Gateway restart brought its parent conversation back. That is the failure described in the newly merged Stop repair in openclaw/openclaw: a user’s decision reached the background worker but did not become a durable decision about the conversation waiting for it.
The distinction matters to anyone who leaves an agent working across restarts. Recovery is supposed to rescue interrupted work. Here, according to the pull request’s reproduction, it rescued work the user had deliberately stopped. The change merged on September 20 UTC closes that particular gap. It does not establish that every installed OpenClaw already contains the repair.
The parent was waiting, not gone
When a parent agent delegates work, it can yield: end its current turn and wait for its children to report back. That leaves a conversation with unfinished business but no active parent run controller to interrupt. OpenClaw’s old cancellation path could stop the children and consume their pending completion wake without writing a terminal state for that waiting parent.
On restart, the saved record still looked like interrupted work. The recovery system could therefore continue it. This was a disagreement between two parts of the same application: the cancellation path had acted, but the recovery path did not have the record that made the action binding.
The revised session-abort handler captures the yielded parent before cancelling descendants. When descendant cancellation occurs, it writes that parent’s cancellation through the existing lifecycle machinery before returning the response. The updated restart documentation makes the acknowledgment boundary explicit: the saved cancellation must be there when Stop answers.
A late Stop must not cancel the next job
Simply adding a write would introduce another danger. While child cleanup is happening, the user could start a new turn or reset the session. The old Stop must not arrive late and overwrite that newer work.
The patch preserves checks on run identity and the session’s particular incarnation. Its regression cases replace the parent during cancellation and assert that the replacement remains intact. Another case stops one child while a sibling cannot be cancelled. The response still reports incomplete cancellation, but the captured parent’s cancelled state is saved before that error goes out.
That is the consequential limit: a parent can be durably cancelled while the application honestly reports that descendant cleanup was incomplete. A green-looking parent state would be a poor substitute for reading the error. The tests also keep queue-only cancellation separate; clearing a queued follow-up is not permission to rewrite the waiting parent.
Two different holes behind one button
A nearby Hermes Agent repair helps explain why “make Stop stronger” is too vague a reading. Its background delegations had been detached from the parent turn’s active-child list. Interrupting that turn therefore did not reach them. Hermes adds session-scoped interruption of those background units, including the case where the parent is already idle, and preserves an interrupted child’s available partial answer.
OpenClaw’s reported failure was different: the child had stopped, and the waiting parent’s record was the missing piece. These are two concrete cancellation boundaries, not evidence of a shared implementation or a general verdict on which agent is safer.
The OpenClaw pull request reports a before-and-after Control UI reproduction with a real model-backed parent, a running child and an actual Gateway restart. That is stronger evidence than a state assertion alone, but it remains the contributor’s reported runtime test. We inspected the merged implementation and regression cases; we did not independently repeat that live experiment or map the change to a released package.
For operators, the useful acceptance test now has a second act: stop a harmless delegated job, wait for the acknowledgment, then restart the Gateway and inspect both parent and child. No completed external action is undone by this repair. The next signal is whether the installed build remembers the user’s cancellation as reliably as it remembers unfinished work.