OpenClaw Fences Plugin Channel Sends to the Active Turn

OpenClaw merged a security-boundary repair for plugin message delivery on August 21, 2026 (PR #127098). External plugin tools previously fell back to the process-wide registry on a request-scoped registry miss. That fallback made channel delivery work, but it also handed tool code the raw outbound adapter — the power to choose destinations, accounts, threads, and media roots the host never selected.

The merged change keeps request-scoped registry misses denied and introduces delivery.send({ text, mediaUrl }) as an optional Plugin SDK capability bound to the active host-selected channel, target, account, thread, agent/run/session identity, media policy, active registry generation, and the current turn. Route and policy facts are snapshotted before plugin factory code receives its context, so factory-side mutation cannot retarget an authorized send. Authority is revoked at turn closure.

What actually changed

• Registry fallback removed. A missing entry in the request-scoped registry is now denied instead of silently escalating to process scope.
• A narrow capability replaces raw adapter access. The new helper exposes text/media sending only; destination selection stays host-owned.
• Snapshotted authority facts. The route, account, thread, media policy, registry generation, sender-scoped local-media grant, and turn lifetime are captured before untrusted factory code runs.
• Live-only sends. Current-turn sends never create durable queue entries that recovery could replay after revocation.
• Gateway-owned channels fenced. They do not receive the process-local helper at all, pending a server-verifiable authority and media-policy contract.

Why this matters operationally

Before this merge, a compromised or buggy plugin tool could direct messages to arbitrary Telegram accounts or write media outside its intended workspace while still passing a functional test suite — the delivery worked; only the authority was wrong. After the merge, a retained reference to the send capability fails closed once the turn closes or the registry generation advances.

Interpretation: this is a least-privilege repair, not a behavior regression hunt. The maintainer decision recorded in the PR explicitly declines compatibility paths that would let older caller-controlled routing survive. Operators running third-party plugins should expect stricter behavior rather than silent retargeting.

Operator checklist

1. Inventory every third-party plugin whose tools send channel messages, and re-test each against a current main build before your next deploy.
2. Expect plugins that relied on raw adapter access to fail loudly now. That failure is the boundary working; treat silent success with suspicion instead.
3. If you maintain such a plugin, migrate to toolContext.delivery.send and accept the current-turn-only lifetime. Durable queue custody remains a core-owned path.
4. Re-run your integration proofs after upgrading: a pre-fix green suite proves nothing about post-fix authority semantics.
5. Watch for follow-up work on Gateway-owned channels; they remain fenced until the upstream server-verifiable contract lands.

What upstream validated

The PR’s evidence list is unusually thorough: ten targeted regressions each demonstrated a specific pre-fix failure (capability gaps, revocation races, hostile factories, config mutation widening filesystem roots, replayable ephemeral sends), followed by 508 passing tests across ten files, full typecheck and SDK-surface verification of all 146 public subpaths, exact-head CI, and a live end-to-end Telegram proof in which a real user received the expected media and text while an eight-second delayed call after turn closure was rejected without any stale send reaching Telegram.

These are upstream-reported results reviewed against the official merged record; OpenClaw Academy did not independently execute the proof suite.

Bottom line

If you run plugins in production, upgrade on your normal cadence but pull this change forward: it closes a genuine privilege escalation path from plugin tool code to arbitrary outbound messaging, and it does so without adding configuration surface. The safe posture is to assume any pre-merge plugin delivery behavior was over-privileged until proven otherwise.