openclaw - 💡(How to fix) Fix [Bug]: Matrix per-room DM handling still sticks to older direct-room mappings and can miss newer DM rooms

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Summary

We are using OpenClaw with Matrix for a bot account that should handle multiple direct-message rooms with the same Matrix user.

OpenClaw now documents channels.matrix.dm.sessionScope: "per-room", and in practice this is the behavior we want. However, in our live setup we found that older direct-room mappings can still dominate routing/discovery, and newer DM rooms with the same person may not be recognized or replied to reliably.

This was not just a one-off config mistake on our side. We were able to reproduce behavior that suggests a gap between the documented per-room model and parts of the current runtime / repair / m.direct handling.

Environment

• OpenClaw: current 2026.5.x era npm-global install
• Channel: Matrix
• Homeserver: self-hosted Synapse
• Bot account: single Matrix bot account
• Intended config:
  • channels.matrix.dm.sessionScope: "per-room"
• Also previously had legacy / older DM history with the same Matrix user

Steps to reproduce

try matrix with multiple DMs

Expected behavior

When Matrix DM session scope is per-room:

• each strict 2-member DM room should be independently usable
• a newly created DM room with the same Matrix user should still work
• replies should go back into the triggering room
• older m.direct mappings should not prevent newer DM rooms from being recognized
• matrix direct repair should be able to recover a good direct mapping state reliably

Actual behavior

We observed several related problems:

1. If an older DM room with the same Matrix user already existed, newer DM rooms could fail to get replies.
2. m.direct for the remote user continued to prefer older rooms.
3. matrix direct repair was fragile because startup readiness could fail with:
   • Matrix client did not reach a ready sync state within 30000ms
4. In direct-room inspection/repair, once an existing mapped strict room was present, newer joined DM rooms could effectively be skipped from discovery.
5. In practice, newer strict 2-member rooms were sometimes only usable after local runtime patching.

OpenClaw version

OpenClaw 2026.4.15 (041266a)

Operating system

Rhasbian

Install method

npm global

Model

deepseek

Provider / routing chain

Matrix room -> Matrix plugin/runtime -> DM detection -> direct-room selection / m.direct logic -> session resolution -> agent run -> reply routing back to Matrix room

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

What we found

1. m.direct stayed stuck on older rooms

For a Matrix user @s:..., account data still preferred older rooms, while a newer replacement/test DM room was not present there.

That made old room mappings "sticky", even though the new room was a real strict DM room.

2. New strict room existed and was valid

We verified that the newer room was:

• encrypted
• exactly 2 joined members
• bot invited + joined
• normal 1:1 room semantics

So this did not look like an invalid room.

3. matrix direct repair was not enough

The built-in repair command failed repeatedly with:

Direct room repair failed: Matrix client did not reach a ready sync state within 30000ms

After extending that startup wait locally, the repair command became able to run longer, but still preferred the old mapped room and did not cleanly switch to the new one.

4. Direct-room inspection logic appears too conservative

In the installed runtime we found logic equivalent to this pattern inside Matrix direct-room inspection:

• mapped rooms are classified first
• if a mapped strict room already exists, joined rooms may no longer be searched for additional strict candidates

That means a valid new DM room can be missed simply because an old DM room is already mapped.

5. Runtime DM acceptance also seemed too conservative

We also found that for new Matrix strict 2-member rooms, runtime acceptance could depend too much on:

• existing m.direct
• recent invite promotion
• local member-state hints

In our case, a stricter "2 joined members = acceptable DM" fallback was needed before the new room started behaving properly in practice.

Why this matters

Matrix users often create replacement DM rooms over time:

• re-created encrypted DMs
• old DM left / abandoned
• test room vs production room
• same user contacting the bot in multiple DM contexts

If per-room is documented and intended, then older direct-room mappings should not effectively block newer valid DM rooms.

Related observations

We also saw that once the runtime behavior was loosened locally, multiple rooms started functioning in practice:

• one encrypted replacement/test room
• another unencrypted room

So this looks less like "Matrix cannot do it" and more like "some current discovery / mapping / fallback logic is still biased toward older room state".

Possible areas to review

• Matrix inspectMatrixDirectRooms() behavior when a mapped strict room already exists
• m.direct update / promotion rules when a new valid strict DM room appears
• interaction between per-room session scope and direct-room selection logic
• startup timeout / readiness handling for matrix direct repair
• whether strict 2-member rooms should be more readily accepted as DM candidates even if m.direct is stale

Possible improvement directions

Option A

Make joined-room discovery continue even when an older mapped strict room exists, so newer strict rooms can still be evaluated and surfaced.

Option B

When channels.matrix.dm.sessionScope = "per-room", reduce dependence on legacy m.direct preference and favor the triggering room if it is a valid strict 2-member DM.

Option C

Make the startup readiness timeout for Matrix repair configurable instead of relying on a fixed 30000ms path.

If useful, I can provide

• sanitized logs
• the exact direct-room inspection behavior we observed
• the local runtime changes we used for diagnosis
• a more minimal reproduction sequence