openclaw - 💡(How to fix) Fix Feishu duplicate delivery when message.send and assistant final reply both emit [1 comments, 2 participants]

Summary

In a Feishu DM session, the same progress update can be delivered twice when an agent both:

1. calls message.send explicitly, and
2. also produces a normal assistant final reply for the same turn / completion event.

This creates duplicate user-visible messages in Feishu. The inbound Feishu message itself was not duplicated.

Environment

• OpenClaw app: 2026.4.22
• Channel: Feishu DM
• Host: Linux 6.8.0-71-generic, Node 22.22.1
• Gateway: local ws://127.0.0.1:18789
• Model/runtime: direct session, gpt-5.5

openclaw status reports an update available to 2026.4.23, but the incident happened on 2026.4.22.

Observed behavior

The user saw duplicate progress messages in Feishu, for example:

• 修订完成 🦞｜标题、MaaS 段和结尾金句已经按评审合同改完。我重跑红灯预检后送二审。
• 二审通过 🦞｜8.15，过线了。现在进入 Humanizer 和排版发布段。

Each appeared twice in the Feishu DM.

Local session inspection showed the progress update existed in two delivery paths:

1. Explicit tool call:

{
  "name": "message",
  "arguments": {
    "action": "send",
    "channel": "feishu",
    "target": "user:ou_137c41086239266036853c70dd1ae919",
    "message": "修订完成 🦞｜标题、MaaS 段和结尾金句已经按评审合同改完。我重跑红灯预检后送二审。"
  }
}

1. A normal assistant message in the Feishu-bound parent/main session with the same text:

修订完成 🦞｜标题、MaaS 段和结尾金句已经按评审合同改完。我重跑红灯预检后送二审。

The same pattern occurred for 二审通过....

Evidence / identifiers

Original user report message:

• message_id: om_x100b51ff55c9dcb4b258f9978ede8f2
• chat_id: user:ou_5f0a9ee868e2d722d2bab01f24567233
• Feishu chatId: oc_cb3bebf8c7331992d7e930e1af4c8a4b
• Timestamp: Sat 2026-04-25 20:21 GMT+8

Screenshot report message:

• message_id: om_x100b51ff55ceccb0b2ad196dc4d2dab
• Screenshot showed duplicated 修订完成 and 二审通过 bubbles.

Relevant local session files from the affected run:

• Feishu-bound main session key: agent:xiaolongxia:main
• Session ID: 81f171e0-cef0-420e-87cc-eb5f7aff99a6
• Active Feishu direct session key also seen: agent:xiaolongxia:feishu:xiaolongxia:direct:ou_137c41086239266036853c70dd1ae919
• Related running session ID: 1347e7ce-134f-4e8e-b44c-4e261d488326

Inspection results:

• In 1347e7ce-134f-4e8e-b44c-4e261d488326.jsonl, line 76 contained the explicit message.send for 修订完成....
• In 81f171e0-cef0-420e-87cc-eb5f7aff99a6.jsonl, line 90 contained the normal assistant text 修订完成....
• Similar duplication was observed for 二审通过... around lines 93 and 91 respectively.

Expected behavior

OpenClaw should avoid delivering the same content twice to the same Feishu target when a turn emits both:

• an explicit message.send, and
• a normal assistant final reply / session delivery.

Possible fixes:

• provide automatic de-duplication for same target + same/similar content within a short time window;
• suppress normal reply delivery when message.send already delivered user-visible output in the same turn;
• expose a first-class NO_REPLY after send / deliveredExternally flag in the runtime contract;
• make subagent completion announce handling clearer so parent sessions do not accidentally double-deliver progress updates.

Workaround

At the prompt/agent level, we added a local rule:

If an agent calls message.send for a user-visible progress update, the assistant final reply for that turn must be NO_REPLY. Do not also return the same text as a normal assistant message.

This works as a local mitigation, but OpenClaw should ideally protect against accidental double delivery at the framework level.

Related issues

This may be related to earlier Feishu delivery/subagent edge cases:

• #54316 Feishu DM can miss parent final reply after sessions_spawn completion even though the reply exists in session history
• #54319 Feishu message.send appears to require card and plain text send fails while minimal card send succeeds