Problem

When a user sends any prompt to the Telegram bot — even the simplest one with no tools and no deep reasoning — the status reaction sequence ends on the error emoji (😱 by default) and persists, instead of transitioning to done (👍). The user receives the correct reply text; this is purely a reaction-indicator issue.

Observed sequence

For prompt was ist 2026 geteilt durch 11? (pure inference, no tools):

1. 👀 (ack / queued) — appears instantly
2. 🤔 (thinking) — during reasoning
3. [final text reply delivered to the user: 184, correct]
4. 😱 (error) — appears after the text arrived
5. 😱 persists (without removeAckAfterReply) or clears after errorHoldMs (with removeAckAfterReply: true — though see caveat at bottom)

Expected: step 4 should be 👍 (done).

Environment

• OpenClaw 2026.4.14 (arm64 Linux, Raspberry Pi 5, Node 22.22.1)
• Default Telegram account (DM with bot, no topics)
• Model: openai-codex/gpt-5.4 via Codex OAuth (ChatGPT Plus subscription)
• messages.statusReactions.enabled: true (using default emojis — all Telegram-whitelisted)
• messages.ackReaction: "👀", messages.ackReactionScope: "all"
• channels.telegram.streaming.mode: "block" (also reproduces with "partial" and "off")

Reproduction is deterministic — fires on every turn, not intermittent.

Captured evidence (debug-level run)

Captured a turn at --log-level debug for the prompt above (20:20 CEST, message_id=4410). Relevant log lines:

20:20:32.140 [agent/embedded] embedded run start: runId=10906df2-... provider=openai-codex model=gpt-5.4 thinking=medium messageChannel=telegram
20:20:33.148 [agent/embedded] [context-diag] pre-prompt: messages=82 promptChars=318
20:20:39.231 [diagnostic] session state: prev=processing new=idle reason="run_completed" queueDepth=0
20:20:39.520 [diagnostic] lane task done: lane=session:agent:main:telegram:direct:7169013046 durationMs=9261 active=0 queued=0
20:20:40.197 [gateway/channels/telegram] telegram sendMessage ok chat=7169013046 message=4410
20:20:40.199 telegram ingress: chatId=7169013046 dispatchCompleteMs=12292 buffer=inbound-debounce

Key observations:

• Run completed cleanly: reason="run_completed", active=0 queued=0, durationMs=9261 — not aborted, not timed out
• Message delivered successfully: telegram sendMessage ok on message=4410
• No error log lines during this turn (no dispatch failed, no throw, no timeout)
• Yet the user observed 😱 as the final reaction, which can only come from setError() — meaning !hasFinalResponse was truthy at the finalize check in bot-BwMz6R6-.js:5086

This is the smoking gun: a successful, non-aborted, clean run with confirmed delivery still ends on setError().

Root-cause hypothesis

