Bug Report: Subagent sessions persist after completion, main session becomes unresponsive

Version: OpenClaw 2026.3.13 (stable channel)
Environment: WSL2, Ubuntu 24.04.4, Node v24.14.0
Channel: webchat (openclaw-control-ui dashboard)

Summary

After spawning multiple subagent sessions (particularly when some fail), the main session becomes unresponsive to new user messages for a period after the subagent result is delivered. Session list shows stale subagent sessions that appear to persist beyond their completion.

Steps to Reproduce

1. Open dashboard (openclaw-control-ui)
2. Spawn a subagent session that fails (e.g., due to missing API key)
3. Retry multiple times (6+ attempts in my case)
4. After subagent finally completes successfully, main session stops responding to new messages
5. Messages sent after subagent result delivery appear to be queued/ignored
6. After some time passes, main session becomes responsive again

Observed Behavior

• openclaw status shows multiple subagent sessions still listed after completion
• Main session does not receive new messages immediately after subagent delivers result
• User sees "unresponsive" behavior even after sessions_yield returns

Expected Behavior

• Subagent sessions should be cleaned up after completion
• Main session should immediately receive new messages after subagent result is delivered
• Session list should not show completed subagent sessions

Session List Example

agent:main:main (active)
agent:main:subagent:<uuid-1> (stale - completed)
agent:main:subagent:<uuid-2> (stale - completed)
agent:main:subagent:<uuid-3> (stale - completed)
...

Multiple subagent sessions remain in list despite having completed.

Workaround

• Wait for some time (~30-60 seconds) after subagent result before sending new messages
• Alternatively, use a different channel (Telegram) which appears more responsive

Additional Context

• Gateway logs show no errors during this behavior
• sessions_yield documentation states "End your current turn" - but main session appears to remain in a "waiting" state
• Subagent spawn mode was run (one-shot), not session (persistent)

Logs

Gateway logs show normal operation - cron timers, request handling, no error messages related to session state. No exceptions thrown.

Configuration

Model: ollama/glm-5:cloud
Channel: webchat
Gateway: bind=lan, port=18789

Possible Root Cause

Hypothesis: When main session yields to wait for subagent completion, the session state may not fully clear after receiving the subagent result. There may be a race condition or cleanup delay that prevents the main session from immediately processing new incoming messages.