Summary

When a WhatsApp group session receives an inter_session turn that is actually asking it to post a normal human message into the group, the session can incorrectly choose REPLY_SKIP, ANNOUNCE_SKIP, or NO_REPLY instead of emitting the requested message.

This appears to be a precedence bug between:

• inter_session anti-ping-pong / silent-reply heuristics, and
• legitimate explicit outbound group-reply intents.

The result is confusing because:

• the group/session is authorized
• the sender/chat authorization is fine
• transport is fine
• explicit “post this exact message now” instructions can succeed in the same session

So the failure is not routing or authorization. It is the wrong default decision path for certain inter_session turns.

Minimal repro

1. Configure a WhatsApp group/session where a given authorized sender is allowed to trigger replies without needing an @ mention.

2. Send an inter_session message into that group session that asks it to post a normal human message into the WhatsApp group.

3. Observe that the target session may reply with one of:

   • REPLY_SKIP
   • ANNOUNCE_SKIP
   • NO_REPLY

4. Then send a stronger explicit instruction such as:

   Post a normal human message in this WhatsApp group now. Do not return NO_REPLY, REPLY_SKIP, or ANNOUNCE_SKIP. Message text exactly:
   
   hello
   

5. Observe that the same session can now emit the requested normal group message successfully.

This shows that:

• the target session is reachable
• the outbound message path works
• the platform/channel can deliver
• but the default inter_session handling is incorrectly suppressing a real delivery intent

Expected behavior

If an inter_session turn is clearly an explicit delivery request to emit a normal channel message, the target session should prefer normal message emission over generic REPLY_SKIP / ANNOUNCE_SKIP / NO_REPLY behavior, assuming:

• the destination channel/session is authorized
• the sender/chat policy allows the reply
• no higher-priority policy/safety rule blocks it

Actual behavior

The target session can treat the turn as meta-coordination and fall back to skip/silent tokens, even though the intended effect is a normal outbound group reply.

Why this matters

This can waste a lot of tokens and operator time because the system looks half-broken:

• normal forced literal sends can work
• but ordinary inter-session instructions keep getting silently suppressed
• operators end up restating the same thing many times
• the distinction between transport failure vs session-decision failure is unclear

Likely root cause

There seems to be a prompt/runtime seam around inter_session guidance.

OpenClaw appears to explicitly teach inter_session recipients that they may reply with:

• REPLY_SKIP to stop ping-pong
• ANNOUNCE_SKIP to remain silent

That guidance is useful for genuine agent-to-agent coordination chatter, but it appears too broad when the inbound turn is actually an explicit request to post a normal message into the destination channel.

In other words, the model is encouraged to classify some delivery requests as coordination chatter, and once that happens, skip/silent control tokens outrank the actual outbound messaging intent.

Proposed fix

1) Narrow the skip-token path for inter_session

For inter_session turns, if the message is an explicit delivery request to emit a normal channel reply, that delivery intent should outrank generic anti-ping-pong/silent heuristics.

2) Improve inter_session injected guidance

The prompt/runtime guidance should distinguish between:

• meta/coordination chatter, where REPLY_SKIP / ANNOUNCE_SKIP are appropriate
• explicit delivery instructions, where those tokens are the wrong default

3) Consider a typed delivery mode for sessions_send

Free-text inter_session instructions are ambiguous.

A more robust design would be a typed intent, conceptually something like:

• sessions_send(..., mode: "deliver-message")

or equivalent structured metadata so the receiving session knows:

• this is not coordination chatter
• this is an explicit request to emit a normal outbound message

4) Add a regression test

Suggested regression test shape:

• target = WhatsApp group session
• input provenance = inter_session
• payload = explicit “post this text as a normal group message” instruction
• expected = emitted normal text reply
• forbidden = REPLY_SKIP, ANNOUNCE_SKIP, NO_REPLY

Additional note

This bug is easy to misdiagnose as:

• sender allowlist failure
• WhatsApp transport failure
• channel routing failure

But the tell is: a more literal forced instruction often succeeds immediately in the same session. That means delivery is available; the wrong branch is being chosen earlier.