fix(auto-reply): hide direct-chat metadata without sender-id sentinel by obviyus · Pull Request #24373 · openclaw/openclaw

obviyus · 2026-02-23T09:43:40Z

Supersedes #22054 (author branch was force-reset and maintainers no longer had push rights).

What changed

Hide message_id, message_id_full, reply_to_id, sender_id, and sender in direct chats in buildInboundUserContextPrefix.
Keep direct/group classification based on normalized ChatType only (remove sender-id sentinel behavior).
Add direct-chat regression test for hidden message identifiers.
Add group-chat guard test to ensure sender-id string cannot force direct behavior.
Add changelog entry.

Validation

pnpm vitest run src/auto-reply/reply/inbound-meta.test.ts

Greptile Summary

Removes sender-id sentinel behavior that could allow group chats to be misclassified as direct chats. Now hides message_id, message_id_full, reply_to_id, sender_id, and sender metadata strictly based on the normalized ChatType value, preventing spoofing attacks where a malicious sender could set sender_id to a special value like openclaw-control-ui to trigger direct-chat handling in a group context.

Fixed security issue where sender-id values could override chat type classification
Added regression test for direct chat metadata hiding
Added guard test to ensure group chats with sentinel sender-ids remain classified as group chats
Updated existing tests to use ChatType: "group" instead of "direct" for tests that verify group metadata visibility

Confidence Score: 5/5

This PR is safe to merge with minimal risk - it fixes a security vulnerability and has comprehensive test coverage
The changes are straightforward and well-tested. The fix correctly addresses the security issue by ensuring chat type classification is based solely on the normalized ChatType field rather than allowing sender-id values to override it. All modified tests now correctly use ChatType: "group" for group chat scenarios, and two new tests specifically guard against the vulnerability. The logic changes are confined to conditional checks that hide metadata in direct chats, which is the intended behavior.
No files require special attention

_{Last reviewed commit: 1212258}

obviyus · 2026-02-23T09:55:42Z

Merged with admin CI bypass per maintainer instruction. Head pinned: ca54355.

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

Lanfei · 2026-02-25T08:36:02Z

@obviyus After this PR, agents in direct chats can no longer access sender_id. This breaks proactive messaging scenarios — e.g. the message tool needs a target to send to the user, but there's no reliable way to obtain one from the current metadata. What's the intended approach for this?

obviyus · 2026-02-25T08:46:13Z

@Lanfei Good catch! This was intentional: we removed sender_id from the untrusted direct-chat conversation block.

Proactive sends should use the trusted route target (chat_id in inbound metadata) or rely on message-tool current-session target inference (no explicit target needed for same chat).

If you have a concrete flow where those are insufficient, please let me know. I can take a look.

Lanfei · 2026-02-25T09:13:07Z

@obviyus Thanks! One follow-up: chat_id from trusted metadata doesn't seem to be directly usable as target in the message tool across all channels. For example, "telegram:123456789" fails looksLikeTargetId() in target-resolver.ts and falls through to a directory lookup that fails for DMs. Is there a channel-agnostic way to use chat_id as target for proactive sends to a different user (not a reply to the current session)?

obviyus · 2026-02-25T09:20:06Z

@Lanfei With channel=telegram, target="telegram:" is treated as a direct id (no directory lookup). The current limitation is channel selection, not Telegram id parsing: for proactive sends to another user, you must pass both channel and target (unless sending in current-session context where channel/target can be inferred).

Maybe we can also add a follow-up enhancement to infer channel from provider-prefixed targets when channel is omitted.

Lanfei · 2026-02-25T09:33:58Z

@obviyus Thanks for the clarification! Just to confirm: is using chat_id (from trusted inbound metadata) as target — combined with channel — a universal approach that works across all channels?

Also, in a multi-account setup, the message tool requires the correct account_id. What's the recommended way for an agent to obtain it?

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

@jd316

…openclaw#24373) thanks @jd316 Co-authored-by: jd316 <138361777+jd316@users.noreply.github.com> Co-authored-by: obviyus <22031114+obviyus@users.noreply.github.com>

obviyus added 2 commits February 23, 2026 15:11

fix: remove sender-id direct-chat override

79a9135

docs: add changelog entry for inbound metadata fix

1212258

openclaw-barnacle bot added size: S maintainer Maintainer-authored PR labels Feb 23, 2026

obviyus self-assigned this Feb 23, 2026

obviyus added 2 commits February 23, 2026 15:16

docs: update changelog PR reference for inbound metadata fix

d7f7a16

docs: credit jd316 in inbound metadata changelog entry

ca54355

obviyus merged commit 2247b81 into main Feb 23, 2026
25 of 26 checks passed

obviyus deleted the fix/22054-inbound-meta-direct-hide branch February 23, 2026 09:55

vabole mentioned this pull request Feb 23, 2026

ops: decision needed for upstream sync (3 disputed files) vabole/openclaw#3

Merged

3 tasks

github-actions bot mentioned this pull request Feb 24, 2026

上游更新: v2026.2.23, v2026.2.22 — 114 P0 + 122 P1 待合并 jiulingyun/openclaw-cn#328

Closed

jiulingyun mentioned this pull request Feb 24, 2026

upstream(auto-reply): 移植 4 个冲突 commit (P1) — v2026.2.21→v2026.2.23 jiulingyun/openclaw-cn#427

Closed

6 tasks

Oceanswave mentioned this pull request Feb 28, 2026

Agents can't react to DM messages — message_id stripped from inbound context #29503

Open

Lucenx9 mentioned this pull request Mar 2, 2026

fix(whatsapp): restore direct inbound metadata for relay agents #31969

Merged

20 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(auto-reply): hide direct-chat metadata without sender-id sentinel#24373

fix(auto-reply): hide direct-chat metadata without sender-id sentinel#24373
obviyus merged 4 commits intomainfrom
fix/22054-inbound-meta-direct-hide

obviyus commented Feb 23, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

Uh oh!

obviyus commented Feb 23, 2026

Uh oh!

Lanfei commented Feb 25, 2026

Uh oh!

obviyus commented Feb 25, 2026

Uh oh!

Lanfei commented Feb 25, 2026

Uh oh!

obviyus commented Feb 25, 2026

Uh oh!

Lanfei commented Feb 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

obviyus commented Feb 23, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed

Validation

Greptile Summary

Confidence Score: 5/5

Uh oh!

Uh oh!

obviyus commented Feb 23, 2026

Uh oh!

Lanfei commented Feb 25, 2026

Uh oh!

obviyus commented Feb 25, 2026

Uh oh!

Lanfei commented Feb 25, 2026

Uh oh!

obviyus commented Feb 25, 2026

Uh oh!

Lanfei commented Feb 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

obviyus commented Feb 23, 2026 •

edited by greptile-apps bot

Loading