Bug

session.sendPolicy deny rules block inbound message processing, not just outbound delivery. When a deny rule matches (e.g., {action: "deny", match: {channel: "whatsapp", chatType: "group"}}), the inbound message is silently dropped — the agent never sees it.

The docs say sendPolicy "controls cross-session send permissions" — it should only gate whether the agent's response is delivered, not whether the inbound message is processed.

Affected Code

Primary: src/auto-reply/reply/dispatch-from-config.ts (lines ~461-481)

const sendPolicy = resolveSendPolicy({...});
if (sendPolicy === "deny" && !bypassAcpForCommand) {
  // Returns early BEFORE the agent processes the message
  return { queuedFinal: false, counts };
}

This check happens BEFORE getReplyFromConfig() (line ~549) which runs the agent. The message is dropped without the agent ever seeing it.

Secondary: src/auto-reply/reply/commands-core.ts (lines ~314-324)

if (sendPolicy === "deny") {
  return { shouldContinue: false };
}

This blocks slash command processing for denied sessions. This is arguably correct behavior and should be left as-is.

Expected Behavior

• sendPolicy: "deny" should suppress delivery of the agent's response only
• The agent should still process the inbound message (for context, memory, tool calls, etc.)
• Slash commands from denied sessions can reasonably remain blocked

Proposed Fix

In dispatch-from-config.ts:

1. Replace the early return block (lines 473-481) with a flag: const suppressDelivery = sendPolicy === "deny" && !bypassAcpForCommand;
2. Before the delivery loop (line ~641), check suppressDelivery and skip delivery while still returning normally
3. The agent still processes inbound messages via getReplyFromConfig(), maintaining context and memory

This separates the "should the agent see this message" decision from the "should the response be delivered" decision, matching the documented intent of sendPolicy.