OpenClaw merged a Discord transcript ownership fix today that matters most for operators running more than one Discord bot account in the same deployment. The change landed in PR #118579, titled "fix(discord): bind transcript capture to source account [AI]."
The issue was narrow but important: Discord voice transcript capture could honor a model-provided bot account instead of the account that actually received the active turn. In a multi-account setup, that meant one bot could route a capture through another bot's voice manager.
That is a classic agent-boundary problem. The transcript content may look like ordinary session context, but the authority to start, persist, and later manage that capture comes from a specific channel account.
What Changed
The merged PR carries the Discord voice manager's account into the agent-run context and adds a focused transcript-provider ownership contract:
accountOwnership.channelIdaccountOwnership.resolveAccountId
For same-channel captures, OpenClaw now binds capture to the trusted inbound account and ignores a model-selected accountId on that path. For channel-less or configured captures, the provider must resolve ownership before persistence.
The fallback rules are explicit. An explicit capable account wins. If there is only one capable account, Discord can use it. A capable configured default or canonical default can also be used. Remaining multi-account ambiguity is rejected rather than guessed.
Why It Matters
Voice transcripts are durable session material. If the wrong bot account owns the capture, later lifecycle actions can be mis-associated with a different credential boundary.
This fix stores the validated owner channel and account when the transcript session is created. Later lifecycle actions can enforce the same ownership boundary instead of reconstructing it from incomplete context.
The PR also excludes Discord accounts whose credentials are unavailable in the active runtime, returns provider-resolution failures with bounded account identifiers, and keeps historical rows with incomplete ownership metadata on a local recovery path rather than inferring provenance.
Operator Impact
For ordinary single-bot Discord setups, this should be mostly invisible. The default path is now better specified, not more complicated.
For multi-account deployments, this is a real hardening step:
- Discord-originated transcript capture stays on the bot account that received the turn.
- Ambiguous channel-less capture requires a clear capable account.
- Historical sessions without complete ownership are not silently rewritten.
- Auto-start shutdown is qualified by the exact process-owned capture, so a reused session id cannot stop a replacement capture.
The maintainer decision in the PR accepts the new public openclaw/plugin-sdk/transcripts ownership contract and draws the owner boundary cleanly: core owns trusted-account binding and lifecycle enforcement, while Discord owns capability and canonical-account resolution.
That is the right shape for channel security work. The model can request actions, but the runtime has to preserve the account that granted authority in the first place.
Source: OpenClaw PR #118579