PR #69906: fix(whatsapp): guard multi-account groups inheritance (#69874)

• Repository: openclaw/openclaw
• Author: neeravmakwana
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/69906

Description (problem / solution / changelog)

Closes #69874.

Root cause

extensions/whatsapp/src/account-config.ts resolved every account via a flat { ...channelConfig, ...accountConfig } merge, with no awareness of how many accounts were configured. Root channels.whatsapp.groups therefore flowed into every account that did not explicitly set its own groups, regardless of accounts size. After #59553 added groups["*"].systemPrompt, that silent inheritance also fan-injected one account's wildcard system prompt into every other account's group sessions. Telegram already avoided this at the corresponding seam (mergeTelegramAccountConfig, #30673) via an isMultiAccount guard; the WhatsApp path was the only remaining divergence.

Fix

Mirror Telegram's guard in resolveMergedWhatsAppAccountConfig. After the existing flat merge, recompute groups with a three-level precedence:

1. account-level groups (unchanged)
2. accounts.default.groups shared defaults for named accounts (unchanged)
3. channel-level channels.whatsapp.groups only when Object.keys(accounts).length <= 1 (new guard)

Behavior matrix:

Per the issue's open sub-question #1, only groups is guarded — matching Telegram's scope exactly. direct, toolsBySender, and all other account-shaped fields are untouched.

Why this is safe

• No default value changed. ResolvedWhatsAppAccount.groups was already | undefined, and single-account (including the overwhelmingly common zero-config default-only case) behavior is byte-identical.
• Tighter, not looser. In multi-account setups the change removes silent inheritance, so any runtime check that keyed off account.groups now receives either the explicitly configured map or undefined; it never receives an account that was not in the intended scope.
• Shared baseline preserved. Named accounts still pick up accounts.default.groups through resolveWhatsAppDefaultAccountSharedConfig, so existing multi-account configs that put their shared map under accounts.default keep working without change.
• Mirrors a shipped, battle-tested guard. The logic is the same pattern as mergeTelegramAccountConfig's isMultiAccount branch, including the Object.keys(accounts).length > 1 heuristic.

Security / runtime controls unchanged

• Sender authorization (groupPolicy, groupAllowFrom, dmPolicy, allowFrom, commands.ownerAllowFrom), DM pairing rules, action gates, and the command-auth path in inbound-policy.ts are all unchanged. The guard only narrows which groups map is associated with a given account; it does not soften any authorization check. No runtime-enforced policy is replaced by prompt text in this change, and no prompt text is elevated into a policy decision.
• Wildcard group admission via groups["*"] in multi-account setups becomes opt-in per account instead of implicit across accounts. This is the intended effect and matches Telegram's long-standing behavior.
• channels.whatsapp.direct inheritance is deliberately left as-is (matches Telegram's guard scope and the issue's stated preference).

Migration

Multi-account WhatsApp users who relied on root channels.whatsapp.groups being inherited by every account must now put the map under each account's config block (or under accounts.default to keep the shared-baseline behavior). A note was added to docs/channels/whatsapp.md and the "Unreleased / Changes" section of CHANGELOG.md.

Tests run

• pnpm test:extension whatsapp → 63 files / 523 tests passing, including the seven new cases added in extensions/whatsapp/src/accounts.test.ts covering:
  • single-account inherits root groups
  • single-account account-level groups wins
  • multi-account named account with no own groups → undefined
  • multi-account default account with no own groups → undefined
  • multi-account account-level groups wins
  • multi-account accounts.default.groups shared defaults still flow to named accounts
  • multi-account root direct is intentionally not guarded
• pnpm exec vitest run --project extension-telegram extensions/telegram/src/accounts.test.ts → 28/28 passing (sanity check on the mirrored Telegram path).
• pnpm exec tsc --noEmit -p extensions/whatsapp/tsconfig.json → no new type errors introduced (verified by stashing the diff and rerunning; the three pre-existing errors on main are unrelated to this change and not touched).

Checklist

