Connecting OpenClaw to Matrix (with real end-to-end encryption)

The lightest channel setup OpenClaw has: any homeserver, an access token, no webhook, no public URL, and full E2EE support. Setup, encryption upkeep, and the LAN-homeserver trap.

The short answer

Matrix is the lightest serious channel in OpenClaw’s catalog: install the @openclaw/matrix plugin, point it at any homeserver with an access token, restart, invite the bot. No webhook, no public URL, no cloud console: the connection is outbound-only. And it’s the one channel with real end-to-end encryption support: DMs, rooms, threads, media, reactions, polls, and E2EE all work. The cost is E2EE’s operational upkeep (device verification, cross-signing, key housekeeping), plus one trap for self-hosters: LAN homeservers are blocked by default.

Setup

openclaw plugins install @openclaw/matrix

Then configure an account. Any homeserver works: matrix.org, your own Synapse, a hosted one. Token auth is preferred (password login works and caches credentials):

channels: {
  matrix: {
    homeserver: "https://matrix.example.org",
    accessToken: "<token>",
  },
}

Restart the gateway, invite the bot to a room (auto-join is configurable: off, allowlist, or always), and you’re talking. There’s an interactive wizard (openclaw channels add) if you’d rather be walked through it. Because the plugin dials out to the homeserver, your machine exposes nothing, the same pleasant property the Telegram channel has, and the loudest contrast with the webhook-shaped corporate channels.

Encryption: supported, with homework

Turn it on with encryption: true or run openclaw matrix encryption setup, which bootstraps secret storage, cross-signing, and key backup in one go. Encrypted rooms are detected automatically. Even media thumbnails go encrypted without extra config. The upkeep is where Matrix asks more of you than any other channel: verify the agent’s device (openclaw matrix verify device with your recovery key) so other users don’t see scary shields, and expect some housekeeping over time. Old OpenClaw-managed devices can accumulate (there’s a devices prune-stale command for exactly this). None of it is hard; all of it is real. The payoff is meaningful: on most bot platforms the server can read bot messages. An E2EE Matrix room is the exception.

Access control and behavior

Standard OpenClaw gating: DMs pairing-first (openclaw pairing approve matrix <code>), rooms allowlisted by default with per-room mention-requirements. Allowlist entries use real Matrix identifiers: @user:server for people, !roomId:server or #alias:server for rooms. Nice touches: proper thread support (reply-in-thread configurable), per-user or per-room DM session scoping, and inbound voice notes get transcribed when you have an audio model configured.

The traps

Self-hosting on a LAN? The plugin’s SSRF guard refuses private-network homeservers by default: a Synapse at 192.168.x.x won’t connect until you explicitly opt in with the config key whose name starts with dangerously. A sensible default that surprises exactly the people most likely to run Matrix.
Leave message-preview streaming off (the default): live-updating previews cost extra API calls against your homeserver’s rate limits.
Messages chunk at 4,000 characters; media caps at 20MB by default, both configurable.

Who this channel is for

Matrix pairs naturally with the self-hosted temperament: if you already run (or rent) a homeserver because you want your chat under your control, an agent that joins E2EE rooms without exposing a single port is the same philosophy extended. It’s also simply a good default channel: the setup effort sits closer to Telegram than to Teams, with a privacy ceiling none of the others reach.