OpenClaw merged a Gateway and dashboard permission fix this morning for official external plugins. PR #150309, "fix: allow dashboard reads through official plugins," addresses a mismatch that blocked supported channel reads before provider traffic began.
The concrete example in the PR is Discord. A dashboard conversation could ask for messages from a Discord channel that its configured account was allowed to read. The request worked with bundled Discord, but failed when the verified official plugin was registered externally.
What Was Broken
The host required native channel conversation context, even though the dashboard turn did not have that kind of native channel context. That made externally registered official plugins behave differently from bundled channel support.
The mismatch also affected users whose existing operator.write permission already allowed chat.send and the message tool. Requiring administrator scope for those reads did not line up with the command permissions users already had.
In practice, that meant an authenticated dashboard session could have enough account, session, tool, destination, and action authority, but still get stopped before the provider was ever called.
What Changed
The fix carries a source-bound permission from the authenticated Control UI handshake and external chat admission into local message execution and Gateway routing. That permission remains tied to the original run, agent, session key, and prepared session ID.
OpenClaw then applies the permission only where three things agree:
- The read is eligible for the host
- The adapter opts in
- The registration authority is verified
The PR is careful about replay and borrowing boundaries. Ordinary transport loss does not cancel the original admitted turn, but stopping the run, removing required participation, or retiring caller authority prevents later reads. Internal re-entry, injected input, another run, and background work cannot borrow the permission.
No configuration, public SDK, wire protocol, or persisted-state format changes are introduced.
User Impact
Authenticated dashboard turns can now use supported reads through verified official plugins under their existing permissions. Incognito sessions and fresh messages after reconnect keep their current session rules, and providers that require native requester or workspace context can still enforce those requirements.
For users, the visible difference is that dashboard-driven workflows involving official external plugins should behave more like bundled integrations. A Discord read that the account and session are already allowed to perform should not fail just because the provider is registered externally.
Validation
The proof uses a real Gateway, signed clients, CLI child, generated MCP tool, and registered Discord provider, with synthetic model decisions and provider data. The signed browser flow read channel metadata and messages, created the requested automation, and retained the completed reply after a real reload.
The membership-withdrawal control is also important. After another owner removed the required membership, a fresh send was denied with SESSION_PARTICIPATION_REQUIRED, and the original queued read rejected before another provider request. The contrasting reconnect control completed the original read after socket loss without creating a new turn.
Current-head CI passed after one rerun on the identical checkout, and the exact-head review reported no actionable findings.
This is the kind of permission repair that should feel invisible once it ships. The dashboard asks for an allowed read, the official plugin executes it, and the original session boundary still holds.
Source: OpenClaw PR #150309.