openclaw - 💡(How to fix) Fix Group/topic reply context not propagated to codex transport (suspected sibling of #83767)

Summary

When a user sends a Telegram reply in a group/topic chat to a prior message that the bot has not previously seen (i.e. not in the bot's chat window), and the reply text mentions the bot, the bot receives only the bare user text via the codex transport. None of the inbound-context blocks that buildInboundUserContextPrefix would normally produce — Conversation info, Reply target of current user message, Reply chain — are appended to the prompt.

The model therefore has no awareness that the message is a reply, and cannot see what it is a reply to. From the user's perspective the reply metadata vanishes between Telegram and the model.

This looks like a sibling regression to #83767 (fixed for the DM path by #83953 in 5.19). The group/topic + codex code path appears uncovered by that fix.

Environment

• OpenClaw 2026.5.20
• Main agent uses openai provider via the codex plugin (plugins.entries.openai.enabled: true)
• Forum-style group chat with topics enabled
• Reply target is an earlier user message that does not mention the bot (so the bot never ingested it into its session history / chat window)

Repro

1. In a forum/group with topics, user A sends an ordinary message that does not mention the bot.
2. User A sends a follow-up message that:
   • is a Telegram-level reply_to_message to the message from step 1, and
   • includes an @bot mention to wake the bot up.
3. Bot replies, but with no awareness that the message is a reply at all, and no access to the reply target's text.

Expected

Per buildInboundUserContextPrefix in get-reply-*.js, since chatWindowCoversReplyContext is false here (the reply target's message_id is not in chatWindowMessageIds), the prefix should include at least one of:

• Reply chain of current user message (untrusted, nearest first): (when replyChainPayload.length > 0), or
• Reply target of current user message (untrusted, for context): (when replyToBody is present),

alongside the always-on Conversation info (untrusted metadata): block carrying reply_to_id, sender_id, etc. That prefix should then be prepended to the prompt via prependCurrentInboundContext.

Actual

The codex rollout payload contains only the bare user text:

{
  "type": "message",
  "role": "user",
  "content": [{"type": "input_text", "text": "@<bot> <user text>"}]
}

No Conversation info, Reply target, Reply chain, or Sender blocks. Effectively as if currentInboundContext were undefined for this code path, or its prepend were skipped further downstream.

Suspected code path

run-attempt-*.js:

prompt: prependCurrentInboundContext(promptText, params.currentInboundContext)

get-reply-*.js:

currentInboundContext: !params.isBareSessionReset && currentInboundContextText ? {
  text: currentInboundContextText,
  ...
} : undefined

For the group/topic + codex transport combination, currentInboundContext appears to be undefined (or its prepend is bypassed), so only the raw prompt text reaches the model.

Related

• #83767 (closed by #83953) — same class of bug, DM path. The fix shape there may need to be replicated for group/topic + codex.