Skip to content

Proactive messages not visible in session context, causing conversation desynchronization #88757

Description

@aaronade0

Problem: Proactive agent messages are invisible in session context, causing desynchronization

Summary

When an agent sends a proactive message (e.g., heartbeat updates, scheduled reports, reminders) via message(action=send), the message appears in the target channel (e.g., Telegram) but is not injected into the agent's session context. This leads to a desynchronized conversation where the user replies to a message the agent doesn't "remember" sending.

Real-world impact

Example scenario:

  1. Agent sends a KI model check report to Telegram via scheduled job
  2. User replies in Telegram: "Regarding your KI model check..."
  3. Agent receives the reply but has no context of the original report
  4. Agent is confused about what the user is referring to

This breaks the conversational flow and makes proactive messaging unreliable.

Current behavior

Action Channel delivery Session context Result
User sends message ✅ Delivered ✅ Stored in session ✅ Context intact
Agent replies normally ✅ Delivered ✅ Stored in session ✅ Context intact
Agent proactive send (message) ✅ Delivered to channel NOT in session Desynchronized

Expected behavior

Proactive messages should appear in the session context just like any other message, so the agent can reference them when the user replies.

Possible solutions

Option A: Session-aware proactive sends

Allow proactive messages to be sent "through" a specific session, so they appear in both the channel and the session history.

Option B: Automatic session injection

When a proactive message is sent, automatically inject it into all active sessions for that user/channel combination.

Option C: Global context buffer

Maintain a shared context buffer per user that includes ALL messages regardless of origin, which sessions can reference.

Environment

  • OpenClaw version: 2026.x.x
  • Channels affected: All (Telegram, Discord, etc.)
  • Use case: Heartbeat checks, scheduled reports, reminders

Additional context

This is particularly problematic for:

  • Heartbeat agents sending periodic updates
  • Cron jobs delivering scheduled reports
  • Reminder systems where the user replies to a reminder

The workaround is documenting proactive messages in memory/ files, but this is brittle and doesn't solve the core architectural issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.staleMarked as stale due to inactivity

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions