openclaw - 💡(How to fix) Fix Plugin-owned conversation bindings intercept native detach/control commands

Summary

Plugin-owned conversation bindings can intercept native/control commands that are required to inspect or detach the binding itself. In practice, a Telegram DM bound to the Codex app-server plugin routed /codex detach into the bound Codex thread as normal user input instead of letting the OpenClaw command dispatcher handle it.

This creates a self-locking route: the command that should detach the binding cannot reach the command handler because the binding is applied first.

Observed behavior

1. Bind a channel conversation to a plugin-owned session, e.g. Codex app-server via /codex bind.
2. Send plugin/control commands in the same conversation, e.g.:
   • /codex binding
   • /codex detach
   • /codex stop
3. The message is claimed by the plugin-owned conversation binding before native command dispatch.
4. /codex detach is delivered to the bound Codex thread as ordinary user text, so the binding remains attached.

Expected behavior

Authorized native/control commands should have an escape hatch before plugin-owned conversation binding routing.

Suggested order:

1. Receive inbound message.
2. If it is an authorized native/control command, dispatch it through OpenClaw command handling.
3. Otherwise, resolve plugin-owned conversation binding.
4. If a plugin-owned binding exists, send normal text to the owning plugin.
5. Otherwise, continue normal agent dispatch.

Why this matters

Plugin-owned binding priority is useful for normal conversational steering (continue, run tests, etc.), but control commands that manage the binding must not be trapped behind the binding they are supposed to inspect or remove.

Without this, users may need to manually edit binding state files to recover from a stale or unwanted plugin binding.

Local confirmation

In a local OpenClaw v2026.5.19 deployment:

• Telegram direct conversation had a runtime binding record with:
  • targetSessionKey: plugin-binding:codex:...
  • metadata.pluginBindingOwner: plugin
  • metadata.pluginId: codex
  • metadata.detachHint: /codex detach
• /codex detach was routed into the Codex-bound conversation instead of detaching.
• Manually clearing the Telegram thread binding restored normal command handling.
• A local hotfix that lets authorized native/plugin command prefixes bypass plugin-owned binding dispatch made /codex binding, /codex bind, and /codex detach work again.

Suggested fix direction

Implement a general command escape hatch before plugin-owned binding inbound claim routing. This should not be Codex-specific; it should apply to authorized native/control/plugin commands whose command prefix belongs to OpenClaw or the owning plugin.

Potential regression test:

• Given an active plugin-owned conversation binding for pluginId: codex with detachHint: /codex detach
• When an authorized user sends /codex detach
• Then the owning plugin inbound claim hook is not invoked for normal bound text delivery
• And the message falls through to native command dispatch

Normal non-command text in the same bound conversation should still route to the owning plugin.