Summary

A tool-running embedded attempt can terminate with error and send no user-visible reply when it hits:

session file changed while embedded prompt lock was released: <sessionFile>

This makes the assistant appear silent/dead to the user even though the inbound message was received and the run started.

Observed behavior

In a Telegram group session, a user message was received and the assistant began a tool call (memory_search). During the tool-running attempt, the run ended with status error and no final assistant reply was delivered.

Relevant trace evidence:

2026-06-03T02:07:21Z prompt.submitted msg=35153
2026-06-03T02:07:39Z assistant toolCall memory_search
2026-06-03T02:07:59Z session.ended status=error
promptError: session file changed while embedded prompt lock was released: /home/node/.openclaw/agents/officer/sessions/e0d2c6f2-03c6-4ce6-90d8-37405cd75c08.jsonl

Later, the dangling tool call was repaired as:

memory_search -> aborted

…but the original user-visible failure was silent.

Root cause / trigger

This appears to be a race condition around embedded prompt session locking:

1. A run starts for a user message.
2. The assistant calls a tool.
3. During tool execution, the embedded prompt lock is released.
4. The same session file is modified by another writer or repair/background process.
5. When the run resumes, the session file fingerprint has changed.
6. Runtime throws EmbeddedAttemptSessionTakeoverError.
7. The run ends as error without a user-visible reply.

Expected behavior

A user request should not silently disappear. On this error, runtime should do one of:

• automatically retry the current user request once after recompiling the latest session context; or
• send a user-visible failure notice, e.g. “Internal session concurrency conflict; the previous run was interrupted, please retry.”

Why this matters

The current behavior is confusing in chat surfaces: the user sees that they asked something, but the assistant never replies. It looks like the bot ignored them or died, while internally the run ended with an error.

Suggested fix

Handle EmbeddedAttemptSessionTakeoverError specially in the runtime:

• catch it at the run boundary;
• if safe, retry once with fresh context;
• otherwise emit a clear user-visible failure message rather than ending silently.