Description

The outbound target authorization logic treats an empty allowFrom list as allow all direct targets, effectively disabling outbound allowlisting when allowFrom is omitted/empty.

• Input: allowFrom comes from configuration (e.g., account/channel allowFrom), and may be undefined/empty for default configs.
• Sink: resolveWhatsAppOutboundTarget() authorizes sending to arbitrary E.164 WhatsApp targets.
• Issue: when allowFrom is empty, the code returns { ok: true } for any non-group target, enabling outbound messages to arbitrary numbers.

Vulnerable code:

if (hasWildcard || allowList.length === 0) {
  return { ok: true, to: normalizedTo };
}

This is security-sensitive because other call paths (e.g., action authorization via resolveWhatsAppDirectTargetAuthorization() in account-policy.ts) pass configuredAllowFrom which is empty when not configured, resulting in an implicit allow-all posture.

Recommendation

Adopt a default-deny posture for outbound direct messages unless an explicit allow rule exists.

Suggested change:

• Only allow all when an explicit wildcard "*" is configured.
• If allowFrom is empty, deny (or require an explicit config flag like allowAllOutbound: true).

​// deny-by-default unless wildcard or explicit match
if (hasWildcard) {
  return { ok: true, to: normalizedTo };
}
if (allowList.length === 0) {
  return { ok: false, error: whatsappAllowFromPolicyError(normalizedTo) };
}
if (allowList.includes(normalizedTo)) {
  return { ok: true, to: normalizedTo };
}
return { ok: false, error: whatsappAllowFromPolicyError(normalizedTo) };

Also update documentation/tests to reflect the intended policy (and ensure configs without allowFrom do not silently become unrestricted).

Description

resolveWhatsAppOutboundTarget treats any target that matches @​g.us group JID format as automatically authorized, bypassing the configured allowFrom allowlist.

• Input: untrusted to/chatJid is provided by callers (e.g., tool/action parameters)
• Policy: allowFrom is intended to restrict which targets can be messaged
• Bypass: group JIDs return { ok: true } before evaluating wildcard/empty/allowlist membership

This allows an actor who can invoke WhatsApp send actions to message arbitrary groups (if they can supply/guess a group JID), even when outbound messaging is restricted to specific contacts via allowFrom.

Vulnerable code:

if (isWhatsAppGroupJid(normalizedTo)) {
  return { ok: true, to: normalizedTo };
}

Recommendation

Apply allowlist enforcement consistently to group JIDs, or introduce a separate, explicit configuration for allowed group targets.

Example: require group JIDs to be explicitly allowlisted unless a dedicated allowAllGroups (or groupAllowTo) flag/list is configured:

const isGroup = isWhatsAppGroupJid(normalizedTo);

if (hasWildcard || allowList.length === 0) {
  return { ok: true, to: normalizedTo };
}

​// Enforce allowlist for both users and groups
if (allowList.includes(normalizedTo)) {
  return { ok: true, to: normalizedTo };
}

return { ok: false, error: whatsappAllowFromPolicyError(normalizedTo) };

If the intent is to keep groups open by default, make that an explicit policy (e.g., groupAllowFrom / groupAllowTo) and document the security implications.

Best possible solution:

Refresh the account-policy seam on current main, replace broad config-runtime imports with narrow Plugin SDK subpaths, preserve current WhatsApp send/inbound behavior, and land only after maintainers accept the sequencing with adjacent WhatsApp authorization work.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a behavior-preserving refactor PR rather than a bug report. The reviewable checks are current-main mergeability, source parity, and authorization-policy sequencing.

Is this the best way to solve the issue?

No for the submitted branch state. A WhatsApp-local account-policy seam is a plausible cleanup, but this branch conflicts with current main and imports from a config SDK barrel that current main's boundary guard rejects.

Full review comments:

• [P2] Use narrow Plugin SDK config subpaths — extensions/whatsapp/src/account-policy.ts:1-6
  Current main's config boundary guard reports imports from openclaw/plugin-sdk/config-runtime in repo code and tells callers to use narrow config subpaths instead. This new module imports config types and resolveDefaultGroupPolicy from that broad barrel, so a refreshed branch will fail boundary checks until those imports move to focused subpaths such as config-contracts and runtime-group-policy.
  Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 8ed6c78b7891.

Label justifications:

• P3: This is maintainer-owned WhatsApp refactor work with no confirmed active user regression, but it needs refresh and review before merge.
• merge-risk: 🚨 compatibility: The PR centralizes WhatsApp default account, allowFrom, groupAllowFrom, fallback, and store-read behavior that existing configs may depend on.
• merge-risk: 🚨 message-delivery: The changed seam feeds outbound send account selection and heartbeat recipient behavior, so a parity mistake could misroute or suppress WhatsApp messages.
• merge-risk: 🚨 security-boundary: The changed seam feeds inbound sender authorization and outbound action target authorization decisions.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The external contributor proof gate does not apply because this is a member-authored, maintainer-labeled internal refactor PR.

PR surface:

Source +41, Tests +237. Total +278 across 7 files.

What I checked:

• Root policy read: Root AGENTS.md was read fully; its PR review policy requires whole-surface review and treats plugin auth, fallback, config, and compatibility surfaces as merge-risk-sensitive. (AGENTS.md:26, 8ed6c78b7891)
• Scoped plugin policy read: extensions/AGENTS.md was read fully; bundled plugin production code should import through Plugin SDK subpaths and stay inside the plugin boundary. (extensions/AGENTS.md:19, 8ed6c78b7891)
• Live PR state: Live GitHub reports this PR open, non-draft, maintainer-labeled, head 844b652, and CONFLICTING/DIRTY against base ed6094b. (844b65293991)
• Patch adds broad config-runtime import: The added account-policy module imports config types and resolveDefaultGroupPolicy from openclaw/plugin-sdk/config-runtime. (extensions/whatsapp/src/account-policy.ts:1, 844b65293991)
• Current main rejects that import shape: The current config boundary guard records broad config-runtime imports as violations and tells callers to use narrow Plugin SDK config subpaths. (scripts/lib/config-boundary-guard.mjs:200, 8ed6c78b7891)
• Current main uses narrow WhatsApp imports: Current main's WhatsApp inbound policy imports config contracts from config-contracts and resolveDefaultGroupPolicy from runtime-group-policy, not config-runtime. (extensions/whatsapp/src/inbound-policy.ts:3, 8ed6c78b7891)

Likely related people:

• mcaxtr: Authored this PR and multiple merged WhatsApp account, inbound, outbound, and target-routing changes that this seam centralizes. (role: feature-history owner and recent area contributor; confidence: high; commits: 844b65293991, 458a52610a4d, eb67ac5cbe5f; files: extensions/whatsapp/src/inbound-policy.ts, extensions/whatsapp/src/accounts.ts, extensions/whatsapp/src/send.ts)
• Bluetegu: Authored the merged WhatsApp group/direct system prompt work that participates in the same account/group config surface this refactor must preserve. (role: adjacent feature owner; confidence: medium; commits: 08bc16853ef4; files: extensions/whatsapp/src/account-types.ts, extensions/whatsapp/src/inbound-policy.ts)
• Dallin Romney: Local blame in this shallow checkout points the current WhatsApp policy and boundary-guard lines to the latest current-main snapshot commit; this is useful as recent provenance but not strong feature ownership. (role: recent current-main source contributor; confidence: low; commits: 8604dbdc93fb; files: extensions/whatsapp/src/inbound-policy.ts, extensions/whatsapp/src/accounts.ts, scripts/lib/config-boundary-guard.mjs)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.