Bug description

ACP sessions created via sessions_spawn(runtime="acp", thread=true, task="...") can enter a stale "running" state where:

1. The session appears in OpenClaw session state as status: "running"
2. The session history shows only the placeholder task — the real task payload was never delivered
3. The ACP runtime has no first-class close or kill operation for these stale sessions

OpenClaw version

OpenClaw 2026.3.31 (213a704)

Steps to reproduce

1. Spawn an ACP thread session: sessions_spawn(runtime="acp", agentId="codex", thread=true, mode="session", task="real task")
2. Observe the ACP session creates successfully and a childSessionKey is returned
3. Call sessions_history(sessionKey="agent:codex:acp:<id>") immediately
4. The history shows only the placeholder task, not the real task — the handoff failed silently
5. The session remains in status: "running" indefinitely
6. There is no sessions close <id> or equivalent operation in the ACP runtime API to terminate it

Expected behavior

One of:

• sessions_spawn task delivery should succeed reliably, OR
• there should be a first-class sessions close / sessions kill operation to terminate a stale ACP session

Actual behavior

• Spawn returns success
• Task never lands in session history
• Session stays running with no cleanup path
• ACP session accumulation with no close/kill mechanism

Workaround observed

The only reliable workaround is to bypass sessions_spawn entirely and drive the ACP harness directly via acpx codex exec one-shot or direct acpx codex sessions new --name <session> / acpx ... -s <session> for persistent sessions. That path does not suffer from the same handoff ambiguity.

Impact

• Stale ACP sessions accumulate in session state with no cleanup path
• Operators cannot reliably recover from failed handoffs — only start replacement sessions
• The lack of a close/kill mechanism makes ACP session lifecycle management incomplete

Labels

bug, bug:behavior