hermes - 💡(How to fix) Fix Bug: Discord create_thread does not rebind active conversation/context to the new thread

Bug Description

When Hermes creates a new Discord thread successfully, subsequent tool calls and follow-up agent output can remain bound to the parent channel instead of the new thread.

This makes thread creation insufficient for actual handoff/continuation workflows. The thread exists, but the conversation/session does not move there.

Steps to Reproduce

1. In a Discord channel, ask Hermes to create a new thread.
2. Confirm the thread is created successfully.
3. Continue with additional tool calls or follow-up work that should logically continue in that new thread.
4. Observe where subsequent messages/tool-driven output actually appear.
5. As a control, explicitly send a message to the thread using a fully-qualified Discord target (discord:<parent_channel_id>:<thread_id>).

Expected Behavior

After creating a Discord thread for continuation/handoff, subsequent agent activity should continue in the new thread, or Hermes should clearly distinguish that create_thread is only resource creation and does not switch execution context.

At minimum, if the intended behavior is handoff/continuation, Hermes should:

• bind the active session/conversation to the new thread, and
• route subsequent tool-driven output and follow-up there.

Actual Behavior

Observed behavior:

• thread creation succeeds
• explicit thread-targeted delivery works
• but normal follow-up activity stays in the parent channel

So the bug does not appear to be Discord thread delivery itself. The problem appears to be missing session/context rebinding after thread creation.

Environment

• OS: Linux (Unraid-hosted Hermes environment)
• Hermes surface: Discord gateway
• Version/Commit: current local checkout/runtime at time of report
• Python version: unknown at report time
• Browser (if applicable): N/A

Error Output

No explicit runtime error was surfaced during reproduction.

Behavioral failure only:
- thread is created
- explicit send-to-thread works
- ordinary follow-up remains in parent channel

Additional Context

What was verified

• Discord thread creation succeeds.
• Explicit thread-targeted delivery using discord:<parent_channel_id>:<thread_id> succeeds.
• Therefore this looks like a conversation/session handoff bug, not a raw Discord API send failure.

Relevant code paths inspected

Low-level Discord thread creation path

In tools/discord_tool.py, create_thread appears to only:

• create the thread
• return metadata like success, thread_id, and name

It does not appear to:

• update origin/current conversation context
• update session source
• switch the session binding to the new thread
• dispatch follow-up execution into that new thread

Existing handoff path already has the right primitives

In gateway/run.py, the CLI→gateway handoff flow already appears to do the important rebinding work:

• create a handoff thread
• compute an effective thread id
• build a SessionSource(... thread_id=...)
• compute a destination session_key
• call session_store.switch_session(...)
• dispatch a synthetic internal event into the new destination

That suggests Hermes already has an existing pattern for:

• creating a thread
• rebinding session identity to that thread
• continuing execution there

So this bug may be a missing integration between generic Discord thread creation and session/context rebinding.

Existing issues checked first

I checked for related issues before drafting this one. I found related but non-matching issues, including:

• a broad cross-surface session continuity feature request
• a Discord long-message handoff/chunking bug

I did not find an issue matching this specific problem:

• Discord thread creation succeeds
• explicit sends to the thread work
• but the active conversation remains bound to the parent channel

Suggested direction

Possible fixes:

1. After Discord thread creation, provide a proper session rebind path so the active conversation moves into the new thread.
2. Reuse or adapt the existing handoff/session-switching pattern already present in the gateway handoff flow.
3. If create_thread is intentionally low-level and should not switch context, document that clearly and expose a higher-level “create thread and continue there” operation.