fix(signal): add group-level allowlist support via groups config by derekross · Pull Request #4337 · openclaw/openclaw

derekross · 2026-01-30T03:14:48Z

Summary

Add channels.signal.groups.<groupId> config to allow specific Signal groups by ID
Groups listed in this config bypass the sender-level groupAllowFrom check
Matches the pattern used by Telegram and iMessage for group allowlists

Changes

Add SignalGroupConfig type and groups property to Signal config schema
Add SignalGroupSchema to Zod validation
Add resolveChannelGroupPolicy check in Signal event handler
Add tests for group-level allowlist functionality
Update docs to explain groupAllowFrom (senders) vs groups (group IDs)

Usage

{
  channels: {
    signal: {
      groupPolicy: "allowlist",
      groups: {
        "your-signal-group-id": {}  // Allow this specific group
      }
    }
  }
}

Testing

Added unit tests for group-level allowlist
Manually tested on live Signal instance

Greptile Overview

Greptile Summary

This PR adds a per-group allowlist for Signal via channels.signal.groups.<groupId>, updates Signal config types/Zod schema, adds a group allowlist check in the Signal event handler, and documents the difference between sender allowlists (groupAllowFrom) vs group-ID allowlists (groups).

The new behavior plugs into the shared resolveChannelGroupPolicy mechanism (already used by Telegram/iMessage/WhatsApp) so Signal can allow or block groups by ID (including "*" wildcard) before applying sender-level groupAllowFrom gating.

Confidence Score: 3/5

Reasonably safe to merge once the Signal groups schema mismatch is fixed.
Core logic is small and follows existing group-policy patterns, but the current Zod schema likely rejects the documented/expected config shape (groups: { id: {} }), which would break the feature at runtime. Also, command authorization may not align with the new group-level allowlist semantics.
src/config/zod-schema.providers-core.ts; src/signal/monitor/event-handler.ts

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}

Context used:

Context from dashboard - CLAUDE.md (source)
Context from dashboard - AGENTS.md (source)

Signal's groupPolicy: allowlist was checking senders against groupAllowFrom, but users expected to put group IDs there. This adds proper group-level allowlisting via channels.signal.groups.<groupId>, matching the pattern used by Telegram and iMessage. When a group is explicitly listed in the groups config, it bypasses the sender-level groupAllowFrom check, allowing all members of that group to interact with the bot. - Add SignalGroupConfig type and groups property to SignalAccountConfig - Add resolveChannelGroupPolicy check before sender-level gating - Add tests for group-level allowlist functionality - Update docs to clarify groupAllowFrom vs groups config

The TypeScript type was added but the Zod runtime schema was missing, causing config validation to reject the groups key.

derekross · 2026-01-30T18:57:50Z

Just to add that I've actively been using this since last night configured as such and it's been working great in my family chat. So this proof of concept fix actually does work, following the Telegram structure.

greptile-apps

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-03T02:51:31Z

src/config/zod-schema.providers-core.ts

+export const SignalGroupSchema = z
+  .object({
+    requireMention: z.boolean().optional(),
+    tools: ToolPolicySchema,
+    toolsBySender: ToolPolicyBySenderSchema,
+    enabled: z.boolean().optional(),
+    allowFrom: z.array(z.union([z.string(), z.number()])).optional(),
+    systemPrompt: z.string().optional(),
+  })


[P0] SignalGroupSchema makes tools and toolsBySender required, but SignalGroupConfig marks them optional and docs/tests use empty objects (groups: { "id": {} }). With .strict(), {} will fail validation because required keys are missing, so the new channels.signal.groups.<groupId>: {} example won’t work.

A minimal fix is to make these optional (like Telegram): tools: ToolPolicySchema.optional() and toolsBySender: ToolPolicyBySenderSchema.optional() (and keep allowFrom/enabled/etc. optional as they already are).

Prompt To Fix With AI

This is a comment left during a code review. Path: src/config/zod-schema.providers-core.ts Line: 61:69 Comment: [P0] `SignalGroupSchema` makes `tools` and `toolsBySender` required, but `SignalGroupConfig` marks them optional and docs/tests use empty objects (`groups: { "id": {} }`). With `.strict()`, `{}` will fail validation because required keys are missing, so the new `channels.signal.groups.<groupId>: {}` example won’t work. A minimal fix is to make these optional (like Telegram): `tools: ToolPolicySchema.optional()` and `toolsBySender: ToolPolicyBySenderSchema.optional()` (and keep `allowFrom`/`enabled`/etc. optional as they already are). How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-03T02:52:37Z

