Summary

When spawning two ACP sessions (sessions_spawn runtime:"acp") in rapid succession (~37s apart), the first agent's CC process never starts while the second eventually works fine.

Environment

• OpenClaw 2026.3.22
• acpx 0.1.16
• ACP backend: acpx, defaultAgent: claude
• Node 22.22.1, macOS (arm64)

Steps to Reproduce

1. From a main session, call sessions_spawn twice in quick succession:
   • Agent 1 spawned at 02:22:28 UTC
   • Agent 2 spawned at 02:23:05 UTC (37s later)
2. Both return status: "accepted" with valid childSessionKey and streamLogPath

Observed Behavior

Agent 1 (0a73e5e1):

• lifecycle:start emitted at 02:22:28
• stall warning at 02:23:28 (60s, no output)
• No assistant_delta events ever appear — CC process never produced any output
• ps aux | grep claude.*reachfar shows no matching process

Agent 2 (ebf86699):

• lifecycle:start emitted at 02:23:05
• stall warning at 02:24:05 (60s cold start)
• assistant_delta appears at 02:25:17 — CC starts working normally
• Progress updates continue ("Now let me read the specific files...")

Expected Behavior

Both agents should launch successfully. A ~37s gap between spawns should not cause the first to silently fail.

Stream Log Evidence

Agent 1 stream log (3 lines total, never progresses):

lifecycle:start → system_event:stall → (nothing)

Agent 2 stream log (resumes after cold start):

lifecycle:start → system_event:stall → assistant_delta ("Now let me read...") → system_event:resumed → ...

Workaround

Falling back to direct claude --print --permission-mode bypassPermissions via exec works reliably for parallel spawns (tested 3 concurrent agents successfully).

Analysis

The acpx backend appears to have a race condition during concurrent session initialization. The first session's CC process is either:

1. Never spawned (acpx loses the session init in concurrent handling)
2. Spawned but immediately crashes without emitting any output
3. Blocked waiting on a resource the second session acquires first

Since the session is "accepted" and lifecycle:start fires, the issue is downstream of session registration — likely in the acpx CLI launch path.

Related

• [Bug]: v2026.3.22 regression: ACP backend acpx stops registering after update even though host acpx CLI still works #52878 — ACP backend registration regression
• fix: enable ACP completion relay for main sessions #53256 — ACP completion relay fix (different bug, addresses result routing)
• RFC: ACP completion relay — unified approach to close the parent notification loop #49782 — RFC: ACP completion relay