Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Environment

• OpenClaw: 2026.4.14 (config written by 2026.4.14, service running 2026.4.5)
• OS: Linux 6.17.0-20-generic (x64)
• Node: v24.14.1
• Channel: Discord (persistent group sessions)
• ACP Runtime: acpx + Claude Code

Description

When an ACP (Claude Code) run takes a long time (7-14 minutes), it blocks the nested lane globally. Other agent sessions queuing behind it experience severe delays, and their assistant responses get generated (visible in session transcript) but never delivered to Discord.

Additionally, an agent session's channel field can silently degrade from discord to webchat after an ACP run completes, causing subsequent nested run outputs to be routed to the wrong delivery target.

Reproduction

1. Set up persistent agent sessions bound to Discord channels (e.g., agent:ebao, agent:ebao-next, agent:ebao-vue)
2. Agent A (ebao) dispatches tasks to Agent B (ebao-next) and Agent C (ebao-vue) via sessions_send(timeoutSeconds: 0)
3. Both B and C invoke ACP (Claude Code) to perform long coding tasks (file creation, compilation, type fixing loops)
4. While ACP runs are active, Agent A generates a summary text response
5. The response appears in Agent A's session transcript with stopReason: "stop"
6. The response never arrives in the Discord channel

Observed Behavior

Lane Congestion Timeline

T+0:00   ACP Claude Code starts for ebao-next (TASK-RTE-001-A)
         nested lane occupied

T+9:36   nested lane wait exceeded: lane=nested waitedMs=576497 queueAhead=1

T+9:37   ebao-next ACP run completes, output dumped
         But channel=webchat instead of discord ❌

T+9:37   Second wave: ebao-vue ACP also blocking nested lane
         nested lane wait exceeded again: waitedMs=459438

T+14:12  ebao-vue lane wait exceeded: waitedMs=851678 queueAhead=1
T+7:01   ebao lane wait exceeded: waitedMs=420524 queueAhead=1

T+14:19  Lanes finally release
         ebao generates summary text (visible in transcript)
         ❌ Text never delivered to Discord

Key Log Evidence

# nested lane blocked for 9.6 minutes
WARN  lane wait exceeded: lane=nested waitedMs=576497 queueAhead=1

# ebao-vue session blocked for 14 minutes
WARN  lane wait exceeded: lane=session:agent:ebao-vue:discord:channel:... waitedMs=851678 queueAhead=1

# ebao session blocked for 7 minutes
WARN  lane wait exceeded: lane=session:agent:ebao:discord:channel:... waitedMs=420524 queueAhead=1

# Nested run output delivered to WRONG channel
INFO  [agent:nested] session=agent:ebao-next:discord:channel:... channel=webchat "编译通过。提交推送..."
#                                                          ^^^^^^^^^ should be discord

Session State After Incident

// ebao-next session: channel degraded to webchat
{
  "key": "agent:ebao-next:discord:channel:1490736567680241715",
  "channel": "webchat",           // ❌ was "discord"
  "displayName": "webchat:g-1490736567680241715",  // ❌ was "discord:..."
  "deliveryContext": {
    "channel": "webchat"           // ❌ no "to" field, no accountId
  }
}

Expected Behavior

1. Long ACP runs should not block other agent sessions' lane
2. Assistant responses with stopReason: "stop" should always be delivered to the configured delivery target
3. Session channel/deliveryContext should not silently change after nested runs

Impact

• Agent task dispatch → completion → summary pipeline is broken: the final "task complete" notification never reaches the user on Discord
• Session channel corruption causes subsequent messages to go to webchat instead of Discord until session reset
• The user has no visibility that messages were lost (no error logged for dropped delivery)

Possible Root Causes

1. Nested lane is global/shared — one long ACP run blocks all other agents' nested runs across the entire gateway
2. Delivery context not preserved through ACP nested run lifecycle — the ACP runtime (webchat by default?) overwrites the parent session's delivery context
3. No delivery retry or DLQ — if delivery fails due to lane timeout, the message is silently dropped

Suggested Fixes

1. Per-session lane isolation — one agent's ACP run should not block another agent's lane
2. Preserve parent session's delivery context through nested ACP runs
3. Log a warning when an assistant response is generated but not delivered
4. Implement delivery retry or at minimum a DLQ for undelivered messages

Steps to reproduce

NOT_ENOUGH_INFO

Expected behavior

NOT_ENOUGH_INFO

Actual behavior

NOT_ENOUGH_INFO

OpenClaw version

2026.4.14

Operating system

Ubuntu 24.04

Install method

pnpm

Model

glm-5-turbo

Provider / routing chain

openclaw -> glm

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response