openclaw - 💡(How to fix) Fix [Feature]: Support outbound-only messaging for specific WhatsApp peers (no inbound processing) [1 comments, 2 participants]

Summary

Currently, OpenClaw allows sending WhatsApp messages to specific contacts via configured bindings or allowlists. However I could not find a way to separate outbound messaging permissions from inbound message processing on a per-contact basis.

This means that if a number is allowed for outbound communication, incoming messages from that same number can still trigger agent execution and responses.

I have a little workaround using dummy agents.

Problem to solve

I wanted to let Openclaw send a message to my wife when I finished working. To allow sending WhatsApp messages to specific contacts the number has to be in the allowlists. This also redirects inbound messages from that number to openclaw. I probably don't know enough but I found a workaround:

Workaround

The issue was mitigated by removing the global default model configuration (agents.defaults.model) to prevent unintended model inheritance across all agents.

Instead, models were assigned explicitly only to active agents (e.g. the main agent), ensuring that only intended agents can execute LLM responses.

A separate “silent” agent was created without any model assigned. This agent is used as a routing sink for specific peers via explicit bindings, ensuring that messages from those peers are matched but not processed or responded to.

This setup effectively prevents unintended replies by:

• Eliminating global model inheritance
• Restricting model execution to explicitly configured agents
• Using a no-model agent as a message sink for ignored peers

Proposed solution

Proposed solution

Introduce native per-peer control over inbound message handling, allowing outbound messaging and inbound processing to be configured independently.

This would allow each WhatsApp contact (peer) to define whether incoming messages should trigger agent execution, without affecting the ability to send messages to that contact.

Suggested design

Add a per-peer configuration option in bindings or allowlist rules:

{
  "channel": "whatsapp",
  "peer": {
    "kind": "direct",
    "id": "+324XXXXXXXXX"
  },
  "inbound": "disabled",
  "outbound": "enabled"
}

Behavior

• inbound: disabled

  • Incoming messages from this peer are ignored at routing level
  • No session creation
  • No agent execution
  • No fallback triggers

• outbound: enabled

  • Messages can still be sent to this peer via agents or API calls

Alternative simpler API

If a boolean is preferred:

"inbound": false

Expected outcome

This removes the need for:

• dummy/silent agents
• model inheritance workarounds
• routing sink hacks
• binding duplication patterns

It cleanly separates:

• messaging permissions (outbound)
• interaction permissions (inbound processing)

Benefit

• clearer routing semantics
• safer automation for notification-only contacts
• prevents unintended agent activation
• reduces configuration complexity and edge cases

Alternatives considered

No response

Impact

Impact

Affected users / systems / channels

This affects users building WhatsApp-based automations in OpenClaw, especially those using:

• Per-peer routing (bindings / allowlists)
• Multi-contact messaging systems (CRM-style workflows)
• Hybrid human + automation setups
• Any setup where WhatsApp DM handling is enabled alongside outbound messaging

It primarily impacts the WhatsApp channel routing layer, including:

• DM session handling
• Agent binding resolution
• Fallback routing behavior

Severity

Moderate to high severity

• It does not fully break the system, but it causes unintended agent execution
• Leads to loss of control over inbound message handling
• In automation-heavy setups, this can effectively break expected behavior and reliability

For some workflows (e.g. notification-only messaging), it becomes workflow-blocking in practice, because safe outbound-only usage is not supported natively.

Frequency

Intermittent to frequent (depends on setup)

• Occurs consistently whenever:

  • a peer is allowed for outbound communication
  • and inbound messages from that peer are received

• More visible in:

  • allowlist-based configurations
  • systems with multiple active contacts
  • setups relying on fallback agents

In real-world usage, it is often experienced as recurring unexpected replies rather than a rare edge case.

Consequences

• Unexpected agent responses to inbound messages from allowed contacts
• Loss of separation between outbound messaging and inbound conversation handling
• Need for manual workarounds (e.g. routing hacks, dummy agents, or strict config restructuring)
• Increased configuration complexity and maintenance overhead
• Reduced predictability of automation behavior in production workflows
• Risk of unintended interactions with end users (bots replying when they should not)

Overall impact summary

The lack of inbound/outbound separation per peer leads to unpredictable agent activation behavior in real-world messaging workflows, forcing users to rely on structural workarounds to achieve basic directional communication control.

Evidence/examples

No response

Additional information

No response