feat(gateway): WhatsApp group authz + owner detection + reactions (fixes #7269) by sdugoten · Pull Request #53623 · NousResearch/hermes-agent

sdugoten · 2026-06-27T12:33:21Z

What & why

Fixes #7269 — in a WhatsApp group with require_mention: true, the bot only replies to senders already in WHATSAPP_ALLOWED_USERS; a normal group member who @mentions it is rejected. This brings WhatsApp to Telegram parity: any allowed-group member can talk to the bot, the bot knows which sender is the owner, and messages get 👀→✅ progress reactions — without changing the [name] sender prefix or any other platform's behavior.

The changes

1. Group-member authorization — gateway/authz_mixin.py
Adds WHATSAPP / WHATSAPP_CLOUD → WHATSAPP_GROUP_ALLOWED_USERS to the group-allowlist dict, so WHATSAPP_GROUP_ALLOWED_USERS=* authorizes the whole group exactly like TELEGRAM_GROUP_ALLOWED_CHATS. Direct fix for the issue.

2. Owner detection (both transports) — whatsapp_common.py, whatsapp_cloud.py, plugins/platforms/whatsapp/adapter.py
_set_owner_flag() resolves the group sender's LID to the owner via WHATSAPP_ALLOWED_USERS + the on-disk alias map and sets source.is_owner at intake. Called by both the Cloud adapter and the Baileys plugin adapter. A generic _is_owner() fallback covers the DM path; wildcard * is never an owner.

3. Surfacing the owner — gated, additive, no [name] change — gateway/run.py, gateway/session.py

single-user sessions → an **Owner:** yes/no context line;
cache-shared group sessions → keep [name] and prepend an owner-only [SYSTEM: sender NAME is the owner] marker (guests byte-identical to upstream).

Both outputs are gated to WHATSAPP/WHATSAPP_CLOUD, so Telegram/Slack/Discord/etc. are completely unaffected. The gate is a source.platform in {...} set with a comment inviting other platforms to opt in once their adapter sets source.is_owner.

4. Reaction progress indicators — plugins/platforms/whatsapp/adapter.py, scripts/whatsapp-bridge/bridge.js
Overrides the base on_processing_start / on_processing_complete hooks (which the gateway already calls for every platform): 👀 while processing, ✅/❌ when done, and clears the 👀 on cancel so it never lingers (parity with the Telegram adapter). New bridge endpoint POST /send-reaction (Baileys react; empty emoji removes). Disable with WHATSAPP_REACTIONS=false.

Scope notes

The owner plumbing (_is_owner, the run.py marker, session.py is_owner) is shared with the Signal PR feat(gateway): bring Signal groups to Telegram parity (authz, mention, owner detection) #53348; whichever merges first, the other's shared hunks become no-ops, and the gate set merges to {SIGNAL, WHATSAPP, WHATSAPP_CLOUD}.
Owner-surfacing changes are gated, so no other platform's group/DM output changes.

How to test

.env: WHATSAPP_GROUP_ALLOWED_USERS=*, WHATSAPP_ALLOWED_USERS=<owner phone/LID> (concrete, not *).
config.yaml: whatsapp: { require_mention: true }.

A non-owner member @mentions the bot → it replies (previously rejected). (1)
The owner's messages arrive marked [SYSTEM: sender … is the owner]; everyone else plain [name]. (2,3)
Send a message → 👀 appears while processing, flips to ✅ on success. (4)

Platforms tested

macOS (Apple Silicon), Baileys bridge (bot mode). Owner-surfacing + reactions are additive/gated; non-WhatsApp adapters unaffected.

Fixes the issue where a WhatsApp group member is rejected under require_mention unless they're in WHATSAPP_ALLOWED_USERS, and brings WhatsApp to Telegram parity. - authz_mixin: WHATSAPP / WHATSAPP_CLOUD group-allowlist entry so WHATSAPP_GROUP_ALLOWED_USERS authorizes the group; generic _is_owner() fallback. - whatsapp_common: _set_owner_flag() resolves the group sender (LID) to the owner via WHATSAPP_ALLOWED_USERS; called at intake by BOTH the Cloud adapter and the Baileys plugin adapter (plugins/platforms/whatsapp/adapter.py). - run.py/session.py: owner surfaced WITHOUT changing the [name] prefix — a **Owner:** context line + an additive [SYSTEM: sender NAME is the owner] marker. Gated to WHATSAPP/WHATSAPP_CLOUD so other platforms stay byte-identical (other platforms can opt in by adding themselves to the set). - plugin adapter + bridge.js: reaction progress indicators — 👀 while processing, ✅/❌ when done, cleared on cancel (parity with Telegram); WHATSAPP_REACTIONS=false to disable. New bridge POST /send-reaction.

teknium1

Thanks for tackling WhatsApp group parity; the underlying intake path still needs work on current main.

Problems

scripts/whatsapp-bridge/bridge.js:637 drops a non-self sender not in WHATSAPP_ALLOWED_USERS before the Python gateway sees it, including a group member. This PR does not change that gate, so its gateway allowlist cannot fix the stated Baileys configuration.
WhatsApp Cloud currently drops group-shaped inbound payloads at gateway/platforms/whatsapp_cloud.py:1891-1899; the proposed Cloud authz/owner wiring cannot provide the claimed group behavior.
WHATSAPP_REACTIONS is a new user-facing non-secret environment setting. AGENTS.md requires behavioral settings to use config.yaml.
No regression test covers the bridge → adapter → gateway authorization path; existing group-policy coverage is adapter-level (tests/gateway/test_whatsapp_group_gating.py:262-272).

Suggested changes

Rework the Baileys intake gate around the existing whatsapp.group_policy / group_allow_from model, then add an end-to-end regression for an unlisted member mentioning the bot in an allowlisted group.
Scope the patch to Baileys until Cloud group intake is implemented, and place reaction configuration in config.yaml.

Automated hermes-sweeper review.

teknium1 · 2026-07-15T05:42:06Z

                Platform.TELEGRAM: "TELEGRAM_GROUP_ALLOWED_CHATS",
                Platform.QQBOT: "QQ_GROUP_ALLOWED_USERS",
+                Platform.WHATSAPP: "WHATSAPP_GROUP_ALLOWED_USERS",
+                Platform.WHATSAPP_CLOUD: "WHATSAPP_GROUP_ALLOWED_USERS",


WHATSAPP_CLOUD cannot use this group allowlist yet: current gateway/platforms/whatsapp_cloud.py:1891-1899 drops every group-shaped payload before gateway authz. Please omit the Cloud entry or implement Cloud group intake first.

…ope, bridge group gate, reactions config, e2e test Four items from the hermes-sweeper review: 1. bridge.js group gate (scripts/whatsapp-bridge/bridge.js) The WHATSAPP_ALLOWED_USERS gate dropped non-self, non-allowlisted senders — including group members — before the Python gateway saw them, so a concrete allowlist (required for owner detection) meant only the owner could trigger the bot in a group. Gate is now DM-only; group messages pass through to the gateway, which authorizes via the documented whatsapp.group_policy / group_allow_from model and applies require_mention. 2. Scope to Baileys (gateway/platforms/whatsapp_cloud.py) WhatsApp Cloud drops group-shaped inbound earlier in the handler, so wiring owner detection there was dead code. Removed; documented to re-add once Cloud group intake exists. Baileys owner detection is unchanged. 3. Reactions setting -> config.yaml (plugins/platforms/whatsapp/adapter.py) WHATSAPP_REACTIONS is a behavioral setting; AGENTS.md requires config.yaml. Now read from whatsapp.reactions (legacy env kept as a fallback). 4. Regression test (tests/gateway/test_whatsapp_group_gating.py) Adds an end-to-end authorization test: an unlisted group member @mentioning the bot in an allowlisted group is processed by the adapter AND authorized by the gateway, while the same sender in a DM is denied. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

# Conflicts: # gateway/authz_mixin.py # gateway/session.py # scripts/whatsapp-bridge/bridge.js

Signal DMs already resolve source.is_owner via the generic _is_owner() fallback (SIGNAL_ALLOWED_USERS), but the two owner-marker opt-in gates (the **Owner:** session-prompt line and the additive [SYSTEM: sender NAME is the owner] message marker) only listed WHATSAPP/WHATSAPP_CLOUD. Add Platform.SIGNAL to both gates so Signal gets the same owner disclosure as WhatsApp once is_owner is set, and add regression tests covering all three gated platforms plus the non-gated/shared-session cases.

…-parity-owner-detection # Conflicts: # gateway/run.py # tests/gateway/test_shared_group_sender_prefix.py

sdugoten mentioned this pull request Jun 27, 2026

[Question] Whatsapp groups and require_mention: true, only reply to allowed users #7269

Open

sdugoten force-pushed the feat/whatsapp-group-parity-owner-detection branch from 775ad47 to 94cbdee Compare June 27, 2026 13:05

sdugoten changed the title ~~feat(gateway): authorize WhatsApp group members + owner detection (fixes #7269)~~ feat(gateway): WhatsApp group authz + owner detection + reactions (fixes #7269) Jun 27, 2026

sdugoten mentioned this pull request Jun 27, 2026

feat(gateway): bring Signal groups to Telegram parity (authz, mention, owner detection) #53348

Open

sdugoten marked this pull request as ready for review June 27, 2026 13:32

This was referenced Jun 27, 2026

feat(whatsapp): notify the owner when a non-allowlisted sender messages #53745

Open

feat(whatsapp): owner-aware toolset gating for shared lines #53742

Open

fix: authorize allowlisted WhatsApp group chats #55875

Open

dorukardahan mentioned this pull request Jul 7, 2026

feat(whatsapp): add processing status reactions #29354

Open

teknium1 reviewed Jul 15, 2026

View reviewed changes

sdugoten and others added 2 commits July 15, 2026 12:58

Merge remote-tracking branch 'origin/main' into pr-53623

a14be6e

# Conflicts: # gateway/authz_mixin.py # gateway/session.py # scripts/whatsapp-bridge/bridge.js

bhargav-forsyt mentioned this pull request Jul 21, 2026

fix(whatsapp): end-to-end allowlisted group intake for multi-member chats #68844

Open

19 tasks

sdugoten added 2 commits July 26, 2026 16:16

Merge remote-tracking branch 'upstream/main' into feat/whatsapp-group…

ca1a20e

…-parity-owner-detection # Conflicts: # gateway/run.py # tests/gateway/test_shared_group_sender_prefix.py

eduardo mentioned this pull request Jul 28, 2026

fix(whatsapp): honor group ingress policy in bridge #73465

Open

19 tasks

This was referenced Jul 29, 2026

[Bug]: WhatsApp reply-to-bot detection fails — device suffix mismatch in botIds vs quotedParticipant #29023

Open

fix(whatsapp): gate group media downloads #68810

Open

fix(whatsapp): authorize first-contact LID senders via senderPn #63416

Open

Navigation Menu

Uh oh!

feat(gateway): WhatsApp group authz + owner detection + reactions (fixes #7269) - #53623

feat(gateway): WhatsApp group authz + owner detection + reactions (fixes #7269)#53623
sdugoten wants to merge 5 commits into
NousResearch:mainfrom
sdugoten:feat/whatsapp-group-parity-owner-detection

sdugoten commented Jun 27, 2026 •

edited

Loading

Uh oh!

alt-glitch commented Jun 27, 2026

Uh oh!

teknium1 left a comment

Uh oh!

teknium1 Jul 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

sdugoten commented Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What & why

The changes

Scope notes

How to test

Platforms tested

Related

Uh oh!

alt-glitch commented Jun 27, 2026

Uh oh!

teknium1 left a comment

Choose a reason for hiding this comment

Problems

Suggested changes

Uh oh!

teknium1 Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sdugoten commented Jun 27, 2026 •

edited

Loading