OpenClaw merged a high-priority Gateway security fix tonight: PR #126424 keeps conversation delivery inside the active agent's configured channel bindings.
The bug mattered most for multi-agent installs. When operators used conversation tools, an agent could discover or deliver to an external conversation through a channel route owned by a different agent. That is the kind of boundary error that can turn an otherwise useful helper into a cross-account messaging risk.
The fix is broad because the boundary is broad. OpenClaw now checks ownership when conversation references are admitted and again when they are consumed. The same owner rule applies to directory discovery, stored conversation-list results, sends, turns, session binding, completed-operation replay, durable queue attempts, and recovery.
What Changed
The PR adds a canonical route-owner evaluation layer for conversation delivery. Instead of trusting a stored conversation reference on its own, OpenClaw records bounded route facts that can be replayed later: the route peer, team or guild context, thread parent, and member roles.
Different providers expose those facts differently, so the implementation includes provider-aware handling for Discord, Slack, Telegram, Matrix, Mattermost, Feishu, and iMessage. Slack, Discord, Telegram, and Matrix use channel-owned read-only resolvers when the generic binding store cannot reproduce their configured or runtime binding precedence. Mattermost directory discovery remains scoped to the requested account.
The session-conversation association also gains a same-version SQLite column for route facts. A current-writer envelope and update trigger invalidate stale preserved bytes from older writers, even if the association timestamp itself does not move.
In practical terms, OpenClaw is making the route proof travel with the conversation reference instead of assuming that a previously valid reference is still safe.
Why Operators Should Care
OpenClaw's conversation tools are powerful because agents can list conversations, send messages, and continue turns across connected channels. That power depends on strict account ownership.
The merged fix protects several failure modes:
- Sibling-account discovery through a route owned by another agent.
- Persisted foreign conversation rows being consumed later.
- Stale binding replay after route reassignment or deletion.
- Durable queue recovery retrying work against a route the requesting agent no longer owns.
The user impact section is direct: conversations_list, conversations_send, and conversations_turn now stay within the configured account, peer, contextual route, and active conversation binding. Reassigned or deleted routes are rejected before stored results or completed-operation replies are returned.
That last piece is especially important for unattended agents. A boundary check that only works during the first happy-path send is not enough. Recovery paths have to prove the same ownership again.
Validation
The evidence for PR #126424 is unusually extensive, which fits the size of the boundary. The PR reports focused ownership, registry, send, turn, session-commit, queue-attempt, recovery, and provider suites passing across Discord, Slack, Telegram, Matrix, Mattermost, Feishu, and iMessage.
The core and extension typecheck commands passed, along with typed lint, docs MDX validation, the SQLite sessions schema check, formatting, and git diff --check. A clean-machine Testbox proof also verified that non-owner delivery was blocked while owner delivery stayed allowed.
The judged production diff is large, but the scope is clear: a canonical owner evaluator, bounded route provenance, channel-owned resolver seams, and durable-attempt enforcement.
Bottom Line
This is a security-boundary fix more than a visible feature. Most users should not notice anything except fewer impossible routing states.
For teams running multiple OpenClaw agents against shared Slack, Discord, Telegram, Matrix, or Mattermost environments, PR #126424 tightens one of the most important rules: an agent can only act through the conversation routes it actually owns.