openclaw - 💡(How to fix) Fix [Bug]: Persistent ACP session resume fails for Kiro threads after backend invalidation

Bug type

Behavior bug

Beta release blocker

No

Summary

Thread-bound ACP sessions can get stuck when OpenClaw reuses a stale persistent session ID that the ACP backend no longer recognizes, causing ACP_TURN_FAILED / SessionResumeRequiredError on new turns.

Steps to reproduce

1. Spawn a thread-bound ACP session for claude or kiro with runtime: "acp", thread: true, mode: "session".
2. Send a first message and allow the session to initialize.
3. Send another message to the same thread after the persistent session has become stale or unavailable.
4. Observe that OpenClaw attempts to resume the previous persistent ACP session and the turn fails with Persistent ACP session <id> could not be resumed.

Expected behavior

A stale ACP persistent session should either recover cleanly or be discarded and replaced with a fresh session, so the thread remains usable.

Actual behavior

For Kiro, the next turn fails immediately with errors like:

• AcpRuntimeError [ACP_TURN_FAILED]
• SessionResumeRequiredError
• Persistent ACP session <id> could not be resumed: Internal error

In the observed cases, the thread remains alive enough to show reactions/processing signals, but it does not produce a normal text reply.

OpenClaw version

2026.5.19

Operating system

Linux 6.8.0-106-generic (x64)

Install method

Local workspace / developer build

Model

local/gpt-5.4-mini

Provider / routing chain

OpenClaw -> ACP runtime -> Kiro CLI / Claude Code ACP adapter

Logs, screenshots, and evidence

Observed in ACP stream logs under /home/chouzz/.openclaw/agents/*/sessions/*.acp-stream.jsonl.

Relevant Kiro failures:

AcpRuntimeError [ACP_TURN_FAILED]: Persistent ACP session 814f4306-1208-44d2-a1c5-631efdc95453 could not be resumed: Internal error <- SessionResumeRequiredError: Persistent ACP session 814f4306-1208-44d2-a1c5-631efdc95453 could not be resumed: Internal error <- RequestError [-32603]: Internal error

AcpRuntimeError [ACP_TURN_FAILED]: Persistent ACP session 90c67b6a-94f2-4deb-bac6-a35a0c277e62 could not be resumed: Internal error <- SessionResumeRequiredError: Persistent ACP session 90c67b6a-94f2-4deb-bac6-a35a0c277e62 could not be resumed: Internal error <- RequestError [-32603]: Internal error

Relevant Claude failure / recovery behavior:

Persistent ACP session 5eb470ed-2c79-4215-ab57-6750552a5045 could not be resumed: Resource not found: 5eb470ed-2c79-4215-ab57-6750552a5045

Followed by a successful recovery and normal reply in the same thread.

Additional implementation context from the repo suggests the resume path reuses resolveRuntimeResumeSessionId(previousIdentity) and only falls back after ACP_SESSION_INIT_FAILED, which may leave stale identity state around after a resume failure.

Impact and severity

Affected: thread-bound ACP sessions, especially Kiro in the observed tests. Severity: high for affected threads because the thread becomes unusable for normal replies. Frequency: reproducible in the observed Kiro thread spawns. Consequence: users can send messages and see reactions/processing signals, but the agent never returns a normal text response.

Additional information

Observed with two separate Kiro ACP thread spawns; both failed on stale persistent session resume IDs. The Claude ACP thread in the same environment was able to recover from a stale session once, which suggests the issue is not simply “thread messaging while busy”, but a session resume / stale identity handling problem.