Summary

When a cron job sends a proactive message to a Telegram DM topic (thread), the outbound delivery creates a session with one routing key, but when the user replies in the same thread, the inbound message routes to a different session key. This breaks session continuity for cron-initiated conversations.

Problem

We have an isolated cron job (agentId: "finance") that:

1. Creates a new Telegram DM topic (e.g., "ZenMoney — 10.05")
2. Sends an operations report via message tool to that topic
3. Waits for the user to reply with confirmations

Outbound delivery session key:

agent:finance:telegram:finance:direct:104506878:thread:174872

Inbound reply session key:

agent:finance:telegram:finance:direct:104506878:thread:104506878:174872

The difference: the inbound key includes the peer ID (104506878) because dmScope is per-account-channel-peer. The outbound key does not include the peer because it was created by the bot, not by a user message.

This means when the user replies to the cron-generated report, OpenClaw creates a new session with no context from the cron run. The agent cannot see the report it just generated, nor the operation mappings.

Config context

{
  session: {
    dmScope: "per-account-channel-peer",
    reset: { mode: "idle", idleMinutes: 1440 }
  },
  channels: {
    telegram: {
      dm: { threadReplies: "inbound" },
      accounts: {
        finance: { /* separate bot account */ }
      }
    }
  }
}

Why existing solutions don't work

1. sessionTarget: "main" — requires payload.kind: "systemEvent", cannot run full agent workflows (export, sync, message tool calls). Need agentTurn which requires isolated.

2. sessionTarget: "session:xxx" — named session persists across cron runs, but inbound DM replies still route to the routing-based key, not the named session.

3. sessionTarget: "current" — binds to the session active at cron creation time, not dynamically.

4. sessionKey on cron job — threadId changes daily (new topic per day), so we can't hardcode it. Even if we could, the agent has no API to create a session with an arbitrary routing key.

5. File-based workaround — works (cron writes mapping to disk, new session reads it), but this is a workaround for what seems like an architectural gap.

Proposed solutions (any of these would help)

Option A: Outbound session key alignment

When a cron agent sends a message via the message tool to a DM thread, create/update the session using the same routing key that would be computed for an inbound reply to that thread. This ensures the user's reply finds the same session.

Option B: Session key override for cron

Allow cron jobs (or agent tool calls) to explicitly set the session routing key, so the cron can create a session that matches the inbound routing pattern.

Option C: Session key aliasing

Allow linking two session keys as aliases, so inbound routing finds the session regardless of which key was used to create it.

Related

• [Bug] Telegram DM topics keep breaking: conflicting fixes suppress message_thread_id for private chats #18974 — DM topic routing keeps breaking (related but different: that's about message_thread_id being suppressed; this is about session key mismatch)
• The workaround described in docs for dmScope: "per-account-channel-peer" doesn't address proactive (cron-initiated) messages

Environment

• OpenClaw 2026.5.4
• Multi-agent setup (main, finance, health, coach)
• Telegram with DM topics enabled
• dmScope: "per-account-channel-peer"