openclaw - 💡(How to fix) Fix [Bug] Structured card action callback filtered by requireMention in group chats

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

When a structured card action callback (e.g., execute_confirmed) is dispatched in a group chat with requireMention: true, the synthetic message is filtered out because checkBotMentioned returns false, even though buildSyntheticMessageEvent injects the bot open_id into the mentions array.

Result: Card button clicks appear to "do nothing" — the agent never receives the command.

Root Cause

In monitor.account-DfA69ukP.js:

buildSyntheticMessageEvent (line ~2763) correctly injects the bot mention:

...botOpenId ? { mentions: [{ id: { open_id: botOpenId }, name: "bot", key: "mention_bot" }] } : {}

But checkBotMentioned (line ~189) checks:

const mentions = event.message.mentions ?? [];
if (mentions.length > 0) return mentions.some((mention) => 
  !isFeishuBroadcastMention(mention) && mention.id.open_id === botOpenId
);

The botOpenId passed to handleFeishuMessage comes from dispatchSyntheticCommand, which gets it from params.botOpenId (the card action handler). This should match.

However, the handleFeishuMessage flow also re-resolves requireMention via resolveFeishuReplyPolicy based on group config. The issue is that even though the synthetic message has the bot in mentions, the resolveFeishuReplyPolicygroupSenderActivationIngress check evaluates ingress.admission as non-dispatch because the synthetic message's mention format doesn't match what resolveFeishuGroupSenderActivationIngressAccess expects.

Most likely: the key: "mention_bot" in the injected mention doesn't match the expected format used by checkBotMentioned or resolveFeishuGroupSenderActivationIngressAccess.

Fix Action

Workaround

None found — setting requireMention: false for the entire group chat is not acceptable as it would cause the bot to respond to all messages.

Code Example

[feishu] feishu[xingbu]: handling structured card action execute_confirmed from ou_55adbd044c84df015a0f7bfbcf9241ca
[feishu] feishu[xingbu]: received message from ou_55adbd044c84df015a0f7bfbcf9241ca in oc_54cd... (group)
[feishu] feishu[xingbu]: message in group oc_54cd... did not mention bot   ← silently dropped

---

...botOpenId ? { mentions: [{ id: { open_id: botOpenId }, name: "bot", key: "mention_bot" }] } : {}

---

const mentions = event.message.mentions ?? [];
if (mentions.length > 0) return mentions.some((mention) => 
  !isFeishuBroadcastMention(mention) && mention.id.open_id === botOpenId
);
RAW_BUFFERClick to expand / collapse

Description

When a structured card action callback (e.g., execute_confirmed) is dispatched in a group chat with requireMention: true, the synthetic message is filtered out because checkBotMentioned returns false, even though buildSyntheticMessageEvent injects the bot open_id into the mentions array.

Result: Card button clicks appear to "do nothing" — the agent never receives the command.

Reproduction

  1. Feishu group chat with requireMention: true
  2. Bot sends an interactive card with a button (structured callback, e.g., a: "execute_confirmed")
  3. User clicks the button
  4. Expected: agent receives the command and executes
  5. Actual: message is silently dropped with log: message in group {chatId} did not mention bot

Evidence from logs

[feishu] feishu[xingbu]: handling structured card action execute_confirmed from ou_55adbd044c84df015a0f7bfbcf9241ca
[feishu] feishu[xingbu]: received message from ou_55adbd044c84df015a0f7bfbcf9241ca in oc_54cd... (group)
[feishu] feishu[xingbu]: message in group oc_54cd... did not mention bot   ← silently dropped

Root cause analysis

In monitor.account-DfA69ukP.js:

buildSyntheticMessageEvent (line ~2763) correctly injects the bot mention:

...botOpenId ? { mentions: [{ id: { open_id: botOpenId }, name: "bot", key: "mention_bot" }] } : {}

But checkBotMentioned (line ~189) checks:

const mentions = event.message.mentions ?? [];
if (mentions.length > 0) return mentions.some((mention) => 
  !isFeishuBroadcastMention(mention) && mention.id.open_id === botOpenId
);

The botOpenId passed to handleFeishuMessage comes from dispatchSyntheticCommand, which gets it from params.botOpenId (the card action handler). This should match.

However, the handleFeishuMessage flow also re-resolves requireMention via resolveFeishuReplyPolicy based on group config. The issue is that even though the synthetic message has the bot in mentions, the resolveFeishuReplyPolicygroupSenderActivationIngress check evaluates ingress.admission as non-dispatch because the synthetic message's mention format doesn't match what resolveFeishuGroupSenderActivationIngressAccess expects.

Most likely: the key: "mention_bot" in the injected mention doesn't match the expected format used by checkBotMentioned or resolveFeishuGroupSenderActivationIngressAccess.

Environment

  • OpenClaw version: 2026.5.12
  • Channel: Feishu (websocket mode)
  • Group chat: requireMention: true

Suggested fix

Structured card action callbacks should bypass requireMention checks entirely, since the user has already interacted with the bot (clicked a button on a bot-sent card). The callback is a direct response to a bot-initiated action.

Options:

  1. In handleFeishuMessage, detect synthetic card-action messages (message_id starts with card-action-) and set requireMention: false
  2. Fix the bot mention injection in buildSyntheticMessageEvent to use the format that checkBotMentioned recognizes
  3. Add a flag to the synthetic message context that bypasses the mention check

Workaround

None found — setting requireMention: false for the entire group chat is not acceptable as it would cause the bot to respond to all messages.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug] Structured card action callback filtered by requireMention in group chats