Summary

On the released npm package OpenClaw 2026.6.11 (e085fa1), a Signal direct-message inbound was delivered to the local Signal account but was dropped by OpenClaw during reply-session handoff with:

reply session initialization conflicted for agent:main:signal:direct:<redacted-phone>

Outbound Signal delivery continued to work, and the Signal receive websocket stayed connected. The user saw two Signal checkmarks, but OpenClaw did not wake/respond until a local retry workaround was patched in.

This looks like the same reply-session conflict family as #98220 and #96837, but those are closed as fixed on current main; this report is specifically that the published 2026.6.11 npm release can still drop Signal direct inbound messages.

Environment

• OpenClaw: 2026.6.11 (e085fa1)
• Install: npm global
• Channel: Signal direct message through the official @openclaw/signal adapter
• Account: existing local signal-cli account; no new Signal account was created by the plugin
• Session key shape: agent:main:signal:direct:<redacted-phone>

Observed behavior

1. Send a Signal message to OpenClaw.
2. Signal delivers it to the local Signal account/device; outbound sends also work.
3. OpenClaw logs show the inbound fails at source=replyResolver with:

Error: reply session initialization conflicted for agent:main:signal:direct:<redacted-phone>

4. The inbound message is effectively dropped from the user's perspective: OpenClaw does not respond or continue the session.

In the local incident, the failed inbound happened a few seconds after an outbound Signal reply was delivered, suggesting the guarded reply-session initialization collided with normal session-row churn from delivery/recovery metadata.

Local investigation

Comparing the installed package with 2026.6.10:

• 2026.6.10 did not have the reply session initialization conflicted... error string/path.
• 2026.6.11 adds commitReplySessionInitialization(...) with an expectedRevision guard.
• In the installed release, the revision is a full serialized entry:

function createReplySessionInitializationRevision(entry) {
  return JSON.stringify(entry ?? null);
}

So any session-entry change between snapshot and commit can cause a stale-snapshot conflict, including harmless high-churn fields like delivery timestamps, token/session status metadata, restart recovery state, active-memory/compaction metadata, etc.

The release path had a very small retry. I locally increased this to a bounded 5 retries with short backoff, restarted, and the next Signal inbound test (patchtest) reached OpenClaw successfully. That is only a local mitigation, not a root fix.

Expected behavior

A transient reply-session initialization stale-snapshot conflict should not drop Signal inbound messages.

Preferably, reply-session initialization should either:

• serialize snapshot+commit per sessionKey in the shared session writer lane;
• compare a canonical persisted-shape revision, not the entire runtime session entry;
• merge harmless concurrent metadata churn rather than failing the inbound;
• or retry with bounded backoff and preserve the inbound event until it succeeds or dead-letters visibly.

Actual behavior

A delivered Signal inbound can be lost at the reply-session initialization boundary when the session row changes between read and guarded write.

Impact

High for messaging surfaces: Signal appears to deliver the user message, but OpenClaw silently does not respond. Basic outbound tests can pass, making the problem look like Signal inbound is broken even though the adapter/receive websocket are alive.

Related issues / fixes

• [Bug]: Error: reply session initialization conflicted for agent:main:main #98220 reports reply session initialization conflicted for agent:main:main and was closed as fixed on current main via shared reply-session initialization serialization / canonical persisted-shape revision comparison.
• Telegram DM spooled update hot-loops on reply session initialization conflict in 2026.6.11-beta.1 #96837 reports a Telegram DM conflict/hot-loop and was closed as fixed on current main for Telegram backoff.

If the fix for #98220 is already on main but not in the 2026.6.11 npm release, this may just need a patch release/backport. If it is expected to be in 2026.6.11, Signal direct sessions may need a separate regression test for this exact path.

Suggested regression coverage

A Signal/direct-message or generic direct-channel regression where:

1. reply-session initialization loads a snapshot for agent:main:signal:direct:<id>;
2. a concurrent harmless session metadata update occurs before commit, e.g. delivery timestamp/status/token metadata;
3. inbound handling still initializes/continues the reply session and does not drop the message.