Bug report

Environment

• OpenClaw 2026.6.5 (5181e4f), npm install, stable channel
• Gateway: systemd user service, local loopback, WSL2 (linux 6.6.114.1-microsoft-standard-WSL2, node 22.22.0)
• Channel: WhatsApp (Baileys plugin 2026.6.5)
• Agents: main (user-facing, pi runtime) → spawns workflow-lead (depth 1) → spawns content-lead / editorial-review (depth 2)

Summary

When a depth-1 subagent calls sessions_yield while waiting on its own depth-2 children, the background task that tracks that subagent run is settled as cancelled, and the standard cancellation notice — Background task cancelled: Subagent task (run <id>) — is delivered into the requester (user-facing) session as a visible message.

Nothing was actually cancelled: no operator ran openclaw tasks cancel, the requester agent made no cancel tool call, and the yielded subagent session kept orchestrating normally — it was woken by each child completion, ran all 5 planned steps, and produced the final deliverable ~37 minutes later.

Two problems:

1. Status taxonomy violation. The docs (Background tasks) define cancelled as "Stopped by the operator via openclaw tasks cancel". The yield path reuses this terminal status for a run that is, per the sub-agents doc, merely waiting ("the waiting primitive ... ends the current model turn and waits for runtime events").
2. False-failure notice leaks to the end user. The cancellation notice is injected into the owner session and dispatched to the user channel (WhatsApp). The end user sees "Background task cancelled" for a job that is alive and ultimately succeeds. The requester agent then burns turns investigating (subagents list shows the child as active (waiting on N children) — directly contradicting the notice).

Reproduction (observed twice, deterministic)

Flow: user asks main for a multi-step deliverable → main does sessions_spawn(agentId=workflow-lead) → workflow-lead spawns its first child and calls sessions_yield.

Occurrence 1 — run 78c48230:

Occurrence 2 — run a07e4c37 (retry of the same job):

Evidence

Task ledger (openclaw tasks list --json, trimmed/redacted):

{
  "taskId": "883da0ed-ec58-4bcb-ba02-ce901d2cad8f",
  "runtime": "subagent",
  "requesterSessionKey": "agent:main:whatsapp:direct:+55XXXXXXXXXXX",
  "ownerKey": "agent:main:whatsapp:direct:+55XXXXXXXXXXX",
  "childSessionKey": "agent:workflow-lead:subagent:df8b8587-3b37-4a7d-8dd7-299862a77eb8",
  "agentId": "main",
  "runId": "a07e4c37-2815-44e2-928c-425f9b535e01",
  "status": "cancelled",
  "deliveryStatus": "delivered",
  "createdAt": 1781233203657,
  "startedAt": 1781233240686,
  "endedAt": 1781233240686,
  "lastEventAt": 1781233240686
}

workflow-lead session transcript (the yield that coincides with the settle):

{"timestamp":"...T03:00:19...","message":{"role":"assistant","content":[{"type":"toolCall","name":"sessions_yield","arguments":{"message":"Aguardando retorno do step_1."}}]}}
{"timestamp":"...T03:00:19...","message":{"role":"toolResult","content":[{"type":"text","text":"{\n  \"status\": \"yielded\",\n  \"message\": \"Aguardando retorno do step_1.\"\n}"}]}}

Requester (main) session — the notice arrives as a visible assistant message and goes out to the user channel:

{"timestamp":"...T03:00:20...","message":{"role":"assistant","content":[{"type":"text","text":"Background task cancelled: Subagent task (run a07e4c37)."}]}}

Same-session contradiction ~3 minutes later: subagents list from main reports the run's child session as active, "waiting on 2 children" — while the task ledger says cancelled.

The orchestration itself was healthy throughout: each depth-2 completion woke the yielded workflow-lead, which advanced its plan (update_plan) and spawned the next step, ending with the deliverable. So the cancelled settle is purely a bookkeeping/notification defect on the yield path — but it is user-visible and reads as a hard failure.

Expected behavior

• A subagent run that yields while waiting on children keeps its background task in a non-terminal state (running, or a dedicated waiting state), OR settles it with a status that does not collide with operator cancellation semantics.
• No Background task cancelled notice is delivered to the requester/user session unless the run was actually cancelled (operator tasks cancel, or an explicit cancel tool call).

Actual behavior

• First sessions_yield of the depth-1 subagent → its tracking task settles cancelled (occurrence 1: same second as the yield; occurrence 2: 21 s later, with startedAt == endedAt).
• The cancellation notice is dispatched to the end user, who sees a false failure for a job that completes successfully minutes later.

Related (not duplicates)

• sessions_yield terminates isolated cron sessions instead of waiting for next turn #46298 — sessions_yield terminates isolated cron sessions instead of waiting (different surface; here the session survives, only the task record + notice are wrong)
• sessions_yield with pending child subagents can be announced upstream as 'completed successfully' #46719 — yield with pending children announced upstream as "completed successfully" (same root family, opposite false status)
• [Bug]: image_generate in isolated cron session — agent correctly uses sessions_yield but runner aborts with AbortError after callback is delivered #92120 — runner AbortError after yield callback in cron session
• Subagent announce give-up (retry-limit/expiry) does not wake parent waiting on sessions_yield → permanent deadlock #90178 — announce give-up doesn't wake a parent waiting on sessions_yield

These suggest the yield path settles/aborts the surrounding run in several contexts; this report adds the user-triggered subagent-chain case where the status lands as cancelled and the notice reaches the end user.