Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Signal does not emit lifecycle status reactions when messages.statusReactions.enabled is true because the Signal inbound handler never wires the status reaction controller into dispatch callbacks.

Steps to reproduce

1. Run OpenClaw from upstream main at ca0232ff0ea12fb74081ab17e5b122fb488d6217 with Signal enabled and a config like:

   {
     "messages": {
       "ackReaction": "👀",
       "ackReactionScope": "all",
       "statusReactions": {
         "enabled": true
       }
     },
     "channels": {
       "signal": {
         "dmPolicy": "open",
         "allowFrom": ["*"]
       }
     }
   }

2. Send a Signal DM or allowed Signal group message that triggers an agent run.

3. Observe the inbound message while the agent processes, calls tools, compacts, and finishes.

Expected behavior

Signal should update reactions on the inbound message using the shared status reaction lifecycle, similar to other channels that already wire createStatusReactionController into dispatch callbacks:

• queued / ack reaction when the run is accepted
• thinking during model/reasoning work
• tool/coding/web reaction during tool calls
• compacting during compaction
• done or error at terminal state

Actual behavior

No automatic lifecycle status reaction is sent for Signal inbound messages. Signal has reaction send helpers, but the inbound monitor never creates a status reaction controller and never passes status callbacks to dispatchInboundMessage.

Code evidence from upstream main:

• extensions/signal/src/monitor/event-handler.ts dispatches inbound messages with only disableBlockStreaming and onModelSelected in replyOptions.
• The same Signal tree has sendReactionSignal / removeReactionSignal helpers in extensions/signal/src/send-reactions.ts, so the transport primitive exists.
• Signal tests do not cover messages.statusReactions, createStatusReactionController, or lifecycle callbacks.
• Other channels on main already wire status reactions, for example Telegram, Discord, and Slack use createStatusReactionController / statusReactions.enabled / resolveAckReaction.

OpenClaw version

Upstream main at ca0232ff0ea12fb74081ab17e5b122fb488d6217 (package version in this checkout: 2026.4.25).

Operating system

Linux / Ubuntu 24.04 for code inspection and regression test authoring.

Install method

pnpm dev checkout.

Model

N/A - this is channel lifecycle wiring before/during dispatch, not model-specific.

Provider / routing chain

N/A - this is channel lifecycle wiring before/during dispatch, not provider-specific.

Additional provider/model setup details

N/A.

Logs, screenshots, and evidence

Static evidence from upstream main:

• Signal dispatch path lacks status reaction callbacks in extensions/signal/src/monitor/event-handler.ts.
• git grep -E 'statusReactions|createStatusReactionController|resolveAckReaction|shouldAckReaction' main -- extensions/signal/src/monitor/event-handler.ts finds no status reaction wiring.
• git grep -E 'createStatusReactionController|statusReactions.*enabled|resolveAckReaction' main -- extensions/telegram/src extensions/discord/src extensions/slack/src shows equivalent wiring exists in other channels.

Impact and severity

Affected: Signal users who configure messages.statusReactions.enabled expecting lifecycle reactions.

Severity: Medium UX regression/behavior gap. Signal users get no visual progress signal while other channels can show queued/thinking/tool/done reactions.

Frequency: Always for Signal inbound runs on main, based on the missing wiring in the only Signal inbound dispatch path.

Consequence: Configured Signal status reactions are a no-op; users cannot tell whether a long-running Signal-triggered agent turn is accepted, thinking, using tools, compacting, done, or failed.

Additional information

Related but not identical:

• Signal: Instant ACK Reactions #20393 covered Signal instant ack reactions, not the full lifecycle messages.statusReactions.enabled flow.
• [Feature]: Keep configured presence alive until run complete + dispatch idle #65919 tracks a broader presence-lifetime concern across channels.