Summary

Matrix read receipts are sent only after the full message handler pipeline completes (access control, room config resolution, auto-reply generation, etc.), causing messages to appear "unread" in Element/other clients while the agent is processing.

Steps to reproduce

1. Configure a Matrix channel
2. Send a message to the agent
3. Observe read receipt timing in Element (or another Matrix client)

Expected behavior

Read receipt should fire immediately when the message arrives from the SDK, before any processing. This is what human Matrix clients do — the message is marked "read" as soon as it's received, regardless of whether a reply has been composed.

Actual behavior

Read receipt is sent in handler.ts at line ~606, deep inside the message processing pipeline. If the agent is busy (queued messages, slow tool calls, etc.), the sender sees their message stuck in "sent" / "delivered" state for potentially minutes, with no indication the agent received it.

Proposed fix

Move the sendReadReceiptMatrix call from the handler to events.ts, wrapping the room.message listener to fire the receipt immediately on message arrival (filtering out self-messages via lazy getUserId resolution). The handler's receipt call becomes a no-op comment.

This is a one-file change with no behavioral side effects — the receipt is fire-and-forget and doesn't affect message processing.

Environment

• OpenClaw: 2026.2.23
• Matrix plugin: @openclaw/matrix 2026.2.22
• OS: macOS 15.4 (arm64)
• Install method: pnpm global

Impact and severity

Low severity, high annoyance. Affects all Matrix users. The UX difference between "instant read receipt" and "delayed read receipt" is significant — it's the difference between feeling like the agent heard you vs. wondering if your message was lost.