openclaw - 💡(How to fix) Fix [Feature]: Signal channel: add live tool-call progress (edit-free pattern) [4 comments, 2 participants]

Summary

Add live tool-call progress visibility to the Signal channel using an edit-free send-and-delete pattern, closing the silence gap that affects all tool-heavy agent turns on Signal.

Problem to solve

On Telegram, users see live tool-call progress during long agent turns (commands running, patches applied, plans updated) via edits to a single "Working…" preview message. On Signal, the same agent is silent until the final reply arrives — sometimes minutes later — with no indication it is alive or making progress.

The gap is structural. previewToolProgressEnabled in pipeline.runtime is gated on two conjuncts:

const previewToolProgressEnabled = Boolean(draftStream) &&
  resolveChannelStreamingPreviewToolProgress(account.config);

The config flag is not the problem. The problem is draftStream: it requires an editable-message primitive that Signal's protocol does not have. signal-cli exposes no edit RPC. The gate short-circuits to false for Signal in every case, making the entire pushPreviewToolProgress code path a no-op. This is a protocol-level constraint, not an extension oversight.

Proposed solution

An edit-free progress pattern that delivers the same user-facing value without requiring a message-edit API:

1. Send each progress event as its own Signal message.
2. Capture the timestamp returned by signal-cli's send RPC.
3. When the real reply is queued (onBlockReplyQueued), bulk-delete all tracked messages via signal-cli's remoteDelete JSON-RPC method.

For the user, progress appears during the turn and scaffolding disappears when the reply lands — approaching Telegram's visual effect. The trade-off is multiple notifications instead of in-place edits, but that is acceptable compared to total silence.

Two implementation paths:

• Option A (channel-side opt-in): Add the pattern as a Signal extension feature gated behind channels.signal.toolProgress: "on". Self-contained; no shared pipeline changes. A deleteMessageSignal helper (wrapping signalRpcRequest("remoteDelete", ...)) plus six replyOptions callbacks injected in the Signal monitor's runDispatch are the only new surfaces. Shippable in days.

• Option B (pipeline abstraction): Refactor draftStream to support an "edit mode" (current) and a "tombstone mode" (send + bulk-delete). Channels declare supportsMessageEdit: boolean; the pipeline picks the right implementation. More invasive but benefits any future edit-free protocol (SMS gateways, Matrix without edits). Quarter-scale effort.

A working implementation has been validated against signal-cli's remoteDelete JSON-RPC method and OpenClaw 2026.5.2. Full proposal with reference implementation available (see Additional information).

Alternatives considered

• Enable blockStreaming on Signal: Setting channels.signal.blockStreaming = true fixes assistant-text streaming (final reply arrives in chunks) but does not address tool-call visibility — the draftStream gate is upstream of streaming chunking.
• Suppress the gap silently: The current behavior. Unacceptable for tool-heavy workflows; makes the agent feel broken or stuck.

Impact

Affected: All Signal channel users who trigger tool-heavy agent turns (coding sessions, multi-step research, anything using bash/browser/patch tools) Severity: High for affected workflows — the agent appears unresponsive for the full duration of long turns Frequency: Every turn that involves tool calls on Signal Consequence: Users lose trust in the agent, migrate to Telegram for real work, or stop using tool-heavy tasks entirely — directly undermining OpenClaw's "your AI in the app you use" value proposition for privacy-focused users who chose Signal

Evidence/examples

Validated against: OpenClaw 2026.5.2 (8b2a6e5), signal-cli installed at /usr/local/bin/signal-cli. Bundle files patched: send-CfzfoBbG.js, monitor-BYoaNI4k.js. Gateway started clean with no load errors post-patch.

Full proposal document (TL;DR, root cause, complete reference implementation, edge cases, validation traces, idempotent reapply script): see attachment in Additional information.

Additional information

The pipeline already accommodates channel-side injection: the Signal monitor builds replyOptions before dispatchInboundMessage and can substitute its own on* callbacks without any shared-code changes. The onBlockReplyQueued hook plus a finally block on dispatch covers all turn outcomes (success, error, no-reply turns). Progress messages are capped at 200 chars in the reference implementation. A channels.signal.toolProgress: "on" | "off" config knob is recommended to let users manage notification noise.

Full proposal with reference implementation, edge-case analysis, and idempotent patch script available on request (authored from a working production patch against OpenClaw 2026.5.2).

openclaw_signal_tool_progress_proposal.docx

Signal Show Tool Calling Custom Patch.zip