openclaw - 💡(How to fix) Fix [Bug]: Signal typing indicator is sent successfully but official clients do not show it [2 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Summary

OpenClaw's Signal channel calls sendTyping during long agent turns, and signal-cli returns success, but official Signal clients do not show the typing indicator. The agent then appears silent until the final reply arrives.

I traced this below OpenClaw into signal-cli's Turasa/signal-service-java dependency. For 1:1 typing messages, SignalServiceMessageSender.sendTyping(...) sends the typing envelope with online=true. Rebuilding signal-cli with that delivery flag changed to online=false made the official Signal typing bubble appear reliably.

This suggests OpenClaw is correctly requesting typing, but the current signal-cli delivery path for typing is no longer reliable with current Signal service/client behavior.

Steps to reproduce

1. Configure the OpenClaw Signal channel with signal-cli.
2. Start the OpenClaw gateway.
3. Send a prompt from an official Signal mobile or desktop client that causes a long agent turn.
4. Watch the Signal conversation while the agent is thinking.
5. Optionally enable verbose signal-cli logs and observe repeated JSON-RPC sendTyping calls.

Expected behavior

The official Signal client should display the native typing indicator while the agent is running, especially during long tool-heavy turns.

Actual behavior

No typing indicator is displayed. The agent eventually replies normally, but the conversation appears idle during the entire run.

Environment observed

• OpenClaw version: observed after upgrade to 2026.5.18
• signal-cli versions tested: 0.14.3, 0.14.2, 0.13.24
• Signal Android version in logs: 8.10.2
• Official Signal mobile and desktop clients both showed the same missing typing behavior.
• Signal messages themselves were delivered normally.

Evidence

OpenClaw was not the missing link:

• During long agent turns, signal-cli logs showed repeated sendTyping JSON-RPC requests.
• Direct JSON-RPC calls to signal-cli's sendTyping method returned success but still did not display typing in official clients.
• Normal Signal messages sent through the same account and target were visible.
• Rolling signal-cli back through 0.14.2 and 0.13.24 did not restore typing.

A sealed-sender diagnostic did not fix the issue:

• A local diagnostic build forced typing sends without sealed sender.
• signal-cli logs confirmed that diagnostic path ran.
• Official clients still did not display typing.

The working change was in Turasa/signal-service-java:

return sendMessage(
    recipients,
    sealedSenderAccesses,
    message.getTimestamp(),
    envelopeContent,
    false,
    null,
    cancelationSignal,
    null,
    false,
    false
);

The only behavioral change from the shipped code was changing the online argument for 1:1 typing from true to false.

After rebuilding signal-cli 0.14.2 against the patched signal-service-java-2.15.3_unofficial_142 dependency, official Signal clients started showing the expected three-dot typing bubble.

Bytecode inspection of the running patched jar confirmed the online=false argument position:

50: iconst_0
55: iconst_0
56: iconst_0
57: invokevirtual ... sendMessage(...;ZZ)Ljava/util/List;

Suspected root cause

The typing content itself appears valid. The failure appears to be the online-only delivery path used by signal-cli's dependency for 1:1 typing messages.

online=true looks semantically reasonable for ephemeral typing indicators, but with current Signal service/client behavior it can produce a local success while the receiving official client does not show typing. Using online=false still sends a typing envelope; it only changes the delivery path.

This also matches the observed history: typing was previously intermittent and later became consistently absent.

Proposed fix

Preferred upstream fix:

• Patch Turasa/signal-service-java so 1:1 sendTyping(...) uses online=false.
• Then update OpenClaw's signal-cli dependency/runtime once that upstream fix is available.

Minimal source diff shape:

- return sendMessage(recipients, sealedSenderAccesses, message.getTimestamp(), envelopeContent, true, null, cancelationSignal, null, false, false);
+ return sendMessage(recipients, sealedSenderAccesses, message.getTimestamp(), envelopeContent, false, null, cancelationSignal, null, false, false);

Open question:

• Group typing appears to use a nearby group send path with its own online flag. That should be tested separately before changing group behavior.

Impact and severity

This is most visible during long coding/research/tool-heavy turns over Signal. Replies still arrive, but the user gets no liveness signal and the agent appears stuck.

Additional notes

This is separate from Signal tool-call progress previews or send/delete "Working..." message workarounds. OpenClaw's native typing loop is already calling signal-cli; the issue is that signal-cli's current 1:1 typing delivery path does not produce a visible typing indicator in official clients.