Summary

Matrix messaging works normally in this environment, but ACP thread-bound session creation/routing fails because the Matrix room ID is being lowercased somewhere in the session/binding path.

This appears related to #57321, but the impact here is narrower and different:

• normal Matrix room messaging works
• the bot is definitely in the room
• failures only appear when invoking ACP thread-bound sessions
• the likely problem is that the room ID is preserved correctly for normal delivery, but lowercased in session key / binding / routing metadata used by ACP thread-bound flows

Related

• [Matrix] Lowercased room ID in delivery-recovery causes sync loop crash and permanent message loss #57321, lowercased Matrix room ID in delivery-recovery
• [Bug]: Matrix: per-room requireMention/autoReply config ignored due to room ID case mismatch #19278, Matrix room ID case mismatch in config lookup

This issue seems to be the same root family, but specifically in ACP thread-bound session binding/routing, not general Matrix messaging.

Environment

• OpenClaw: 2026.4.x
• Channel: Matrix
• Problem area: sessions_spawn(..., runtime: "acp", thread: true, mode: "session")

What works

Normal Matrix messaging works fine in the same rooms.

Evidence:

• gateway startup logs show the correct mixed-case room IDs
• messages can be sent normally to those rooms
• Matrix membership is valid, the bot is already in the room

Example startup log entries show correct IDs such as:

• !FEVFJFQloZmRnZhfIi:<redacted>
• !WduXsjCLEtbgDqbJuU:<redacted>

What fails

When attempting to invoke ACP thread-bound sessions, the routing/session path appears to use a lowercased room ID.

Observed evidence:

1. Session index stores lowercased Matrix room IDs

In ~/.openclaw/agents/main/sessions/sessions.json, a Matrix channel session was stored like:

• session key:
  • agent:main:matrix:channel:!wduxsjcletbgdqbjuu:<redacted>
• groupId:
  • !wduxsjcletbgdqbjuu:<redacted>

But in the same object, the delivery/origin metadata still preserves the correct case:

• deliveryContext.to:
  • room:!WduXsjCLEtbgDqbJuU:<redacted>
• origin.nativeChannelId:
  • !WduXsjCLEtbgDqbJuU:<redacted>

This strongly suggests the real Matrix room ID is known correctly, but the session/binding identity is normalized to lowercase.

2. Gateway log shows lowercased room ID during failure path

A relevant log line during the failure window:

Queue 'message' giving up on event ~!wduxsjcletbgdqbjuu:<redacted>:...

That lowercased room ID corresponds to the real room:

• actual: !WduXsjCLEtbgDqbJuU:<redacted>
• failing path: !wduxsjcletbgdqbjuu:<redacted>

Expected behavior

When spawning or routing ACP thread-bound sessions on Matrix:

• the original Matrix room ID casing should be preserved
• ACP thread binding should use the canonical room ID from Matrix metadata, not a lowercased normalized key
• thread-bound session creation should succeed in rooms where normal Matrix delivery already works

Actual behavior

ACP thread-bound session flows fail as if the bot is not in the room, even though it is.

The likely real failure is:

• room ID is lowercased in session key / groupId / binding metadata
• Matrix room IDs are case-sensitive
• ACP thread/session routing later uses the lowercased ID and fails lookup/delivery/binding

Suspected root cause

A Matrix room ID is being lowercased in one of these places:

• session key construction
• channel/group identity normalization
• ACP thread binding target derivation
• any path that reconstructs delivery target from groupId or session key instead of nativeChannelId

Suggested fix

• never lowercase Matrix room IDs used for actual routing/binding
• keep any normalized session key separate from the real Matrix target ID
• prefer nativeChannelId / original delivery target when binding ACP thread sessions
• audit all Matrix session-key/groupId derivation paths for case loss