Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

In Feishu (Lark) direct message (1:1 chat) scenarios, OpenClaw's built-in Feishu plugin incorrectly sends messages with replyToMessageId set, causing:

1. Messages to display with a "Reply to [User]" label in the Feishu client
2. Slower message delivery due to additional API overhead (reply vs. direct send)

Steps to reproduce

1. Configure an OpenClaw agent with Feishu direct message (DM) binding
2. Send a message to the agent via Feishu private chat
3. Agent replies
4. Observe the reply in Feishu client — it shows "Reply to [User]" label

Expected behavior

In direct/private chat (:direct: session key), messages should be sent as top-level messages without replyToMessageId, resulting in clean message display without "Reply to" labels.

Actual behavior

Messages are sent with replyToMessageId populated, causing:

• "Reply to [User]" label displayed in Feishu client
• Slower delivery (reply API vs. direct send API)
• Visual inconsistency compared to normal chat messages

OpenClaw version

2026.5.20

Operating system

ubuntu 24.04

Install method

npm globle

Model

kimi-coding

Provider / routing chain

openclaw (local gateway) -> feishu built-in plugin -> feishu API (lark-openapi)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Root Cause Analysis (Updated)
Initial Analysis: After investigating dist/channel-CCNshI3E.js and dist/conversation-id-CZogbv72.js, we suspected the issue was in resolveFeishuTopicAutoThreadAnchor being triggered by parentConversationId.
Key Discovery: The real trigger is blockStreaming: true (default). When block streaming is enabled, OpenClaw uses a streaming card delivery path that automatically sets replyToMessageId, causing the "Reply to" label. When blockStreaming: false, messages are sent via the direct path without reply anchoring.
This explains why patches to buildFeishuSendReplyAnchor and resolveFeishuTopicAutoThreadAnchor had no effect — the streaming card path bypasses these functions entirely.
Attempted Fixes
Code patches to channel-CCNshI3E.js (Attempt 1 & 2): Modified resolveFeishuTopicAutoThreadAnchor and buildFeishuSendReplyAnchor to detect direct chats. Result: No effect, confirming the reply anchor is set in the streaming layer, not the send action layer.
Configuration change (Working solution): Set "blockStreaming": false in channels.feishu config. Result: "Reply to" label disappears and message delivery is significantly faster.
Workaround (Verified)
Set blockStreaming: false in your OpenClaw configuration:
json

{
"channels": {
"feishu": {
"blockStreaming": false
}
}
}
Trade-off: Disabling block streaming may affect how large messages are rendered in Feishu, but for typical chat responses the impact is minimal.
Suggested Fix
The streaming card delivery path should respect chat type and not force reply mode for direct/private chats. The fix should be applied in the streaming/card delivery layer (not in buildFeishuSendReplyAnchor).
Additional Context
Regression: This issue occurred in older versions of OpenClaw, was previously fixed, and has now reappeared in version 2026.6.6. This suggests the bug may have been reintroduced during a recent refactoring of the streaming or card delivery path.
Related Code
dist/channel-CCNshI3E.js — buildFeishuSendReplyAnchor, resolveFeishuTopicAutoThreadAnchor, isFeishuGroupTopicSessionKey
dist/conversation-id-CZogbv72.js — parseFeishuConversationId
dist/send-Bpn2MIyC.js — sendReplyOrFallbackDirect, sendMessageFeishu