• AI-assisted, fully tested locally against extension-whatsapp and the mirrored Telegram accounts suite
• Docs updated (docs/channels/whatsapp.md)
• Changelog updated (CHANGELOG.md Unreleased → Changes, marked breaking with migration guidance)
• Bot review conversations will be addressed/resolved on the PR

Made with Cursor

Changed files

• CHANGELOG.md (modified, +1/-0)
• docs/channels/whatsapp.md (modified, +3/-2)
• extensions/whatsapp/src/account-config.ts (modified, +14/-0)
• extensions/whatsapp/src/accounts.test.ts (modified, +84/-0)

---

PR #70000: feat(whatsapp): suppress root groups inheritance in multi-account (#69874)

• Repository: openclaw/openclaw
• Author: omarshahine
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/70000

Description (problem / solution / changelog)

Summary

Closes #69874. Normalizes multi-account groups inheritance on the WhatsApp channel so root-level channels.whatsapp.groups is not silently fan-inherited to every account when more than one account is configured. This matches the existing Telegram guard in extensions/telegram/src/account-config.ts (mergeTelegramAccountConfig) and carves out the follow-up that @Bluetegu flagged in #59553 and maintainers deferred so that PR could land cleanly.

This matters because #59553 added per-group systemPrompt. Before that, silent root-level fan-out of groups was mostly benign (requireMention, tool policies). Now a root channels.whatsapp.groups["*"].systemPrompt: "You are Aria." gets injected into every account's group sessions with no opt-out short of defining an empty groups map per account.

Before / after

Why accept the break

• Telegram parity: the same channel contract should behave the same way for multi-account setups; discrepancies here are a trap for users managing both bots.
• #59553 made the existing silent fan-out dangerous via groups["*"].systemPrompt; a root-level persona bleeds into every account's group sessions by default.
• #59553's author (@Bluetegu) explicitly flagged this design question and asked for a maintainer decision; the decision was deferred so #59553 could ship without breaking any current users. This PR is that follow-up.

Migration

Multi-account users who previously relied on implicit root-level groups inheritance must move the map into each account block explicitly. Two supported patterns:

• Duplicate under each account: channels.whatsapp.accounts.<id>.groups = { ... }.
• Share via accounts.default: channels.whatsapp.accounts.default.groups = { ... } — this still flows to named accounts because the accounts.default shared-defaults path is an explicit opt-in, distinct from implicit root inheritance.

Single-account users see no behavior change.

Open questions for maintainers

Two follow-ups the issue flagged; this PR stays minimal and matches Telegram exactly, so both are left open for maintainer decision:

1. Extend the guard to direct? Telegram only guards groups, so this PR only guards groups. channels.whatsapp.direct has the same per-chat systemPrompt shape (added by #59553) and the same silent fan-out risk in multi-account configs. Matching Telegram's current behavior means leaving it alone here; the question is whether Telegram should gain a direct equivalent, or whether WhatsApp should extend the guard unilaterally.
2. Other per-account-shaped maps? In extensions/whatsapp/src/account-config.ts / src/config/types.whatsapp.ts, the top-level fields that are Record<chatId, ...> shaped and have the same latent-inheritance concern are: groups (guarded here), direct, and dms. Nested under groups[*] there is also toolsBySender, which rides along with groups so it is covered transitively. None of the non-groups fields are touched by this PR.

Tests

Added three cases to extensions/whatsapp/src/accounts.test.ts that lock in the matrix:

• Single-account, no account-level groups → inherits root (preservation).
• Multi-account, no account-level groups → groups is undefined on the resolved account (new behavior; was broken before).
• Multi-account, account defines groups → account replaces root (preservation).

The existing accounts.default shared-defaults tests still pass, confirming that explicit shared-defaults under accounts.default still flow to named accounts.

Closes #69874.

🤖 Generated with Claude Code

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/whatsapp/src/account-config.ts (modified, +12/-3)
• extensions/whatsapp/src/accounts.test.ts (modified, +70/-0)