Bug

When a plugin claims an inbound message via inbound_claim (returning { handled: true }), channel handlers — specifically the Telegram handler — fire a silent-reply fallback (e.g. "No further word from me.") before the plugin's actual async response arrives.

Root cause

In src/auto-reply/reply/dispatch-from-config.ts, the plugin-bound-handled case hardcodes queuedFinal: false:

case "handled": {
  markIdle("plugin_binding_dispatch");
  recordProcessed("completed", { reason: "plugin-bound-handled" });
  return { queuedFinal: false, counts: dispatcher.getQueuedCounts() };
}

The Telegram bot handler uses queuedFinal to decide whether to fire the silent-reply fallback:

if (!queuedFinal && !sentFallback && !dispatchError && !deliverySummary.delivered) {
  // fires "No further word from me." ← spurious
}

Because the plugin responds asynchronously (after the dispatch cycle), deliverySummary.delivered is also false at this point. Both conditions are met, so the silent-reply fires even though the plugin has already claimed the message and will send a response shortly.

Regression

This was introduced in 2026.4.15 when the silent-reply fallback feature was added. In 2026.4.14, the equivalent code path just returned without sending any fallback message, so async plugin handlers worked correctly.

Affected versions

2026.4.15 through 2026.4.21 (latest).

Steps to reproduce

1. Install a plugin that claims inbound messages via inbound_claim and responds asynchronously (e.g. openclaw-codex-app-server)
2. Bind a Telegram conversation to the plugin
3. Send a message — a silent-reply phrase fires immediately, then the plugin's real response arrives seconds later

Expected behaviour

No silent-reply phrase. The plugin claimed the message and will respond; the channel handler should not send a fallback.

Proposed fix

Return queuedFinal: true in the plugin-bound-handled case to signal that a response is committed:

case "handled": {
  markIdle("plugin_binding_dispatch");
  recordProcessed("completed", { reason: "plugin-bound-handled" });
  // Plugin claimed this message and will respond asynchronously.
  // Return queuedFinal: true so channel handlers do not fire a silent-reply
  // fallback before the plugin's async response arrives.
  return { queuedFinal: true, counts: dispatcher.getQueuedCounts() };
}

A PR with this fix is linked below.