openclaw - ✅(Solved) Fix bug(matrix): requireMention does not detect m.mentions from non-OpenClaw senders [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

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…
GitHub stats
openclaw/openclaw#64785Fetched 2026-04-12 13:26:48
View on GitHub
Comments
0
Participants
1
Timeline
10
Reactions
0
Author
Participants
Timeline (top)
referenced ×8closed ×1cross-referenced ×1

When requireMention: true is set for a Matrix group room, messages containing valid m.mentions metadata are not detected as mentions, causing all agents to ignore the message. This effectively makes requireMention: true unusable for rooms where messages may come from non-OpenClaw Matrix clients or bots.

Error Message

  • Potential cascading loops when error messages trigger all agents

Root Cause

Looking at extensions/matrix/src/matrix/monitor/mentions.ts, resolveMentions() checks:

  1. m.mentions.user_ids contains the agent's userId AND formatted_body or text contains a matching pattern (line 166-170)
  2. formatted_body has a matrix.to link for the agent (line 158-165)
  3. Text matches mentionRegexes (line 150-153)

The message I sent satisfies conditions 1 and 2. Possible causes:

  • The sender (@eventbridge:localhost) is in groupAllowFrom but is not an OpenClaw-managed account — perhaps inbound message processing skips mention resolution for certain senders
  • The mentionRegexes auto-generated from identity.name may not match CJK display names correctly
  • There may be an earlier filter that drops the message before resolveMentions() is called

Fix Action

Fix / Workaround

Currently the only workaround is requireMention: false + adding "only respond to messages addressed to you" in each agent's SOUL.md, which is unreliable (LLM-based filtering).

  • PR #59323 (fix: emit spec-compliant mentions) — fixed the outbound side, but the inbound mention detection appears broken
  • PR #64031 (rate-limit-circuit-breaker) — a workaround for cascading loops caused by requireMention: false

PR fix notes

PR #64796: fix(matrix): trust m.mentions.user_ids as authoritative mention source

Description (problem / solution / changelog)

Summary

resolveMentions() in the Matrix extension required BOTH m.mentions.user_ids metadata AND a visible text or formatted_body mention for a user mention to register. When non-OpenClaw Matrix clients (Element, standalone bots via matrix-bot-sdk) send proper m.mentions metadata without duplicating the @bot text in the message body, the mention was silently ignored and requireMention: true dropped the message.

This effectively made requireMention: true unusable for any Matrix room receiving messages from non-OpenClaw clients — which is most production deployments.

Fixes #64785

Root cause

// mentions.ts:166-169 (before fix)
const metadataBackedUserMention = Boolean(
  params.userId &&
  mentionedUsers.has(params.userId) &&
  (mentionedInFormattedBody || textMentioned),  // ← requires BOTH
);

Per MSC3952, m.mentions.user_ids is the authoritative mention source. The visible @bot in the body is a display hint for clients that don't support m.mentions, not a prerequisite for the mention to be valid.

The conjunction meant that a message like:

{
  "body": "please reply",
  "m.mentions": { "user_ids": ["@bot:matrix.org"] }
}

...was NOT detected as a mention because "please reply" doesn't contain @bot.

Fix

Drop the (mentionedInFormattedBody || textMentioned) conjunction:

// mentions.ts:166-172 (after fix)
const metadataBackedUserMention = Boolean(
  params.userId && mentionedUsers.has(params.userId),
);

Metadata-backed user mentions are now trusted on their own, matching the Matrix spec.

Why m.mentions.room is left unchanged

The metadataBackedRoomMention check at line 171 still requires visible @room text alongside m.mentions.room: true. This is intentional: @room mentions have different security implications (spam amplification to all room members), so requiring both metadata AND visible text is a reasonable anti-spam measure. User mentions don't have this concern.

Tests

Updated extensions/matrix/src/matrix/monitor/mentions.test.ts:

  • Before: "does not trust forged m.mentions.user_ids without a visible mention" → asserted wasMentioned: false
  • After: "detects mention via m.mentions.user_ids even without visible text mention (#64785)" → asserts wasMentioned: true + hasExplicitMention: true

The existing test for room mentions (requiring both m.mentions.room and visible @room text) is unchanged.

Scope

  • Files: mentions.ts (+6/-3), mentions.test.ts (+8/-5)
  • Production LOC: 1 condition removed from 1 boolean expression
  • oxlint clean
  • Zero competing PRs (only closed #51106 in adjacent area — different fix scope)

cc @BunsDev — Matrix channel. Credit to @guci314 for the clear reproduction with proper m.mentions metadata in #64785.

Changed files

  • CHANGELOG.md (modified, +5/-0)
  • extensions/matrix/src/matrix/monitor/handler.test.ts (modified, +27/-3)
  • extensions/matrix/src/matrix/monitor/mentions.test.ts (modified, +21/-3)
  • extensions/matrix/src/matrix/monitor/mentions.ts (modified, +4/-0)

Code Example

"groups": {
  "!roomId:localhost": {
    "requireMention": true,
    "enabled": true
  }
}

---

{
  "msgtype": "m.text",
  "body": "@欢欢 please reply",
  "format": "org.matrix.custom.html",
  "formatted_body": "<a href=\"https://matrix.to/#/@huanhuan:localhost\">@欢欢</a> please reply",
  "m.mentions": {
    "user_ids": ["@huanhuan:localhost"]
  }
}
RAW_BUFFERClick to expand / collapse

Summary

When requireMention: true is set for a Matrix group room, messages containing valid m.mentions metadata are not detected as mentions, causing all agents to ignore the message. This effectively makes requireMention: true unusable for rooms where messages may come from non-OpenClaw Matrix clients or bots.

Environment

  • OpenClaw: 2026.4.9
  • Matrix homeserver: Synapse (Docker, localhost)
  • Node: 25.9.0

Steps to Reproduce

  1. Configure a Matrix group room with requireMention: true:
"groups": {
  "!roomId:localhost": {
    "requireMention": true,
    "enabled": true
  }
}
  1. From a non-OpenClaw Matrix client (e.g., Element, or a standalone bot using matrix-bot-sdk), send a message to the room with proper m.mentions:
{
  "msgtype": "m.text",
  "body": "@欢欢 please reply",
  "format": "org.matrix.custom.html",
  "formatted_body": "<a href=\"https://matrix.to/#/@huanhuan:localhost\">@欢欢</a> please reply",
  "m.mentions": {
    "user_ids": ["@huanhuan:localhost"]
  }
}
  1. Observe: no agent responds. The mentioned agent (@huanhuan:localhost) does not get triggered.

  2. Set requireMention: false → the same message triggers all agents (including unmentioned ones).

Expected Behavior

With requireMention: true, the agent whose userId appears in m.mentions.user_ids AND whose name/userId appears in the formatted_body matrix.to link should be triggered. Other agents should remain silent.

Actual Behavior

No agent is triggered. The message is silently dropped for all agents.

Analysis

Looking at extensions/matrix/src/matrix/monitor/mentions.ts, resolveMentions() checks:

  1. m.mentions.user_ids contains the agent's userId AND formatted_body or text contains a matching pattern (line 166-170)
  2. formatted_body has a matrix.to link for the agent (line 158-165)
  3. Text matches mentionRegexes (line 150-153)

The message I sent satisfies conditions 1 and 2. Possible causes:

  • The sender (@eventbridge:localhost) is in groupAllowFrom but is not an OpenClaw-managed account — perhaps inbound message processing skips mention resolution for certain senders
  • The mentionRegexes auto-generated from identity.name may not match CJK display names correctly
  • There may be an earlier filter that drops the message before resolveMentions() is called

Impact

requireMention: true is the only way to prevent agents from responding to every message in a group chat. Without it, multi-agent rooms suffer from:

  • Agents responding to messages not directed at them ("插嘴" / interrupting)
  • Unnecessary API calls and token consumption
  • Potential cascading loops when error messages trigger all agents

Currently the only workaround is requireMention: false + adding "only respond to messages addressed to you" in each agent's SOUL.md, which is unreliable (LLM-based filtering).

Related

  • PR #59323 (fix: emit spec-compliant mentions) — fixed the outbound side, but the inbound mention detection appears broken
  • PR #64031 (rate-limit-circuit-breaker) — a workaround for cascading loops caused by requireMention: false

🤖 Generated with Claude Code

extent analysis

TL;DR

The issue can be mitigated by adjusting the mentionRegexes to correctly match CJK display names or by modifying the resolveMentions() function to handle messages from non-OpenClaw Matrix clients.

Guidance

  • Review the mentionRegexes generation to ensure it correctly handles CJK characters and display names.
  • Investigate the resolveMentions() function to determine if it skips mention resolution for messages from certain senders, such as non-OpenClaw Matrix clients.
  • Verify if there are any earlier filters that may be dropping the message before resolveMentions() is called.
  • Consider adding a workaround to the SOUL.md file for each agent to only respond to messages addressed to them, although this is less reliable.

Example

No code example is provided due to the complexity of the issue and the need for further investigation.

Notes

The root cause of the issue is unclear, and further investigation is needed to determine the exact problem. The provided analysis suggests several possible causes, including issues with mentionRegexes and the resolveMentions() function.

Recommendation

Apply a workaround by adjusting the mentionRegexes or modifying the resolveMentions() function, as upgrading to a fixed version is not mentioned in the issue. This is because the issue seems to be related to the handling of inbound messages and the requireMention: true setting, which requires a more targeted fix.

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