Message your wife on WhatsApp when work ends

Tools

OpenClaw

Overview

Repository navigation

Workflow

Repository navigation Description 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 temporaily 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. "agents": { "id": "silence", }, 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 should 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 I worked for a while bit then he agent kept falling back to a working model. 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: Behavior inbound: disabled Incoming messages from this peer are ignored at routing level No session creation No agent execution No fallback triggers 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 outbound: enabled Messages can still be sent to this peer via agents or API calls Alternative simpler API If a boolean is preferred: 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 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 More visible in: allowlist-based configurations systems with multiple active contacts

Reported result

The workaround initially functioned but failed over time as the agent kept falling back to a working model, causing unintended replies. The issue was closed as 'not planned' by maintainers, who noted that native per-peer directional policy is currently missing and tracked in a broader issue (#59560). No successful long-term resolution was achieved via the described workaround.

Human role

The original post does not say how a person stayed involved.

Limitations

OpenClaw currently lacks native per-peer control to separate inbound processing from outbound permissions. The workaround relies on strict configuration hygiene to prevent model inheritance, which is fragile and prone to fallback errors. Users must manually manage bindings and ensure no global defaults exist. The proposed feature was rejected in favor of a centralized tracker, meaning no immediate native fix is available.

Try it

Act as an OpenClaw configuration engineer. I need to set up outbound-only WhatsApp messaging for [replaceable_contact_name] with number [replaceable_phone_number] to send [replaceable_notification_message] when [replaceable_trigger_event] occurs, without triggering inbound agent responses. Steps: 1. Check current OpenClaw config for any global `agents.defaults.model` settings. If present, remove them to prevent inheritance. 2. Explicitly assign the LLM model only to the main active agent(s) that require processing. 3. Create a new agent configuration with ID `silence` and NO model assigned. 4. Configure WhatsApp bindings to route inbound messages from [replaceable_phone_number] to the `silence` agent. 5. Ensure outbound permissions allow sending to [replaceable_phone_number]. 6. Perform a dry run: Send a test outbound message to verify delivery. Then, simulate an inbound message from [replaceable_phone_number] and verify that NO agent response is generated. 7. If the agent responds, check for fallback model inheritance in the logs and adjust bindings. Deliverables: A JSON snippet of the modified `agents` and `whatsapp` config sections, and a log excerpt showing the successful dry run (outbound sent, inbound ignored). Ask for clarification if the current config structure is unknown.

More cases · Everyday life

• Scrub your phone number from data brokers to stop spam
• Search flights with airline constraints using Comet
• Decide between points and cash for every trip
• Extract school dates from forwarded emails and flyers
• Search for a wedding flight to New York