Description

Every incoming message triggers a secondary lane that always fails with EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released. The first lane processes successfully and replies normally, but the second lane consistently fails, wasting resources and producing noisy error logs.

This is distinct from #66646 (which covers SessionWriteLockTimeoutError cascading through fallback) — this issue is about a second parallel lane being spawned for the same session that always conflicts with the first lane.

Reproduction

1. Configure OpenClaw with a single agent, wecom channel (websocket mode), no fallback
2. Send any message to a wecom group chat
3. Observe: message is processed and replied to once (correct), but a second lane attempt also fires and fails with EmbeddedAttemptSessionTakeoverError

Expected behavior

Only one lane attempt should process a single incoming message. The secondary lane should either not be spawned, or should detect that the session is already being handled and skip.

Actual behavior

Every message produces this pattern:

[wecom] [server -> plugin] cmd=aibot_msg_callback, reqId=xxx  ← message received
[wecom] Reply message sent via WebSocket, reqId=xxx             ← first lane succeeds
[diagnostic] lane task error: lane=main durationMs=19387        ← second lane fails
  error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: ...jsonl"
[diagnostic] lane task error: lane=session:agent:main:wecom:... ← same error, session lane
Embedded agent failed before reply: session file changed while embedded prompt lock was released: ...jsonl

The lane=main + lane=session:... pair always appears together, suggesting two parallel attempts for the same session.

Impact

• Every message generates noise in logs (error-level diagnostics)
• With fallback configured, the second lane triggers model fallback, causing duplicate replies ([Bug]: Session file lock errors cascade through model fallback chain #66646 compound effect)
• Even without fallback, the wasted second lane consumes API quota and latency

Environment

• OpenClaw 2026.5.18 (stable)
• Linux 6.8.0-101-generic (x64), 4 CPU, 3.6GB RAM
• Node 22.22.2
• Channel: wecom (websocket mode)
• Model: trapi/GLM-5.1 (single model, no fallback)
• compaction.mode: "safeguard", thinkingDefault: "adaptive"
• dmScope: "per-channel-peer"

Additional observations

• Removing fallbacks prevents duplicate replies but does NOT eliminate the secondary lane attempt
• Removing maxConcurrent (was set to 4, now using default) does NOT fix it
• A separate OpenClaw instance (same version, same compaction/thinking settings, but no maxConcurrent set and different channel) does NOT exhibit this issue — suggesting the trigger may be specific to the wecom channel or session state
• The error always occurs after the first lane has already successfully sent a reply (5-15 seconds later), suggesting the second lane is a background/housekeeping process (heartbeat? compaction check?) rather than a duplicate message delivery

Related

• [Bug]: Session file lock errors cascade through model fallback chain #66646 — Session file lock errors cascade through model fallback chain (closed, fix incomplete)
• Telegram inbound can fail with persistent session write lock on existing DM session #69790 — Telegram inbound can fail with persistent session write lock on existing DM session