Summary

When multiple messages are sent rapidly in a Slack thread, queued messages lose their thread context and are posted to the main channel instead of the thread, despite replyToMode: "all" being configured.

Steps to reproduce

1. Configure Slack channel with replyToMode: "all" and thread.historyScope: "thread"
2. Start a conversation in a Slack thread
3. Send a message to the bot (e.g., "What is the highest mountain?")
4. Before the bot responds, send another message (e.g., "What is the latest iPhone?")
5. Observe the bot's responses

Expected behavior

Both responses should be posted to the thread where the original messages were sent, since replyToMode: "all" is configured.

Actual behavior

• First response (to the queued message): Posted to the main channel instead of the thread
• Second response: Correctly posted to the thread

The first queued message loses its thread context during queue processing.

Environment

• OpenClaw version: 2026.1.29 (commit a5b4d22)
• OS: macOS (Darwin 25.2.0 arm64)
• Install method: npm (mise)
• Channel: Slack (socket mode)

Configuration

{
  "channels": {
    "slack": {
      "mode": "socket",
      "enabled": true,
      "replyToMode": "all",
      "replyToModeByChatType": {
        "direct": "all",
        "group": "all",
        "channel": "all"
      },
      "thread": {
        "historyScope": "thread"
      }
    }
  }
}

Logs or screenshots

Screenshot showing the issue:

• "Good morning" response → Posted to thread (correct. Japanese tho)
• "Good afternoon" response → Posted to main channel (incorrect)
• "Good evening" response → Posted to main channel (incorrect)

Additional context

The issue appears to be related to how queued messages are processed. When a message is queued (because the bot is busy processing a previous message), the thread ID (threadId) seems to be lost or not properly propagated to the delivery context.

Possible location in codebase:

• Message queue processing logic
• Thread context propagation during queue handling
• Slack delivery context management

Workaround

Wait for the bot to respond before sending the next message to avoid queueing.