Issue: Discord — Bot Cannot Auto-Initiate Threads from Text-Channel Mentions

Summary

OpenClaw's Discord adapter can reply in existing threads but cannot create new threads from messages posted in parent text channels. This forces users to manually start threads before the bot can thread its replies, breaking conversational flow.

This issue does not affect forum channels (type 15) where OpenClaw already auto-creates thread posts via create_thread. The gap is specifically for regular text channel → thread creation.

Expected Behavior

When a user @mentions the bot in a server text channel, the bot should automatically create a thread from that mention message and post its response inside the thread — matching the behavior of Discord's native threading UI and other bot frameworks.

Actual Behavior

The bot replies flat in the parent text channel, not in a thread. After the user manually creates a thread and posts in it, the bot can reply in that existing thread (because thread_id metadata is already present).

Root Cause

OpenClaw's Discord gateway lacks an auto-threading hook in its inbound on_message event handler.

Hermes Reference Implementation

The Hermes Agent Discord adapter (gateway/platforms/discord.py, ~lines 4218–4237) handles this by:

1. Detecting if the incoming message is in a text channel (not already a thread or DM)
2. Checking whether DISCORD_AUTO_THREAD is enabled (default: true)
3. Calling _auto_create_thread(message) which invokes:

   thread = await message.create_thread(
       name=thread_name,
       auto_archive_duration=1440,
   )

4. Storing the thread ID in a persistent tracker so follow-up responses route correctly

OpenClaw Gap

OpenClaw's Discord adapter (dist/*.js — provider/gateway layer) has no equivalent logic. Its outbound delivery can send to thread_id when explicitly passed, but the inbound handler never creates a thread from the triggering message.

Discord API Endpoints Required

Option A: Thread from Existing Message (Recommended)

POST /channels/{channel_id}/messages/{message_id}/threads
Content-Type: application/json
Authorization: Bot {token}

{
  "name": "Thread title here",
  "auto_archive_duration": 1440
}

• name — required, max 100 characters
• auto_archive_duration — optional, one of: 60, 1440 (default), 4320, 10080

This is the cleanest approach because the message acts as the thread starter automatically.

Option B: Standalone Thread in Channel

POST /channels/{channel_id}/threads
Content-Type: application/json
Authorization: Bot {token}

{
  "name": "Thread title here",
  "auto_archive_duration": 1440,
  "type": 11
}

• type — 11 for PUBLIC_THREAD, 12 for PRIVATE_THREAD
• This creates an empty thread; you must then send the starter message separately.

Proposed Fix

Where to Patch

The fix belongs in OpenClaw's Discord gateway inbound message handler (the on_message / messageCreate event listener in the Discord provider).

Pseudocode

// Pseudocode for OpenClaw Discord provider
client.on('messageCreate', async (message) => {
  // Skip DMs, threads, and system messages
  if (message.channel.isDMBased() || message.channel.isThread()) return;

  // Check if auto-threading is enabled (env/config flag)
  if (!shouldAutoThread(message)) return;

  try {
    // Create thread from the user's mention message
    const thread = await message.startThread({
      name: deriveThreadName(message.content),
      autoArchiveDuration: 1440,
    });

    // Store thread ID in session context/metadata
    session.threadId = thread.id;

    // Continue processing — outbound replies will route to thread.id
  } catch (err) {
    // Fallback: reply flat in channel if thread creation fails
    console.warn('Thread creation failed:', err);
  }
});

Key Implementation Details

1. message.startThread() vs channel.threads.create()

   • message.startThread() (discord.js) / POST .../messages/{id}/threads (REST) — threads the specific message
   • channel.threads.create() / POST /channels/{id}/threads — creates a standalone thread
   • Prefer the message-based approach for natural threading UX.

2. Thread Name Derivation

   • Strip Discord mention syntax (<@123>, <@!123>, <#123>)
   • Take first 80 chars of cleaned content, truncate with ... if needed
   • Fallback: "OpenClaw Thread" or user display name

3. Persistence

   • Track created thread IDs per channel/session so follow-up tool calls (e.g., send_message) include thread_id in outbound metadata without explicit user action.

4. Rate Limiting

   • Discord threads endpoint is rate-limited. Add backoff/retry or debounce rapid sequential messages from the same user.

5. Configurability

   • Add an opt-out flag (e.g., OPENCLAW_DISCORD_AUTO_THREAD=false) for users who prefer flat replies.
   • Respect no_thread_channels list (channel IDs where flat replies are preferred).

Reproduction Steps

1. Invite OpenClaw bot to a server text channel.
2. Send: @OpenClaw hello there in the text channel.
3. Expected: Bot creates a thread from your message and replies inside it.
4. Actual: Bot replies flat in the text channel.
5. Now manually start a thread from your message.
6. Send another message in that thread.
7. Result: Bot replies correctly inside the existing thread.

Environment

• OpenClaw Version: 2026.5.7
• Platform: Discord
• Channel Type: Regular text channel (type 0), not forum (type 15)

Additional Context

• This issue does not affect forum channels (type: 15), where OpenClaw already correctly uses create_thread with a starter post.
• The gap is confirmed by comparing OpenClaw's dist JS files (no message.startThread or thread creation in on_message paths) against Hermes' gateway/platforms/discord.py (~line 4220 auto-thread logic).
• The Discord Developer Docs document the POST /channels/{channel_id}/messages/{message_id}/threads endpoint.

Priority

Medium — there's a functional workaround (let Hermes or the user manually create the thread first), but it breaks the seamless conversational UX that users expect from modern Discord bots.

Drafted with Hermes Agent — feel free to edit before posting.