Summary

Sub-agent announce delivery via the queue consistently fails with No active WhatsApp Web listener (account: default) even when WhatsApp is confirmed connected and actively sending/receiving messages.

Environment

• OpenClaw version: 2026.2.26 (also reproduced on 2026.2.24)
• OS: Linux 6.6.87.2-microsoft-standard-WSL2 (x64), Node 25.5.0
• Channel: WhatsApp (single account, default)

Evidence

1. openclaw channels status --probe confirms WhatsApp is enabled, configured, linked, running, connected
2. Normal WhatsApp message routing works perfectly (inbound/outbound messages flow fine)
3. Sub-agent announces accumulate in ~/.openclaw/delivery-queue/ with lastError: "No active WhatsApp Web listener"
4. Items persist across gateway restarts — restart increments retryCount but delivery still fails with the same error
5. ~24 stuck items observed spanning multiple days (Feb 22 and Feb 28), confirming this is persistent, not transient
6. The issue also affects TUI sessions (not just WhatsApp), suggesting the direct agent delivery path (session injection) is also unreliable

Reproduction

1. Start OpenClaw with WhatsApp channel connected
2. Spawn a sub-agent via sessions_spawn tool
3. Wait for sub-agent to complete
4. Observe: announce does not arrive in the main session
5. Check ~/.openclaw/delivery-queue/ — new item with WhatsApp listener error

Expected behavior

Sub-agent announce should be delivered to the requester session, either via:

• Direct agent delivery (session injection) — primary path
• Queue/channel delivery (WhatsApp) — fallback path

Actual behavior

• Direct agent delivery works intermittently (~2/11 success rate observed)
• Queue fallback always fails with stale WhatsApp listener state
• No announce-related entries appear in gateway logs (openclaw logs)

Workaround

Manually check sub-agent status via subagents list + sessions_history to retrieve results.

Additional context

• Queue items contain a mirror field with sessionKey: "agent:main:main" — unclear if this drives delivery or is metadata
• retryCount maxes at 1-2, suggesting very limited retry attempts
• Gateway logs show zero announce/delivery traces at info or debug level, making diagnosis difficult