Matrix thread replies regression in OpenClaw 2026.5.22

Summary

After upgrading OpenClaw from 2026.5.20 to the current stable 2026.5.22, Matrix thread behavior regressed.

There are two main Matrix issues:

1. Bot answers in Matrix are sent as normal Matrix replies instead of being posted inside the thread, even though thread replies are configured as always.
2. Messages sent inside existing older Matrix threads do not produce a proper in-thread bot reply. When manually creating a new Matrix thread, the bot does answer, but again only as a normal reply, not inside that thread.

Related command issue:

1. Matrix slash commands such as /status and /model do not produce any bot response.

Downgrading back to 2026.5.20 is the current workaround.

Versions

Observed broken on:

OpenClaw 2026.5.22
openclaw 2026.5.22
@openclaw/matrix 2026.5.22
@openclaw/acpx 2026.5.22
@openclaw/codex 2026.5.22

Also tested and still broken on the 2026.5.26 beta line:

OpenClaw 2026.5.26-beta.2
@openclaw/matrix 2026.5.26-beta.2

Known workaround:

OpenClaw 2026.5.20
openclaw 2026.5.20
@openclaw/matrix 2026.5.20
@openclaw/acpx 2026.5.20
@openclaw/codex 2026.5.20

The Matrix plugin was updated together with OpenClaw, so the failure was reproduced with matching core/plugin versions.

Relevant Matrix config

Current Matrix channel config has thread replies explicitly enabled globally and for DMs. Identifiers below are redacted, but the config shape and relevant options are unchanged:

{
  "channels": {
    "matrix": {
      "homeserver": "https://matrix.example.net",
      "threadReplies": "always",
      "replyToMode": "all",
      "dm": {
        "policy": "allowlist",
        "allowFrom": [
          "@user:example.net",
          "@user:example.org"
        ],
        "threadReplies": "always"
      }
    }
  }
}

Matrix bindings include both group and channel room bindings for several agents:

[
  {
    "agentId": "hausbau",
    "match": {
      "channel": "matrix",
      "peer": {
        "kind": "group",
        "id": "!ROOM_ID_HAUSBAU:example.net"
      }
    }
  },
  {
    "agentId": "hausbau",
    "match": {
      "channel": "matrix",
      "peer": {
        "kind": "channel",
        "id": "!ROOM_ID_HAUSBAU:example.net"
      }
    }
  },
  {
    "agentId": "finance",
    "match": {
      "channel": "matrix",
      "peer": {
        "kind": "group",
        "id": "!ROOM_ID_FINANCE:example.net"
      }
    }
  },
  {
    "agentId": "finance",
    "match": {
      "channel": "matrix",
      "peer": {
        "kind": "channel",
        "id": "!ROOM_ID_FINANCE:example.net"
      }
    }
  }
]

Expected behavior

With threadReplies: "always":

• If a user sends a message inside a Matrix thread, the bot should answer inside that same thread.
• If a user manually creates a new Matrix thread and messages the bot there, the bot should answer inside that new thread.
• Matrix commands such as /status and /model should return a response in the relevant Matrix room/thread.

Actual behavior on 2026.5.22

• The bot response is created as a normal Matrix reply instead of a thread reply.
• Existing older threads do not get proper in-thread bot responses.
• Newly created manual threads get a bot response, but the response is still a normal reply, not a message inside the thread.
• /status and /model commands in Matrix produce no response.

Runtime health

The Matrix channel itself is connected and healthy; this does not look like a general Matrix login/connectivity failure.

Probe after downgrading back to the workaround version:

{
  "matrix": {
    "configured": true,
    "baseUrl": "https://matrix.example.net",
    "running": true,
    "lastError": null,
    "probe": {
      "ok": true,
      "userId": "@bot:example.net"
    },
    "connected": true,
    "healthState": "healthy"
  }
}

During startup there are also repeated Matrix SDK/log messages for some historical threads:

Couldn't find timeline for thread ID ... in room ...

There are also decryption warnings for old encrypted events sent before the current Matrix device login/key availability. Those appear historical and do not explain the current live channel health.

Regression range

Empirically:

• 2026.5.20: thread behavior works / current workaround.
• 2026.5.22: thread behavior broken as described above.
• 2026.5.26-beta.2: still broken with the same user-visible Matrix thread behavior.

No 2026.5.21 npm package was available during testing, so the practical published regression range is 2026.5.20 to 2026.5.22.

Possibly related issue

This may be related to, but does not look identical to, #75670.

That issue focuses on Matrix opaque ID case-normalization, duplicate/stuck sessions, and delivery failures such as Can't send relation to unknown event. In this report, Matrix channel health is green and the user-visible failure on 2026.5.22 is:

• replies are created, but as normal Matrix replies rather than in-thread messages;
• Matrix commands such as /status and /model produce no response;
• downgrading to 2026.5.20 restores usable behavior.

Notes

The failure was reproduced with matching OpenClaw and Matrix plugin versions, so this does not appear to be caused by a stale @openclaw/matrix install:

openclaw: 2026.5.22
@openclaw/matrix: 2026.5.22

After testing, the host was downgraded back to 2026.5.20 as a workaround.