openclaw - 💡(How to fix) Fix Discord threads should inherit parent /model override without parent transcript fork [1 comments, 2 participants]

Summary

Discord auto-thread workflows currently do not have a clean way to inherit the parent channel's session-level /model override without also enabling parent transcript/session inheritance.

The desired UX is:

1. In a Discord parent channel, switch the model with /model.
2. Ask OpenClaw in that channel with auto-threading enabled.
3. OpenClaw creates a thread and replies there.
4. The new thread uses the parent channel's stored model override, but starts with an isolated transcript.

Current behavior

With the safe/default Discord thread behavior, thread sessions are isolated from the parent channel, so the new thread does not inherit the parent channel's /model override.

The closest workaround is enabling:

{
  "channels": {
    "discord": {
      "thread": {
        "inheritParent": true
      }
    }
  }
}

That makes model override inheritance possible because the reply path can see the parent session key, but it also changes transcript/session semantics: the thread is treated as a child of the parent session and can fork or inherit parent conversation history. That is exactly the behavior that was made opt-in after the Discord thread context-pollution fixes.

Why this is a problem

channels.discord.thread.inheritParent couples two separate concerns:

• inherit the parent session's model choice / provider override
• inherit or fork the parent transcript/session history

For auto-thread usage, those should be independently configurable. Users often want the parent channel's selected model to carry into newly created threads, but do not want unrelated parent-channel history copied into each thread.

This leaves only awkward choices today:

• Keep inheritParent: false: clean thread isolation, but new threads lose the parent /model choice.
• Set inheritParent: true: parent /model can carry over, but transcript/session inheritance risks context pollution and token bloat.
• Manually run /model in every new thread, which defeats the point of auto-threading.

Expected behavior

There should be a model-only inheritance path for Discord threads that is independent of parent transcript inheritance.

Possible acceptable designs:

• Add a separate Discord thread option such as channels.discord.thread.inheritParentModelOverride.
• Preserve/pass the native Discord parent channel id or parent session model metadata as a model-override candidate without setting ParentSessionKey for transcript forking.
• Copy only the parent's providerOverride / modelOverride into the newly created thread session at thread creation time.

Precedence should preserve explicit thread-local overrides:

1. Thread session /model override, if set.
2. Parent channel/session /model override, when model-only inheritance is enabled or otherwise intended for auto-threads.
3. Config-level channel model fallback, if applicable.
4. Agent default model.

Related issues

• #53447 covers modelByChannel parent-channel fallback for Discord threads. This issue is about session-level /model stored overrides, not only config-level modelByChannel.
• #69907 and #41823 cover Discord parent transcript/session inheritance causing context pollution. Those fixes make parent transcript inheritance opt-in, but this request is for model-only inheritance without reintroducing transcript inheritance.
• #30760 is the older stale modelByChannel version of the parent-channel model inheritance problem.
• #62757 is related to persistent per-channel model overrides, but does not address transient /model override inheritance into auto-created threads.

Environment

Observed while using Discord auto-threads on OpenClaw 2026.4.24. The issue is in the behavior split between Discord thread parent inheritance and model override resolution, so it should be independent of the specific model/provider.