Summary

openclaw message send --channel zalo --target <id> rejects valid Zalo Bot Platform chat_id values that are non-numeric (hex-like), even though upstream Zalo Bot API accepts them and delivers successfully.

This causes a mismatch where:

• replying inside an existing Zalo session works
• proactive outbound sends via CLI/script fail with Unknown target ... for Zalo. Hint: <chatId>

Environment

• OpenClaw CLI/runtime on macOS
• Channel: zalo (Bot API)
• OpenClaw model/runtime details available if needed, but this reproduces at the channel/plugin level

What I expected

If a user can DM the Zalo bot and OpenClaw can reply in-session, then openclaw message send --channel zalo --target <chat_id> should also work when given the same valid upstream chat_id.

What happened

OpenClaw rejects the target before send:

openclaw message send --channel zalo --target 3becaa50ae12474c1e03 --message "test"
# Error: Unknown target "3becaa50ae12474c1e03" for Zalo. Hint: <chatId>

Same for another valid Zalo DM target:

openclaw message send --channel zalo --target 49270a5f8f1c66423f0d --message "test"
# Error: Unknown target "49270a5f8f1c66423f0d" for Zalo. Hint: <chatId>

Upstream verification

Calling Zalo Bot Platform API directly with the exact same IDs as chat_id succeeds:

POST https://bot-api.zaloplatforms.com/bot<BOT_TOKEN>/sendMessage
chat_id=3becaa50ae12474c1e03
text=test via chat_id Papa

Response:

{"ok":true,"result":{"message_id":"2bd5af23b7f0a4a8fde7","date":1774860400621},"error_code":0}

And:

POST https://bot-api.zaloplatforms.com/bot<BOT_TOKEN>/sendMessage
chat_id=49270a5f8f1c66423f0d
text=test via chat_id Mommie

Response:

{"ok":true,"result":{"message_id":"dc595f99474a54120d5d","date":1774860400664},"error_code":0}

Using user_id or conversation_id with the upstream API failed; chat_id is the required field.

Why this seems to be happening

From the built plugin/runtime code, Zalo messaging currently appears to use a target validator that expects numeric-looking IDs:

• targetResolver: { looksLikeId: isNumericTargetId, hint: "<chatId>" }

But actual Zalo Bot Platform chat_id values can be non-numeric hex-like strings.

So OpenClaw seems to reject valid upstream chat_ids during target validation/resolution.

Additional observation

OpenClaw can still reply in-session to incoming Zalo messages, which suggests session-route handling works. The failure seems specific to proactive outbound sends through CLI/script paths that rely on target validation.

Suggested fix

For channel zalo, relax or replace the target validator so it accepts the real chat_id format used by Zalo Bot Platform, not only numeric-looking IDs.

At minimum, Zalo should accept string chat_ids like:

• 3becaa50ae12474c1e03
• 49270a5f8f1c66423f0d

Repro steps

1. Configure a working Zalo Bot channel in OpenClaw
2. DM the bot from a Zalo user
3. Confirm in-session replies work
4. Try proactive send:

openclaw message send --channel zalo --target <same-zalo-chat-id> --message "hello"

5. Observe OpenClaw rejects the target
6. Send the same message directly through upstream Zalo Bot API using chat_id=<same-id>
7. Observe upstream delivery succeeds

Impact

This blocks scheduled alerts / proactive notifications over Zalo from scripts and automations, even though the upstream bot platform supports them.