In extensions/telegram/src/bot/*.ts (compiled to dist/bot-BwMz6R6-.js:5075-5130), the reaction-finalize logic is:

const deliverySummary = deliveryState.snapshot();
if (dispatchError || !deliverySummary.delivered && (...skipped/failed...)) {
  // Send fallback "Something went wrong" text
  sentFallback = (await deliverReplies({
    replies: [{ text: fallbackText }],
    silent: silentErrorReplies && (dispatchError != null || hadErrorReplyFailureOrSkip),
    ...
  })).delivered;
}
const hasFinalResponse = queuedFinal || sentFallback;

if (statusReactionController && !hasFinalResponse)
  Promise.resolve(statusReactionController.setError())...  // ← sets 😱

if (!hasFinalResponse) {
  clearGroupHistory();
  return;
}

// ... auto-topic-label code ...

if (statusReactionController)
  Promise.resolve(statusReactionController.setDone())...  // ← sets 👍

The intent is correct: setError only when no final response was delivered. But in practice it ends up calling setError even when the user received the reply. Likely candidate paths:

Hypothesis A — queuedFinal never flips to true on streamed/block deliveries The deliver callback in the dispatcher (around line 4885) only sets queuedFinal = true inside the shouldSuppressLocalTelegramExecApprovalPrompt branch. The "normal" flow to set it is via the return value of dispatchReplyWithBufferedBlockDispatcher (line 4877: ({queuedFinal} = await telegramDeps.dispatchReplyWithBufferedBlockDispatcher(...))). If the dispatcher returns queuedFinal: false for deliveries where only preview-updates were sent and no explicit "final" segment was marked, hasFinalResponse collapses to sentFallback.

Hypothesis B — silent fallback fires unnecessarily If dispatchError is truthy (maybe set transiently by a rate-limit retry or hadErrorReplyFailureOrSkip flipping on a preview-edit race), the fallback path runs. The fallback message is silent: true when silentErrorReplies is on, and might be suppressed or skipped. In that case sentFallback = false, and combined with queuedFinal = false, hasFinalResponse = false → setError.

Hypothesis C — hadErrorReplyFailureOrSkip triggered by a non-critical payload flag Line 4884: if (payload.isError === true) hadErrorReplyFailureOrSkip = true; — any streamed payload with isError: true (even a transient-recoverable one, or a reasoning-lane marker) sets the flag for the whole turn.

Diagnostic I would add

Add a consolidated debug log line around bot-BwMz6R6-.js:5085 (source: extensions/telegram/src/bot/*.ts):

logVerbose(`telegram: reaction finalize: queuedFinal=${queuedFinal} sentFallback=${sentFallback} dispatchError=${Boolean(dispatchError)} deliverySummary=${JSON.stringify(deliverySummary)} hadErrorReplyFailureOrSkip=${hadErrorReplyFailureOrSkip}`);

Right now those four flags aren't logged together anywhere, so even at debug level the root cause isn't directly visible. With this line, one debug-run on a trivial prompt decisively pins down which hypothesis holds.

Proposed fix (pending root-cause confirmation)

Depending on which hypothesis the debug log confirms:

• If Hypothesis A: ensure queuedFinal = true is set in the main streaming/block dispatch path whenever a non-empty answer-lane segment is delivered and confirmed by deliverLaneText to have reached the user.
• If Hypothesis B: decouple dispatchError from the fallback decision — only send fallback if !deliverySummary.delivered, not on dispatchError alone.
• If Hypothesis C: scope hadErrorReplyFailureOrSkip per-lane, so a reasoning-lane error marker doesn't poison the final answer-lane success.

Test Plan

1. Run trivial prompt (2+2 or similar) at --log-level debug. Observe logged flag state at finalize.
2. Run tool-heavy prompt (e.g. read some file) same way. Compare.
3. Run prompt in different streaming modes (off, partial, block). Does hypothesis A hold per-mode?
4. After fix: assert that on a successful trivial turn, queuedFinal=true, hasFinalResponse=true, setDone() is called, setError() is NOT called.

Workaround for affected users

Three options:

1. Accept and ignore — the error emoji is purely cosmetic, delivery works.
2. Override the error emoji to a neutral/positive symbol (e.g. 👍 or 🤝). All turns will then end with the same emoji regardless of setError vs setDone, at the cost of losing visual distinction for genuinely failed turns:

   { messages: { statusReactions: { enabled: true, emojis: { error: "👍" } } } }

3. Disable status reactions — messages.statusReactions.enabled: false. Keeps the raw ackReaction but no in-turn transitions.

Related observations

• Zero editMessageText calls observed across a full day of operation with the default Telegram bot using openai-codex/gpt-5.4 (Codex OAuth). 62+ sendMessage ok entries vs 0 editMessageText entries. Streaming config (mode: partial|block) is accepted by the schema but effectively never triggers preview-editing. Hypothesis: Codex OAuth provider does not emit token-by-token stream deltas to the channel bridge, so the Telegram preview-edit path (bot-BwMz6R6-.js:417-420) is never exercised. Either (a) Codex OAuth uses a non-streaming response shape for this model, or (b) the gateway streaming-hook → channel-preview wiring has a bug in this provider path. Possibly a separate issue; flagging here because it's the same bot + same turn as the main bug.

• removeAckAfterReply: true has no effect in the Telegram path when statusReactionController is active. In bot-BwMz6R6-.js:5125-5130, the removeAckReactionAfterReply({... removeAfterReply: removeAckAfterReply ...}) call sits in an else branch that only executes when statusReactionController is null. When status reactions are enabled (the common case), the final emoji from setDone/setError is never explicitly cleared. This is related to the main bug because it means the error emoji persists instead of auto-clearing after errorHoldMs. Could fold into this issue or keep as separate.

• active-memory plugin times out consistently at its configured timeoutMs: 15000 returning summaryChars=0. Out of scope here; could warrant its own issue.

Metadata

• Observed 2026-04-21
• OpenClaw version: 2026.4.14
• Gateway / systemd service (running under systemd --user)
• Not reproduced on other channels (this user only uses Telegram)

Severity: Low — user-visible inconsistency but no functional impact on message delivery.