Summary

Fixes #8278

When autoThread: true is configured for a Discord channel, replies were sometimes routing to the root channel instead of the thread after the thread was created.

Root Cause

The resolveDiscordReplyDeliveryPlan function was only setting the explicit thread delivery target when a NEW thread was created (when createdThreadId is truthy). For subsequent messages in an existing thread (where threadChannel is set but createdThreadId is null), the delivery target fell back to the originalReplyTarget which relied on message.channelId.

While message.channelId should be the thread ID for thread messages, there could be edge cases where this doesn't resolve correctly, or where the reply target resolution differs.

Fix

Added explicit handling for existing threads: when threadChannel is set (we're in an existing thread) but no new thread was created, explicitly route to channel:${threadChannel.id}. This ensures all replies in a thread context go to the thread, not the root channel.

// When a new thread was created, route to the new thread
if (params.createdThreadId) {
  deliverTarget = `channel:${params.createdThreadId}`;
  replyTarget = deliverTarget;
}
// When in an existing thread (not newly created), ensure we route to the thread
else if (params.threadChannel?.id) {
  deliverTarget = `channel:${params.threadChannel.id}`;
  replyTarget = deliverTarget;
}

Testing

• All existing threading tests pass (7 tests)
• Typecheck passes

Greptile Overview

Greptile Summary

This PR updates resolveDiscordReplyDeliveryPlan to explicitly set deliverTarget/replyTarget to the current thread’s channel ID not only when a new thread is created (createdThreadId), but also when threadChannel indicates the message is already in an existing thread. This prevents autoThread: true follow-up replies from occasionally falling back to the root channel via the original replyTarget.

Change is localized to src/discord/monitor/threading.ts and keeps existing reply-reference behavior by disabling references when the delivery target is rewritten away from the original reply target.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk; it’s a small, well-scoped routing fix.
• The change only affects how reply/delivery targets are chosen in one function, adds a straightforward missing branch for existing threads, and preserves prior behavior for non-thread contexts. No new dependencies or API changes are introduced.
• No files require special attention

Context used:

• Context from dashboard - CLAUDE.md (source)
• Context from dashboard - AGENTS.md (source)