Slack thread sessions do not include parent/root message content

Summary

When a user replies in a Slack DM thread (replying to the bot's own message), OpenClaw creates a new thread session but does not include the content of the message being replied to. The agent receives reply_to_id in runtime context metadata, but has no access to the actual text/content of that message. This makes it impossible for the agent to understand the context of the user's reply.

Environment

• OpenClaw: 2026.5.7
• Channel: Slack (DM, session.dmScope: per-channel-peer)
• Thread config: all defaults (thread.historyScope: thread, thread.inheritParent: false, thread.initialHistoryLimit: 20)

Steps to reproduce

1. Bot sends a top-level message in a Slack DM (e.g., a confirmation, a summary, or any actionable message).
2. User replies in-thread to that message (e.g., "actually, change that to Sunday 12:30").
3. OpenClaw creates a new thread session with key agent:<agentId>:slack:direct:<userId>:thread:<threadTs>.

Expected behavior

The thread session should include the content of the parent/root message that the user is replying to, so the agent has the context needed to understand the reply.

Actual behavior

The thread session receives:

• ✅ Full system prompt (project context files, AGENTS.md, SOUL.md, etc.)
• ✅ The user's reply text
• ✅ Runtime context metadata including reply_to_id pointing to the parent message
• ❌ The content of the parent/root message is missing

The agent sees reply_to_id: "1234567890.123456" but has no way to resolve that to the actual message content. When the user's reply is a correction or follow-up ("actually it's Sunday," "change the time," "apologize and fix that"), the agent has no idea what is being corrected.

Transcript evidence

A sanitized excerpt from the thread session transcript shows the issue:

// Line 0-2: session header, model_change, thinking_level_change (normal)

// Line 3: model-snapshot (normal)

// Line 4: FIRST user message — this is ALL the context the agent gets:
{
  "type": "message",
  "message": {
    "role": "user",
    "content": [{"type": "text", "text": "actually it's Sunday 12:30 pm - apologize and correct, include an ICS, add it to my calendar"}]
  }
}

// Line 5: runtime-context — has reply_to_id but NOT the parent message content:
{
  "type": "custom_message",
  "customType": "openclaw.runtime-context",
  "content": "...\n\"reply_to_id\": \"<parent_ts>\",\n..."
}

// No other messages before the agent's first response.
// The parent message (bot's original confirmation) is completely absent.

The agent then has to guess what's being corrected — and in practice, it guesses wrong.

Impact

This is a recurring, high-impact issue. Documented incidents over a 7-day period:

Incident 1 (2026-05-01): Thread session context loss after update

• Agent lost track of what was posted in a previous message within the same Slack thread.
• Symptom: agent in a new session cannot see its own prior messages and asks "what are you confirming?"
• Noted as a regression after an OpenClaw update.

Incident 2 (2026-05-05): Lost thread context entirely

• User assigned a research task in a Slack thread. Agent replied in-thread that it would handle it, then lost context entirely in the following turn. When the user followed up, the agent had no memory of the original request.
• Root cause: Thread-scoped session context did not persist to the next turn.

Incident 3 (2026-05-08): Context loss on Haiku model

• In a multi-turn Slack thread, agent lost context from the prior turn and repeatedly asked for information that was clearly stated in the thread (3 consecutive times).
• The user had to provide a screenshot proving the information was already there.
• Compounding factor: Haiku's smaller context window, but the root issue is thread session isolation.

Incident 4 (2026-05-08): Wrong action due to missing parent context

• User replied in-thread to the bot's WhatsApp confirmation message saying "actually it's Sunday 12:30 pm — apologize and correct."
• Agent had zero context about the parent message, searched unrelated data, and sent a correction email to the wrong person about the wrong meeting — causing real-world damage that required cleanup.
• This is the most severe manifestation: the agent took confident but completely wrong action because it lacked the context of its own prior message.

Analysis

The gap in the current design

1. thread.initialHistoryLimit (default 20): Fetches existing thread messages when a new thread session starts. But in the most common case — user replies to a bot message, creating a new thread — there are zero prior thread replies to fetch. The root/parent message itself appears not to be included in the fetched history.

2. thread.inheritParent (default false): Copies the entire parent conversation transcript. This is heavy-handed — the agent doesn't need the full conversation history, just the single message being replied to. Setting this to true would also expose unrelated conversation context.

3. reply_to_id in runtime context: The metadata correctly identifies which message is being replied to, but the content of that message is never resolved or included.

What's needed

A mechanism to include the content of the parent/root message when creating a new thread session. This could be:

• Option A: Automatically resolve reply_to_id and inject the parent message content into the session as a prior assistant/user message (depending on who sent it).
• Option B: A new config option like thread.includeRootMessage (default true) that fetches the root message text and includes it at the top of the thread session.
• Option C: Ensure initialHistoryLimit includes the root/parent message when fetching thread history via Slack's conversations.replies API (which does return the root as the first message).

Option C may be the simplest fix, as Slack's conversations.replies already includes the parent message — OpenClaw may just need to not filter it out.

Workaround

Agents can call sessions_history to try to read the thread history, but this only returns messages from the current session — which, for a newly created thread session, is just the triggering user message. The parent message was generated in a different session (the main DM session), so it's not accessible via session history tools from the thread session.

There is currently no reliable programmatic workaround. Agents must either:

1. Ask the user to repeat the context (poor UX, defeats the purpose of threading).
2. Search memory/email/files to try to reconstruct context (unreliable, as demonstrated by Incident 4).

Suggested priority

High. This causes the agent to take confident but wrong actions (not just fail gracefully). The failure mode is silent — the agent doesn't know what it doesn't know — which makes it especially dangerous for agents with tool access (email, calendar, messaging).