OpenClaw Subagents Reporting “Cancelled” While Still Running Is a Control-Plane Truthfulness Bug

Multi-agent systems do not need cheerful status. They need truthful status. If work is waiting, say waiting. If it failed, say failed. If it was cancelled, reserve that word for actual cancellation. The moment an orchestration platform tells a user “Background task cancelled” while the subagent keeps running and eventually completes, the platform has not merely logged a bad state. It has trained the operator not to trust the control plane.

That is the core problem in OpenClaw issue #92448. A reported depth-1 subagent calls sessions_yield while waiting for its own child agents, and its background task is marked cancelled. A visible cancellation notice is sent to the requester session. But the subagent continues orchestrating children and later produces the final deliverable. The data plane is alive. The control plane says it died.

The environment is specific enough to be useful: OpenClaw 2026.6.5 (5181e4f) on the npm stable channel, systemd user service on WSL2 Linux 6.6.114.1-microsoft-standard-WSL2, Node 22.22.0, and WhatsApp via Baileys plugin 2026.6.5. The workflow is also realistic: the main user-facing agent spawns a workflow-lead at depth 1; that lead spawns depth-2 children such as content-lead and editorial-review; then the lead yields while waiting. This is exactly what nested delegation is for.

Two lifecycles got collapsed into one bad word

The issue includes two occurrences. In the first, run 78c48230, workflow-lead called sessions_yield at 02:55:10; the task settled cancelled the same second and sent a notice to the main WhatsApp-facing session. In the second, run a07e4c37, the task ledger recorded startedAt == endedAt == 1781233240686 and terminal status cancelled. Yet from 03:03 to 03:38, the same workflow lead continued through five spawn/yield cycles and delivered the final result.

The contradiction gets worse: about three minutes after the cancellation notice, subagents list reportedly showed the run’s child session as active and “waiting on 2 children,” while the task ledger still said cancelled. That is not just messy bookkeeping. It is a split-brain orchestration state. One surface tells the user the task is over. Another surface says the agent is active. The transcript later proves the active surface was closer to reality.

The likely design pressure is familiar: a model turn ended because the agent yielded, and the durable background task lifecycle treated that as terminal. But yielding is not cancellation. It is a waiting primitive. A child session can pause its current turn while descendants continue. A durable task can remain active while a model invocation is not currently streaming tokens. A visible user-facing notice should be derived from durable lifecycle truth, not from a local turn termination event.

OpenClaw’s task docs describe background tasks moving from queued to running to terminal states such as succeeded, failed, timed_out, cancelled, or lost. That terminal vocabulary is useful only if the meanings are stable. If cancelled can mean “operator cancelled,” “policy cancelled,” or “a parent yielded while children continue,” it stops being a status and becomes a vibe. Production systems cannot be operated on vibes, however strongly the AI industry keeps trying.

“Supports subagents” is not the evaluation bar

This is why coding-agent comparisons need to move beyond feature checklists. “Supports subagents” sounds impressive, but the serious questions are control-plane questions: does nested work have a reliable ledger? Are waiting states explicit? Can cancellations be attributed to an operator or policy? Are wakeups durable? Do user-facing notices match task state? Can a parent wait on children without being marked terminal? Can a human safely retry, kill, or inspect work without causing duplicate execution?

Those questions matter because false failure signals are operationally expensive. If a user sees “Background task cancelled,” they may retry the job, spawning duplicate children against the same files or external systems. They may kill work that is actually healthy. They may ignore future real cancellations because the last one was false. In customer-facing channels like WhatsApp or Telegram, false negatives are especially damaging because the user does not have the full dashboard in front of them. They have one message, and that message lied.

The fix should be explicit state modeling. cancelled should mean cancelled by an operator or cancellation policy. Yielding while descendants run should map to states like waiting_on_children, awaiting_callback, or yielded_active, depending on the architecture. Model-turn lifecycle, child-session lifecycle, and background-task lifecycle should be separate concepts with documented transitions. User notifications should be emitted only when the durable task reaches a true terminal state, or when the platform can say precisely: “paused; waiting on 2 child agents.”

Practitioners using nested OpenClaw workflows should treat a single cancellation notice as a signal to inspect, not as authority. Cross-check the task ledger, subagents list, and transcript before retrying or killing work. If you run customer-facing automation, consider suppressing or reviewing automated background-task failure notices for nested workflows until this class of bug is fixed. Delayed status is annoying. False terminal status burns trust.

The larger point is that multi-agent orchestration is a control-plane product. The agents can be brilliant, the prompts polished, the child tasks well designed — and none of that saves the system if the runtime lies about whether work is alive. Reliability is not just finishing the job. It is telling the truth while the job is happening.

Sources: OpenClaw issue #92448, OpenClaw automation tasks docs, OpenClaw subagents docs, OpenClaw issue #90178