Additional Comments (1)

src/signal/monitor/event-handler.ts
[P1] Group-level allowlisting is checked for message delivery, but commandGate still uses effectiveGroupAllow (sender allowlist) and ignores channels.signal.groups. That means a group explicitly allowed via groups can send normal messages, but control commands may still be blocked (since groupAllowedForCommands is based on sender allowlist).

If the intent is “explicitly allowed groups bypass sender-level allowlist checks”, you may want to incorporate groupExplicitlyAllowed into the authorizers/commandAuthorized path (or document that groups only affects message delivery, not command authorization).

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/signal/monitor/event-handler.ts
Line: 469:482

Comment:
[P1] Group-level allowlisting is checked for message delivery, but `commandGate` still uses `effectiveGroupAllow` (sender allowlist) and ignores `channels.signal.groups`. That means a group explicitly allowed via `groups` can send normal messages, but control commands may still be blocked (since `groupAllowedForCommands` is based on sender allowlist).

If the intent is “explicitly allowed groups bypass sender-level allowlist checks”, you may want to incorporate `groupExplicitlyAllowed` into the `authorizers`/`commandAuthorized` path (or document that `groups` only affects message delivery, not command authorization).

How can I resolve this? If you propose a fix, please make it concise.

steipete · 2026-02-24T05:29:27Z

Closing as AI-assisted stale-fix triage.

Linked issue #4336 ("Signal groupPolicy: allowlist doesn't work with group IDs in groupAllowFrom") is currently closed and was closed on 2026-02-18T04:24:23Z with state reason not_planned.
Given that issue state, this fix PR is no longer needed in the active queue and is being closed as stale.

If the underlying bug is still reproducible on current main, please reopen this PR (or open a new focused fix PR) and reference both #4336 and #4337 for fast re-triage.

derekross · 2026-02-24T14:55:45Z

This issue still exists for Signal and you just merged a similar fix for WhatsApp #24670

Signal was the only channel missing group-level allowlist support. While Telegram, iMessage, WhatsApp, IRC, and BlueBubbles all use resolveChannelGroupPolicy to allow specific groups by ID, Signal only supported sender-level gating via groupAllowFrom. Changes: - Add SignalGroupConfig type with requireMention/tools/toolsBySender - Add SignalGroupSchema to Zod validation - Add groups field to SignalAccountSchemaBase - Wire resolveChannelGroupPolicy into Signal event handler - Groups explicitly allowed via config bypass sender-level checks - Incorporate groupExplicitlyAllowed into command authorization - Update docs with groups config usage and examples Fixes openclaw#25540 Supersedes openclaw#4337

derekross added 2 commits January 29, 2026 21:27

fix(signal): add groups schema to Zod validation

dd705e3

The TypeScript type was added but the Zod runtime schema was missing, causing config validation to reject the groups key.

openclaw-barnacle bot added docs Improvements or additions to documentation channel: signal Channel integration: signal labels Jan 30, 2026

greptile-apps bot reviewed Feb 3, 2026

View reviewed changes

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

steipete closed this Feb 24, 2026

derekross mentioned this pull request Feb 24, 2026

Signal channel missing group-level allowlist support (groups config) #25540

Closed

derekross mentioned this pull request Feb 24, 2026

fix(signal): add group-level allowlist support via groups config #25543

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(signal): add group-level allowlist support via groups config#4337

fix(signal): add group-level allowlist support via groups config#4337
derekross wants to merge 2 commits intoopenclaw:mainfrom
derekross:fix/signal-group-allowlist

derekross commented Jan 30, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

derekross commented Jan 30, 2026

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 3, 2026

Uh oh!

greptile-apps bot commented Feb 3, 2026

Uh oh!

steipete commented Feb 24, 2026

Uh oh!

derekross commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

derekross commented Jan 30, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Usage

Testing

Greptile Overview

Greptile Summary

Confidence Score: 3/5

Uh oh!

derekross commented Jan 30, 2026

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot commented Feb 3, 2026

Uh oh!

steipete commented Feb 24, 2026

Uh oh!

derekross commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

derekross commented Jan 30, 2026 •

edited by greptile-apps bot

Loading