Openclaw doesn't get signal group msgs | Friends of the Crustacean 🦞🤝 | Page 1

keen dust Mar 15, 2026, 4:39 AM

#

Anybody have an issue with their openclaw not receiving group messages at all in signal?

"signal-cli group messages not reaching daemon. Account registered as primary today, deviceId=3, isMultiDevice=true. Group ID allowlisted with requireMention=false. DMs work fine. Group messages don't appear in logs at all — never reach gateway level. signal-cli v0.14.1."

Trying to fix so can use the bot in a group signal chat. Thks

terse dewBOT Mar 15, 2026, 4:39 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

wild brookBOT Mar 15, 2026, 4:44 AM

#

For Signal, the gotcha is: DM pairing / DM allowlists don’t automatically make group messages “allowed.” Groups are fail-closed by default, so it’s very common to have “DMs work, groups are totally silent.”

Two things to check/fix:

1) Make sure you’re not allowlisting the group id where OpenClaw expects the sender

On Signal, the group gate is based on who is allowed to trigger inside groups (groupAllowFrom), not “this group id is allowed”.

Try this (temporarily permissive) to prove the pipeline works:

{
channels: {
signal: {
enabled: true,
dmPolicy: "pairing",
groupPolicy: "allowlist",

#

groupAllowFrom: ["*"], // allow any member in groups (for testing)
},
},
}

Then restart the gateway and test again.

Once it works, tighten it to just you, e.g. groupAllowFrom: ["+1555..."] (or uuid:... if your sender shows up as UUID-only).

Docs: https://docs.openclaw.ai/channels/signal and https://docs.openclaw.ai/channels/groups

2) Verify it’s not just being dropped silently (quick triage commands)

Run these and paste the Signal section:

#

openclaw --version
openclaw channels status --probe
openclaw logs --follow

Then send a message in the Signal group while logs --follow is running. If nothing shows up even with groupAllowFrom:["*"], then it’s likely signal-cli daemon isn’t emitting the group events (separate issue) — but in most cases it’s just the group allowlist gating above.

If you paste your current channels.signal { ... } block (redact phone numbers if you want), I can point out the exact mismatch.

keen dust Mar 15, 2026, 4:14 PM

#

If that doesn't work and the signal CLI daemon still isn't reveiveing group signal messages what should i do?

keen dust Mar 15, 2026, 4:53 PM

#

Thoughts?

wild brookBOT Mar 15, 2026, 4:53 PM

#

Main thought: that “group ID allowlisted + requireMention=false” line is a red flag for Signal.

For Signal, OpenClaw’s group gating is (per the current docs) not “allow this group id” — it’s:

channels.signal.groupPolicy (open/allowlist/disabled)
channels.signal.groupAllowFrom (who is allowed to trigger inside groups; E.164 or uuid:..., or "*")

So if you only allowlisted the group id, OpenClaw will still drop every group message as “not allowed”, and it can look like “nothing reaches the gateway”.

Quick “make it talk” test (2 minutes)

Set this temporarily:

{
  channels: {
    signal: {

#

      groupPolicy: "allowlist",
      groupAllowFrom: ["*"],
    },
  },
}

Restart gateway, then send a group message from any member. If it works, tighten groupAllowFrom afterward.

If it still doesn’t work

Then it’s almost certainly signal-cli / account state:

Update signal-cli (0.14.1 is likely stale; Signal breaks older builds a lot).
Confirm the bot account actually sees the group:

#

signal-cli -a +<bot> listGroups

If the group isn’t listed, the bot/device isn’t in it (or hasn’t synced) → relink/re-add.

Paste these and I can be more precise

openclaw --version
openclaw channels status --probe (Signal section)
your channels.signal config block (redact numbers if you want)

keen dust Mar 15, 2026, 4:54 PM

#

───

Signal group messages not reaching signal-cli daemon (DMs work fine)

Setup:

• OpenClaw 2026.3.13
• signal-cli 0.14.1, primary account (not linked device)
• GrapheneOS / Pixel 8
• Signal number is a Mint Mobile eSIM

Problem: DMs to the bot work perfectly. Group messages never arrive at the daemon at all — nothing shows up in the logs, not even a received/dropped event. It's as if the group messages don't exist.

Already tried:

• Correct groupAllowFrom config (set to my phone number UUID)
• Remove + re-add from group
• Safety number verification
• Manual signal-cli receive to force key sync
• register --voice fails with "Account is already registered"

Logs show: signal-cli daemon starts fine, DMs deliver, zero group traffic ever appears.

Is this a known group sender key sync issue with signal-cli 0.14.1? Any known fix short of full account deletion + re-registration?

───

wild brookBOT Mar 15, 2026, 4:57 PM

#

That symptom set (“DMs arrive, but zero group envelopes ever show up in the daemon / even receive”) points away from OpenClaw and toward signal-cli account state or signal-cli refusing to process group messages (often because of identity / sender-key / group-state sync issues).

A few practical things that are worth trying before “delete account + re-register”:

1) Upgrade signal-cli (seriously)

0.14.1 is old enough that it’s in the “might randomly break” zone. Signal server-side changes are brutal to older clients.

After upgrading, run (this is explicitly called out in the signal-cli man page as fixing receive problems):

signal-cli -a +<bot> updateAccount

Then restart the daemon and re-test group traffic.

2) Check whether group messages are arriving but being dropped due to identity trust/decrypt

It’s possible to “receive nothing” at the app level if signal-cli refuses messages due to identity trust issues (DM works because you’ve verified/trusted that one identity; group has many senders).

#

Run a verbose JSON receive for a few minutes while someone posts in the group:

signal-cli -v --output json -a +<bot> receive -t 600

If you see identity / safety-number / decrypt errors in verbose logs, you’ve found the real blocker. For a bot account you can also test with a more permissive trust mode (trade-off: weaker security):

signal-cli -v --output json --trust-new-identities always -a +<bot> receive -t 600

If that suddenly makes group messages appear, the fix is “trust/verify identities of the group senders” (or keep that trust mode for the bot number).

3) Verify the bot actually has the group state

On the gateway host:

#

signal-cli -a +<bot> listGroups

If the group isn’t listed, the bot isn’t really “in” the group from signal-cli’s perspective (even if other clients think it is). In that case, the only reliable fix is usually to get group state to re-sync (upgrade + updateAccount helps), or relink/recreate the account state.

4) The “works in practice” fix: run signal-cli as a linked device, not the primary

This one’s annoying but tends to be the most stable long-term: make a normal phone the primary device for that bot number, then link signal-cli as a secondary device (QR link path). OpenClaw’s Signal docs recommend linking for a reason.

Docs: https://docs.openclaw.ai/channels/signal

If you can paste the output of:

signal-cli --version after upgrading (and whether it’s native vs JVM build),
signal-cli -a +<bot> listGroups (redact ids if you want),
and a snippet from signal-cli -v --output json ... receive when a group message is sent

#Openclaw doesn't get signal group msgs