openclaw - 💡(How to fix) Fix [Bug]: WhatsApp group agents cannot create polls because same-chat runtime hides message tool [1 comments, 2 participants]

Summary

In WhatsApp group auto-reply sessions, the agent no longer receives the message tool even when the agent config explicitly allows it. Because native polls are exposed via message action poll, the agent cannot create WhatsApp polls and falls back to a text-only "reply with numbers" pseudo-poll.

This appears to be a regression in the same-chat/message-tool suppression path: suppressing ordinary same-chat message send also removes channel actions such as poll.

Environment

• OpenClaw: 2026.4.26
• Channel: WhatsApp Web
• Scenario: WhatsApp group routed to a non-default agent
• Agent config includes:

"tools": {
  "profile": "full",
  "allow": [
    "web_search",
    "web_fetch",
    "message",
    "memory_search",
    "memory_get",
    "sessions_spawn",
    "read"
  ]
}

Repro

1. Configure a WhatsApp group to route to an agent whose tools.allow includes message.
2. In that WhatsApp group, ask the agent to create a native multi-option poll.
3. Inspect the compiled agent context / trajectory for that run.

Expected

The agent should have a way to create a native WhatsApp poll, e.g. via:

{
  "action": "poll",
  "channel": "whatsapp",
  "params": {
    "to": "<current group>",
    "question": "...",
    "options": ["...", "..."],
    "maxSelections": 5
  }
}

or an equivalent dedicated safe poll tool/directive.

Actual

The compiled WhatsApp group run exposed only 6 tools:

• read
• web_search
• web_fetch
• memory_get
• memory_search
• sessions_spawn

message was absent despite the agent allowlist including it. The system prompt/tooling section therefore had no message tool and no poll action available. The agent responded with a text pseudo-poll instead of creating a native WhatsApp poll.

Evidence / notes

The installed 2026.4.26 runtime appears to have the lower-level poll plumbing:

• PollParamsSchema includes to, question, options, maxSelections, durationSeconds, durationHours, silent, isAnonymous, threadId, channel, accountId, idempotencyKey.
• The message action runner has an executePollAction path that calls sendPoll(...).
• WhatsApp send runtime has sendPollWhatsApp / sendWebChannelPoll and ultimately sends a Baileys poll payload similar to:

sock.sendMessage(jid, {
  poll: {
    name: poll.question,
    values: poll.options,
    selectableCount: poll.maxSelections ?? 1
  }
})

So the missing piece looks like tool exposure/policy, not lack of WhatsApp poll implementation.

Likely related behavior: same-chat prompts include guidance equivalent to "your replies are automatically sent to this group; do not use the message tool to send to this same group." That guard makes sense for avoiding duplicate normal replies, but it should not remove channel actions like poll that cannot be represented by a normal assistant text reply.

Suggested fix

Do one of these:

1. Keep message available for same-chat sessions when configured, but restrict/guide action=send to avoid duplicate text replies while still allowing non-text channel actions (poll, react, etc.).
2. Split safe channel actions into separate tools/directives, e.g. a dedicated poll tool that remains available even when same-chat message send is suppressed.
3. If the current behavior is intentional, surface a clear warning when tools.allow contains message but runtime same-chat policy removes it, because the effective tool inventory is surprising.

This is user-visible because WhatsApp accounts can create polls normally, and the OpenClaw WhatsApp backend appears capable of sending them; the harness just does not expose the action to the agent in this context.