openclaw - ✅(Solved) Fix Envelope timestamps never reach the model (BodyStripped prefers BodyForAgent over Body) [1 pull requests, 5 comments, 2 participants]

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…
GitHub stats
openclaw/openclaw#50098Fetched 2026-04-08 00:59:07
View on GitHub
Comments
5
Participants
2
Timeline
18
Reactions
0
Author
Participants
Timeline (top)
commented ×5cross-referenced ×3mentioned ×3subscribed ×3

Root Cause

In initSessionState, BodyStripped is computed with this priority:

BodyStripped: normalizeInboundTextNewlines(
    bodyStripped ?? ctx.BodyForAgent ?? ctx.Body ?? ...
),
  • ctx.Body = message WITH envelope timestamp ✅
  • ctx.BodyForAgent = raw message body, NO envelope ❌
  • BodyForAgent takes precedence over Body in the fallback chain
  • Downstream, baseBody = sessionCtx.BodyStripped ?? sessionCtx.Body — so BodyStripped (without envelope) always wins

The envelope is correctly applied by formatInboundEnvelope() and assigned to Body, but initSessionState bypasses it by preferring BodyForAgent.

Fix Action

Fixed

PR fix notes

PR #50119: fix(whatsapp): pass Timestamp to finalizeInboundContext

Description (problem / solution / changelog)

Problem

WhatsApp was the only channel plugin that did not pass Timestamp into the inbound context payload. This means envelopeTimestamp: "on" had no effect for WhatsApp messages — the model never saw when messages were sent.

Every other channel correctly sets Timestamp:

  • Discord, Telegram, Signal, Slack, LINE, iMessage, TUI — all pass it ✅
  • WhatsApp: missing

Fix

Add Timestamp: params.msg.timestamp to the finalizeInboundContext call in process-message.ts. The timestamp value (inbound.messageTimestampMs) is already available on the message object.

Fixes #50098

Changed files

  • extensions/whatsapp/src/auto-reply/monitor/process-message.ts (modified, +1/-0)

Code Example

[WhatsApp +1555 2026-01-18 00:19 PST] hello

---

BodyStripped: normalizeInboundTextNewlines(
    bodyStripped ?? ctx.BodyForAgent ?? ctx.Body ?? ...
),

---

// Before (broken):
BodyStripped: normalizeInboundTextNewlines(bodyStripped ?? ctx.BodyForAgent ?? ctx.Body ?? ...),

// After (fixed):
BodyStripped: normalizeInboundTextNewlines(bodyStripped ?? ctx.Body ?? ctx.BodyForAgent ?? ...),

---

{
  "agents": {
    "defaults": {
      "envelopeTimestamp": "on"
    }
  }
}
RAW_BUFFERClick to expand / collapse

Bug Description

envelopeTimestamp: "on" is configured but the model never sees the timestamp envelope on inbound messages. The agent is time-blind — cannot determine when messages were sent without calling session_status.

Expected Behavior

Per docs, with envelopeTimestamp: "on", inbound messages should be wrapped:

[WhatsApp +1555 2026-01-18 00:19 PST] hello

Actual Behavior

Messages arrive as raw text with no envelope prefix. The envelope IS applied to ctx.Body, but never reaches the model.

Root Cause

In initSessionState, BodyStripped is computed with this priority:

BodyStripped: normalizeInboundTextNewlines(
    bodyStripped ?? ctx.BodyForAgent ?? ctx.Body ?? ...
),
  • ctx.Body = message WITH envelope timestamp ✅
  • ctx.BodyForAgent = raw message body, NO envelope ❌
  • BodyForAgent takes precedence over Body in the fallback chain
  • Downstream, baseBody = sessionCtx.BodyStripped ?? sessionCtx.Body — so BodyStripped (without envelope) always wins

The envelope is correctly applied by formatInboundEnvelope() and assigned to Body, but initSessionState bypasses it by preferring BodyForAgent.

Affects

All channels (WhatsApp, Slack, Signal, iMessage, Discord, Telegram, LINE) — not WhatsApp-specific.

Suggested Fix

Swap the priority in initSessionState:

// Before (broken):
BodyStripped: normalizeInboundTextNewlines(bodyStripped ?? ctx.BodyForAgent ?? ctx.Body ?? ...),

// After (fixed):
BodyStripped: normalizeInboundTextNewlines(bodyStripped ?? ctx.Body ?? ctx.BodyForAgent ?? ...),

This ensures the envelope-wrapped Body is used when available, falling back to BodyForAgent only when Body is not set.

Config

{
  "agents": {
    "defaults": {
      "envelopeTimestamp": "on"
    }
  }
}

Environment

  • OpenClaw 2026.3.2
  • macOS (arm64)
  • WhatsApp channel (but affects all channels)

extent analysis

Fix Plan

To fix the issue, we need to update the initSessionState function to prioritize ctx.Body over ctx.BodyForAgent. Here are the steps:

  • Update the initSessionState function as follows:
// Before (broken):
BodyStripped: normalizeInboundTextNewlines(
  bodyStripped ?? ctx.BodyForAgent ?? ctx.Body ?? ...
),

// After (fixed):
BodyStripped: normalizeInboundTextNewlines(
  bodyStripped ?? ctx.Body ?? ctx.BodyForAgent ?? ...
),
  • Ensure that the envelopeTimestamp configuration is set to "on":
{
  "agents": {
    "defaults": {
      "envelopeTimestamp": "on"
    }
  }
}
  • Verify that the formatInboundEnvelope() function is correctly applying the envelope timestamp to ctx.Body.

Verification

To verify that the fix worked, you can:

  • Send a test message through the channel (e.g. WhatsApp) and check that the inbound message is wrapped with the timestamp envelope.
  • Check the ctx.Body and ctx.BodyStripped values in the initSessionState function to ensure that the correct value is being used.

Extra Tips

  • Make sure to test the fix on all affected channels (WhatsApp, Slack, Signal, iMessage, Discord, Telegram, LINE) to ensure that the issue is resolved across all platforms.
  • Consider adding additional logging or debugging statements to verify that the envelopeTimestamp configuration is being applied correctly.

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