Bug: Main agent blocked while sub-agent runs via sessions_spawn; runTimeoutSeconds ignored

Describe the bug

When spawning a sub-agent via sessions_spawn, the main agent becomes completely unresponsive to inbound messages until the sub-agent completes. Additionally, runTimeoutSeconds is ignored — a sub-agent configured with a 120-second timeout ran for 15+ minutes before being killed.

Environment

• OpenClaw version: 2026.2.13 (also reproduced on 2026.2.14)
• OS: macOS 26.2 (arm64)
• Node: v25.5.0
• Model: anthropic/claude-opus-4-6 (main), anthropic/claude-sonnet-4-5 (sub-agent)
• Channel: BlueBubbles (iMessage)
• Gateway mode: local (loopback)

Steps to reproduce

1. Main agent is running and responsive to messages via BlueBubbles
2. Spawn a sub-agent with a moderately complex task:

   sessions_spawn({
     task: "Create an architecture document at /path/to/file.md with detailed content...",
     label: "draft-architecture",
     runTimeoutSeconds: 120,
     cleanup: "delete"
   })
   

3. sessions_spawn returns { status: "accepted" } immediately (as expected)
4. Send a message to the main agent via BlueBubbles

Expected behavior

• Main agent should remain responsive to inbound messages while sub-agent works in background
• Sub-agent should be killed after 120 seconds (per runTimeoutSeconds)
• Messages to main agent should be processed independently of sub-agent status

Actual behavior

• Main agent stops processing inbound messages entirely
• runTimeoutSeconds: 120 is ignored — sub-agent ran for 15 minutes 53 seconds
• All queued messages and responses fire at once when sub-agent finally terminates
• From the user's perspective, the assistant goes dark for 16 minutes then dumps 5 messages simultaneously

Additional context

• Short tasks work fine: A simple email-check sub-agent (17 seconds) completed without blocking the main agent
• Long tasks block: The architecture-doc sub-agent (15+ minutes) blocked the main agent completely
• Possibly related: The sub-agent's task description was long (~2000 chars). Unclear if task length vs runtime is the trigger.
• This appears related to Gateway session lock blocks CLI agent commands when subagents are running #7108 (gateway session lock blocks CLI) and [Bug]: Session file locks not released after write (v2026.2.9) #15000 (session file locks not released after write), but neither issue describes this specific sub-agent → main agent blocking scenario.

Transcript evidence

From the main session transcript, there's a 16-minute gap with no activity:

2026-02-15T21:45:44.365Z — sessions_spawn returns "accepted"
[no activity for 16 minutes]
2026-02-15T22:01:36.937Z — everything unblocks, queued messages processed

Workaround

Keep sub-agent tasks short and focused (<30 seconds). Long-running or complex tasks still block the main agent.