fix(whatsapp): enforce sendPolicy on auto-reply delivery path#21827
Closed
rsuk-mb wants to merge 2 commits intoopenclaw:mainfrom
Closed
fix(whatsapp): enforce sendPolicy on auto-reply delivery path#21827rsuk-mb wants to merge 2 commits intoopenclaw:mainfrom
rsuk-mb wants to merge 2 commits intoopenclaw:mainfrom
Conversation
openclaw-barnacle
bot
added
channel: whatsapp-web
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
Additional Comments (1)
consider moving the sendPolicy check inside Prompt To Fix With AIThis is a comment left during a code review.
Path: src/web/auto-reply/monitor/on-message.ts
Line: 169-183
Comment:
broadcast agents create their own session keys (see `broadcast.ts:58-68`), but sendPolicy is only checked for the primary route. If you have per-agent sendPolicy rules configured, broadcast agents might bypass their individual deny rules.
consider moving the sendPolicy check inside `broadcast.ts:75` before calling `processMessage`, or verify that the primary route's sendPolicy is intended to govern all broadcast agents.
How can I resolve this? If you propose a fix, please make it concise. |
rsuk-mb
force-pushed
the
fix/enforce-sendpolicy-whatsapp-autoreply
branch
from
ed1b9a2 to
c2ab205
Compare
sendPolicy deny rules were only checked in the gateway and command paths, not on the WhatsApp auto-reply pipeline. This meant deny rules intended to suppress replies to specific DM sessions were silently ignored — the assistant would still auto-reply to contacts that should have been blocked. Add resolveSendPolicy checks to: - on-message.ts: before dispatching the non-broadcast auto-reply - broadcast.ts: per-agent before calling processMessage, so each broadcast agent's session key is individually evaluated This matches the enforcement already present in commands-core.ts and gateway/server-methods/agent.ts. Closes openclaw#21824 Co-Authored-By: Claude Opus 4.6 <[email protected]>
rsuk-mb
force-pushed
the
fix/enforce-sendpolicy-whatsapp-autoreply
branch
from
c2ab205 to
49b1212
Compare
Author
|
Closing in favour of #21893 which addresses the same issue with a cleaner single-insertion-point approach. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
session.sendPolicydeny rules on the WhatsApp auto-reply delivery pathresolveSendPolicycheck inon-message.tsbefore dispatching auto-replies, matching enforcement already present incommands-core.tsandgateway/server-methods/agent.tsProblem
sendPolicydeny rules had no effect on WhatsApp auto-replies. The auto-reply pipeline (on-message.ts→process-message.ts→deliverWebReply) never calledresolveSendPolicy, so deny rules intended to suppress replies to specific DM sessions were silently ignored.This prevented a "see but don't reply" configuration for non-self DMs — the assistant would auto-reply to contacts even when sendPolicy explicitly denied their session key.
Related: #6301 (sendPolicy bypassed by system notifications — same root cause, different vector)
Test plan
send-policy.test.tsunit tests still passlogVerbosemessage appears when a reply is blockedCloses #21824
🤖 Generated with Claude Code
Greptile Summary
Adds
sendPolicyenforcement to WhatsApp auto-reply path by checkingresolveSendPolicybefore dispatching messages, matching the enforcement pattern already present incommands-core.ts:168andgateway/server-methods/agent.ts:410.Key changes:
resolveSendPolicyfromsessions/send-policy.jslogVerbosemessage when policy denies the sessionloadConfig()fresh to ensure latest policy rules are appliedPotential consideration:
maybeBroadcastMessage) create separate session keys for each agent, but the check only validates the primary route's sendPolicy. If per-agent sendPolicy rules differ, broadcast agents might need individual checks withinbroadcast.ts:75Confidence Score: 4/5
commands-core.tsandgateway/server-methods/agent.ts). The implementation is straightforward and well-commented. The only consideration is whether broadcast agents should have individual sendPolicy checks, but this is likely an enhancement rather than a blocker, as the primary route's policy provides baseline protection.Last reviewed commit: ed1b9a2
(2/5) Greptile learns from your feedback when you react with thumbs up/down!