openclaw - 💡(How to fix) Fix [Bug]: Plugin approval delivers duplicate messages on Telegram — forwarder fallback and native runtime both send when turnSourceChannel is null [1 comments, 2 participants]

Bug Description

When a plugin approval request is created without turnSourceChannel set (or set to null), two identical approval messages are delivered to the Telegram chat — one from the forwarding fallback path and one from the Telegram native approval runtime.

This happens consistently: every plugin approval request produces a duplicate prompt in the Telegram DM.

Root Cause

Two independent delivery paths exist for plugin approvals on Telegram:

These two paths are meant to be mutually exclusive. Path A checks shouldSuppressForwardingFallback before delivering. The suppression logic is configured in telegramNativeApprovalCapability:

requireMatchingTurnSourceChannel: true,

This causes the suppression check (src/plugin-sdk/approval-delivery-helpers.ts) to short-circuit when turnSourceChannel is null:

shouldSuppressForwardingFallback: (input) => {
    // ...
    if (params.requireMatchingTurnSourceChannel) {  // true for Telegram
        const turnSourceChannel = normalizeMessageChannel(
            input.request.request.turnSourceChannel,  // null → undefined
        );
        if (turnSourceChannel !== params.channel) {   // undefined !== "telegram" → true
            return false;  // ❌ Suppression FAILS immediately
        }
    }
    // isNativeDeliveryEnabled check — never reached when turnSourceChannel is null
}

Meanwhile, Path B (native runtime) has different logic in matchesTelegramRequestAccount:

function matchesTelegramRequestAccount(params) {
    const turnSourceChannel = normalizeLowercaseStringOrEmpty(
      params.request.request.turnSourceChannel
    );
    // When turnSourceChannel is null → "" (falsy)
    
    if (turnSourceChannel && turnSourceChannel !== "telegram" && !boundAccountId) {
        // Skipped because turnSourceChannel is ""
    }
    
    // Falls through to session binding check:
    return !boundAccountId || !params.accountId || 
           normalizeAccountId(boundAccountId) === normalizeAccountId(params.accountId);
    // With valid sessionKey, boundAccountId resolves from session entry → matches → handles
}

Result: When turnSourceChannel is null:

• Path A: does NOT suppress → delivers message ✅
• Path B: DOES match via session binding → delivers message ✅
• User receives 2 identical messages

Why turnSourceChannel can be null

The field is populated by the caller of plugin.approval.request. Currently, before_tool_call hooks do not forward the routing metadata — tracked separately in #74003.

But even after #74003 is fixed, any other code path that calls plugin.approval.request without setting turnSourceChannel would still trigger this duplicate-delivery bug.

Steps to Reproduce

1. Configure Telegram with execApprovals enabled and an approver set
2. Configure approvals.plugin.enabled: true
3. Trigger a plugin approval from a Telegram session
4. Two identical approval prompt messages appear in the Telegram chat

Proposed Fix

In shouldSuppressForwardingFallback, when turnSourceChannel is null/undefined, do not immediately short-circuit. Instead, fall back to the session binding to determine the effective channel:

  if (params.requireMatchingTurnSourceChannel) {
      const turnSourceChannel = normalizeMessageChannel(
          input.request.request.turnSourceChannel,
      );
-     if (turnSourceChannel !== params.channel) {
+     const effectiveChannel = turnSourceChannel ?? resolveEffectiveChannelFromSession(input);
+     if (effectiveChannel !== params.channel) {
          return false;
      }
  }

Where resolveEffectiveChannelFromSession would look up the session entry from the request's sessionKey and return the session's channel provider.

Alternatively: when turnSourceChannel is null, resolve the account ID first and check isNativeDeliveryEnabled — if native delivery is active, suppress the forwarder fallback.

Affected Files

• src/plugin-sdk/approval-delivery-helpers.ts — shouldSuppressForwardingFallback logic
• extensions/telegram/src/approval-native.ts — telegramNativeApprovalCapability config
• extensions/telegram/src/exec-approvals.ts — matchesTelegramRequestAccount

Environment

• OpenClaw: 2026.4.29
• Channel: Telegram
• OS: Linux

Related

• #74003 — turnSourceChannel not passed in before_tool_call plugin approval flow
• #57339 — Telegram plugin approval handler missing events
• #64977 — Grammy sequentializer deadlock with plugin approvals