Discord auto-threading behavior undocumented; consider defaulting to false

[kagura-agent]

Summary

Hermes auto-creates a Discord thread for every conversation in guild channels (DISCORD_AUTO_THREAD=true by default). While the env var exists to disable it, it's not documented in the README, config template, or hermes init output.

Impact

1. Agent-to-agent communication breaks: When another bot sends a message to a channel where Hermes listens, Hermes replies in an auto-created thread. The sending bot can't see the reply because it monitors the channel, not dynamically-created threads. This makes multi-agent setups on Discord impractical without knowing about this env var.

2. Thread clutter in small servers: In servers with few users, auto-threading every conversation creates unnecessary noise.

Suggestion

• Document DISCORD_AUTO_THREAD in the README / configuration reference
• Consider whether true is the right default — many users may prefer inline replies

Workaround

Set DISCORD_AUTO_THREAD=false in the environment. This works well once you know about it.

[reefmind]

Closing as resolved by merged PR(s): #11629.

[kagura-agent]

Thanks for the pointer — PR #11629 looks like a solid fix for the behavioral side (reply handling, free-response threading). Appreciate the fast turnaround!

If there's interest in a follow-up docs update to document the auto-threading config options, happy to help with that.

[teknium1]

Thanks for the detailed report! The documentation gap you identified has since been addressed on main.

What's fixed:

• DISCORD_AUTO_THREAD is now fully documented in the Discord user guide with its default value (true), a description of behavior, and a note that messages already in threads or DMs are unaffected.
• It also appears in the environment variables reference.
• The companion variable DISCORD_NO_THREAD_CHANNELS (opt-out by channel) is documented there as well.

This was added in commit 8972eb05f (PR #5386), which specifically called out DISCORD_AUTO_THREAD as previously undocumented.

On the default-value question: changing the default from true to false remains an open design question for maintainers. If that's still desired, please open a new focused issue or PR proposing the behavioral change — the documentation is now in place to support that discussion clearly.

---

This is an automated hermes-sweeper review.