Signal: group added at creation-time is never auto-approved (only post-creation invites are)

[juniperbevensee]

Summary

The Signal group auto-approve path only fires when the agent receives a group-invite envelope (a groupV2 update with no dataMessage). If an approved admin adds the agent as a member during group creation, no invite envelope is delivered, the handler never runs, and the group is never added to the allowlist — so all group messages (including /sethome) are silently dropped.

Evidence

Observed live: Matilde (deployed agent) was added to a group "message bus (matilde)" at creation. She received the messages but never responded; SIGNAL_GROUP_ALLOWED_USERS stayed empty (groups=disabled). Her gateway.log contained zero group invit* / auto-accept / joinGroup lines — confirming no invite envelope ever arrived. Manually adding the group ID to SIGNAL_GROUP_ALLOWED_USERS fixed it.

Code

gateway/platforms/signal.py:647-715 — auto-accept is gated on:

data_message_raw = envelope_data.get("dataMessage")
if not data_message_raw:
    group_v2_invite_id = (envelope_data.get("groupV2") or {}).get("groupId") ...
    if group_v2_invite_id:
        # approved-only: inviter must be an approved user
        ...
        await self._rpc("joinGroup", ...)
        self.group_allow_from.add(group_v2_invite_id)   # auto-approve

There is no handler for the creation-membership case (being a member in the initial group state rather than receiving a standalone invite).

Proposed fix (options)

1. Docs/UX: document the supported path — create the group, then invite the agent (don't add-at-creation). Surface this in HSM's group UI.
2. Code: also detect creation-membership (agent appears as a new member in a groupV2 update for a group it isn't yet in) and run the same approved-inviter check + joinGroup + allowlist-add.

Impact

Low-severity but high-confusion: the agent looks "broken/offline" in a group when it's actually just unapproved. Bit us during Matilde bring-up (2026-06-19).

[juniperbevensee]

Why this is an HSM issue (moved from hermes-agent-mt): the symptom is in the gateway (signal.py:647-715 only auto-approves on a post-creation invite envelope), but the fix we want is HSM-owned. HSM already has the group surface (/api/surfaces/signal/groups listGroups) and the groupInvitePolicy toggle in harness→settings — it just doesn't act on them. Proposed HSM behavior: poll/list the groups the agent is a member of, and for any not yet in SIGNAL_GROUP_ALLOWED_USERS, auto-approve when the agent was added by an approved admin and the settings toggle permits — then persist via the settings path. That covers the add-at-creation case the gateway can't see, and makes the harness→settings toggle the source of truth.

[juniperbevensee]

Investigation note (gardener 2026-07-01): the 'no handler at all' gap is closed — _reconcile_groups() now runs on every connect and approves+persists member groups. But the reported case (default approved-only policy) still does not auto-approve at creation, by design: _group_approval_reason() returns None for approved-only (the #56 privilege-escalation fix — at reconcile time there's no record of who added the bot). So: allow-all/open-mode → add-at-creation now works; approved-only (default) → still silent until an approved user invites or the group is manually allowlisted. Remaining options (both in hermes-agent-mt, neither autonomously safe): (1) document 'create group, then invite the agent' + surface in HSM group UI; (2) secure message-time approval — when an approved user posts in an unapproved group, treat that post as the vouching action (trusts an action not presence, satisfies #56) and approve+persist. Option 2 is net-new auth-boundary code needing security review. Needs a product decision.