Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After installing OpenClaw 2026.5.3-1, the matrix channel receives inbound messages and the agent generates replies normally — but outbound m.room.message events silently disappear before reaching matrix-js-sdk. matrix-js-sdk's own sendEvent of type m.room.message log line never appears for openclaw-driven turns. There are no errors, warnings, or other diagnostics at info, warn, or error level. The agent session JSONL shows the assistant reply was generated cleanly with stopReason: "stop"; it just never reaches the homeserver.

The break is reproducibly inside openclaw's matrix channel wrapper — matrix-js-sdk itself, the access token, the device, and the homeserver have all been verified healthy by direct test (see "Diagnostic evidence" below).

Steps to reproduce

1. Install OpenClaw 2026.5.3-1 as a host npm install with the matrix channel configured against an unencrypted matrix room. Node 24+ runtime.
2. Have a user account post a message in the configured room (e.g. "ping").
3. Observe: the gateway's session JSONL records both the inbound user message and the assistant-generated reply with stopReason: "stop". The reply never appears in the matrix room.
4. Restarting openclaw-gateway does not resolve. Reinstalling the matrix nested deps (matrix-js-sdk, @matrix-org/matrix-sdk-crypto-nodejs, @matrix-org/matrix-sdk-crypto-wasm) does not resolve. Running npm rebuild @matrix-org/matrix-sdk-crypto-nodejs does not resolve.

Expected behavior

Agent-generated replies posted to the configured matrix room within ~seconds of generation, as observed on prior 2026.4.x releases.

Actual behavior

Agent replies generated correctly but silently dropped before reaching matrix-js-sdk. No error or warning at any log level (info / warn / error / file-log / journald).

Diagnostic evidence

1. Inbound bridge healthy. Session JSONL records user message at 2026-05-05T22:13:27.178Z with full matrix metadata (chat_id, message_id, sender). Bridge receives sync events fine.

2. Model + tool loop healthy. Session JSONL records assistant reply at 2026-05-05T22:14:00.518Z with normal stopReason: "stop", expected reply text, ~33s end-to-end model latency.

3. matrix-js-sdk's sendEvent log line is absent for openclaw turns. Grepping /tmp/openclaw/openclaw-2026-05-05.log for sendEvent returns zero hits since gateway start. matrix-js-sdk emits this line on every sendMessage invocation; absence indicates openclaw is not calling it.

4. matrix-js-sdk + same device id + same access token + same nested-deps install sends fine in isolation. Reproducer:

const sdk = require("/path/to/openclaw/node_modules/matrix-js-sdk");
const c = sdk.createClient({
  baseUrl: "http://homeserver:8008",
  accessToken: "<openclaw's access token>",
  userId: "@bot:homeserver",
  deviceId: "<openclaw's device id from storage-meta.json>",
});
await c.startClient({ initialSyncLimit: 1 });
await new Promise((res) => c.once("sync", (s) => s === "PREPARED" && res()));
const r = await c.sendMessage("<room id>", { msgtype: "m.text", body: "test" });
console.log("OK", r.event_id);

Result: SAME-DEVICE SEND OK event_id: $... — HTTP 200 from synapse in ~48ms. Confirms the bridge's matrix-js-sdk install, native binding, access token, device, and homeserver are all functional. The break is in openclaw's wrapper layer.

5. Gateway file log only emits these matrix-related lines all day:

• [matrix] [default] starting provider (http://...) (at startup)
• matrix: logged in as @bot:homeserver (at startup)
• [MatrixClient] Resuming queue after resumed sync (at startup)
• A handful of [MatrixRTCSession ... m.call#ROOM] No membership changes detected entries (call-state polling)
• Couldn't find timeline for thread ID $... warnings on a separate room (not the affected one)

No sendEvent, no error, no warn from matrix-js-sdk during steady-state operation.

6. Native binding loads cleanly from openclaw cwd: node -e 'require("@matrix-org/matrix-sdk-crypto-nodejs")' returns 8 keys (Attachment, EncryptedAttachment, BackupDecryptionKey, ...). OlmMachine.initialize returns successfully.

7. No E2EE state present — homeserver /keys/query for the bot account returns empty device_keys/master_keys/self_signing_keys/user_signing_keys. Bot operates in unencrypted-room-only mode.

8. Gateway liveness diagnostics show event-loop pressure consistent with #77995's symptom class:

[diagnostic] liveness warning: reasons=event_loop_delay
  eventLoopDelayP99Ms=181.9-243.9 eventLoopDelayMaxMs=2294.3-3231.7
  eventLoopUtilization=0.29-0.32 active=1 waiting=0 queued=1

Magnitude is milder than #77995's report (their P99 went up to 6350ms), but queued=1 is consistently present.

9. Direct synapse send via same access token, bypassing matrix-js-sdk entirely, works: curl -X PUT -H "Authorization: Bearer <token>" .../rooms/.../send/m.room.message/<txn> -d '{"msgtype":"m.text","body":"..."}' returns HTTP 200 with event_id. Confirms synapse, network, ACL, room state are all healthy.

What this rules out

• matrix-js-sdk itself (works in isolation with same install)
• Native binding ABI (binding loads, OlmMachine.initialize succeeds; rebuild didn't help)
• Access token / device / E2EE setup (synapse confirms valid device, no E2EE state to be partial about)
• Network, synapse, room ACL (direct PUT works)
• dist/ bundle drift (untouched since prior working state — only node_modules/.package-lock.json was rewritten by an npm install of nested matrix deps)

What's left

The break sits between "openclaw's matrix channel plugin observes the agent-generated reply" and "matrix-js-sdk's sendMessage gets called." That lane is opaque to me at info-level logging.

OpenClaw version

2026.5.3-1

Operating system

Linux (Ubuntu 24.04 / WSL2 host running as a Linux VM), node v24.15.0, npm 11.x.

Install method

npm install -g [email protected], with the npm install --no-save workaround for matrix nested deps as documented.

Related issues

• #77995 — gateway status stalls ~50s on 2026.5.4 / 2026.5.3-1, Discord heartbeat ACK timeouts. Same general regression class (event-loop saturation in 2026.5.x channel runtime); their symptom is timeouts that eventually succeed, ours is silent total drop. Possibly the same root cause expressed differently across channels.
• #77896 — matrix-js-sdk missing after 2026.5.4 host npm update. Different shape (ERR_MODULE_NOT_FOUND — we don't see that), but adjacent matrix-channel-packaging area.
• #77483 (closed) — built-in→external @openclaw/* channel migration without auto-install, likely the architectural ancestor of these regressions.

Workaround

None known. Gateway restarts and nested-deps reinstall do not restore. Going back to 2026.4.x is the only known-good state per #77995's reporter (using 2026.5.2 as their last-known-good).