Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Discord autoThread mentions can produce duplicate parent-channel and thread replies [3 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73278•Fetched 2026-04-29 06:21:31
View on GitHub
Comments
0
Participants
1
Timeline
8
Reactions
0
Author
solavrcsolavrc
Participants
solavrcsolavrc
Timeline (top)
referenced ×5cross-referenced ×3

Discord channel mentions with autoThread: true can produce two user-visible replies: one manual message.send reply in the parent channel and one normal final response in the created thread.

Root Cause

Discord channel mentions with autoThread: true can produce two user-visible replies: one manual message.send reply in the parent channel and one normal final response in the created thread.

Fix Action

Fixed

PR fix notes

PR #73279: [codex] Fix Discord current-conversation reply guidance

Description (problem / solution / changelog)

Summary

  • Problem: Discord autoThread: true channel mentions can produce a parent-channel message.send reply plus a normal final response in the created thread.
  • Why it matters: users see confusing duplicate replies across two Discord surfaces even though final thread delivery is working.
  • What changed: Codex runtime guidance and the bundled Discord skill now direct normal current-conversation replies through the final assistant response, reserving the message tool for explicit messaging actions.
  • What did NOT change (scope boundary): no Discord delivery mechanics, auto-thread creation logic, or message-tool implementation changed.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #73278
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: the Codex runtime developer instruction told agents to use the OpenClaw messaging tool for channel replies, while the bundled Discord skill broadly said to use message. In an auto-threaded Discord mention, that can steer the model to manually send a parent-channel reply before OpenClaw delivers the normal final response to the created thread.
  • Missing detection / guardrail: there was no test locking in that current-conversation replies should stay on final response delivery rather than message-tool sends.
  • Contributing context (if known): the final thread delivery path appeared to work; the duplicate was caused by prompt/tool guidance encouraging an extra manual send.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: extensions/codex/src/app-server/thread-lifecycle.test.ts
  • Scenario the test should lock in: developer instructions say normal current-conversation replies use final response delivery, and no longer include the older guidance to use the messaging tool for channel replies.
  • Why this is the smallest reliable guardrail: the regression came from injected runtime guidance, so testing the generated developer instructions catches the exact failure vector without depending on model behavior.
  • Existing test that already covers this (if any): none found.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

Discord agents should be less likely to send duplicate current-conversation replies through the message tool when normal OpenClaw final response delivery can route the reply correctly.

Diagram (if applicable)

Before:
Discord mention -> autoThread creates thread -> agent may call message.send(parent) -> final response delivers(thread) -> duplicate replies

After:
Discord mention -> autoThread creates thread -> agent answers in final response -> OpenClaw delivers(thread) -> one normal reply

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: macOS 26.4.1 / Darwin 25.4.0 arm64
  • Runtime/container: npm global OpenClaw 2026.4.26 (be8c246) for the observed behavior; local repo checkout for the fix
  • Model/provider: Codex app-server embedded agent session; exact upstream model for the observed Discord turn is not known
  • Integration/channel (if any): Discord channel with autoThread: true
  • Relevant config (redacted): Discord autoThread: true, includeThreadStarter: true, thread bindings enabled

Steps

  1. Mention OpenClaw in a Discord parent channel configured with autoThread: true.
  2. Observe OpenClaw create a thread for the mention.
  3. Observe the agent send a parent-channel message.send conversational reply and also finish with a final response delivered to the thread.

Expected

  • One normal conversational reply is delivered to the created thread.
  • No extra parent-channel conversational reply is sent through message.send.

Actual

  • The observed 2026.4.26 session sent a manual parent-channel reply and a different final response in the thread.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Evidence summary:

  • The observed session included a message.send call to the parent channel/thread starter, followed by normal final-response delivery to the auto-created thread.
  • The official 2026.4.26 npm package contained runtime guidance equivalent to If sending a channel reply, use the OpenClaw messaging tool... and a bundled Discord skill that broadly said to use message.
  • Local package/runtime copies were compared with npm registry tarballs and matched, so this was not caused by a leftover local bundle edit.

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
    • Compared local OpenClaw package/runtime files against registry tarballs for the relevant versions to rule out a lingering local bundle patch.
    • Confirmed the duplicate path was manual message.send plus normal final response delivery, not double delivery by the Discord final-response path.
    • Ran pnpm exec vitest run extensions/codex/src/app-server/thread-lifecycle.test.ts.
    • Ran pnpm test:extension codex.
  • Edge cases checked:
    • The fix preserves explicit message tool use for non-normal-reply Discord operations such as reads, reactions, notifications, and sends to another conversation.
  • What you did not verify:
    • A live Discord end-to-end run against a locally patched OpenClaw build.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: the new wording might discourage legitimate explicit Discord sends.
    • Mitigation: both runtime and skill text explicitly keep the messaging tool available for reads, reactions, notifications, sending to another conversation, and other explicit messaging actions.

AI-assisted disclosure

  • This PR is AI-assisted.
  • Testing degree: targeted local testing plus the bundled Codex extension test lane.
  • I understand the code and prompt changes in this PR.

Changed files

  • extensions/codex/src/app-server/thread-lifecycle.test.ts (modified, +17/-1)
  • extensions/codex/src/app-server/thread-lifecycle.ts (modified, +1/-1)
  • skills/discord/SKILL.md (modified, +4/-2)

PR #73369: fix(skills/discord): clarify message.send is sideband-only to prevent autoThread duplicate replies (#73278)

Description (problem / solution / changelog)

Summary

Fixes #73278. When a Discord channel is configured with autoThread: true, mentions produce two user-visible replies: a manual message.send in the parent channel and the normal final assistant response delivered to the auto-created thread. The reporter traced this to two prompt sources telling the agent to use the message tool for channel replies — the global Codex developer instruction (extensions/codex/src/app-server/thread-lifecycle.ts:226) and the bundled Discord skill at skills/discord/SKILL.md.

The Codex instruction is shared across all channels, so I'd rather leave it to the maintainers to decide whether to narrow it. This PR only adds a Discord-specific clarification in skills/discord/SKILL.md — the skill is allowed-tools: ["message"] so its prompt is loaded only when working with Discord, and the new guideline distinguishes "use message.send for sideband traffic" from "let the runtime deliver your conversational reply." That removes the prompt that was causing Discord-only duplicate replies without changing behavior on other channels.

Changes

FileWhat
skills/discord/SKILL.mdNew ## Guidelines bullet explaining when to use message.send (sideband notifications, mid-turn updates, posting to a different target) vs when to let the runtime deliver the final conversational reply (the default — and the path autoThread: true uses to put the answer in the auto-created thread).
CHANGELOG.mdAppend ### Fixes entry under ## Unreleased, attribution Thanks @KeWang0622.
 2 files changed, 2 insertions(+)

Tests

Skill content is documentation — no scoped tests to add. pnpm exec oxfmt --check --threads=1 CHANGELOG.md skills/discord/SKILL.md is clean. The behavior change is in the agent's understanding of when to call message.send, which the existing skill-loading + Discord channel integration tests already exercise.

Context

Closes #73278.

Scope kept deliberately small. The reporter also noted the global Codex instruction at thread-lifecycle.ts:226 ("If sending a channel reply, use the OpenClaw messaging tool instead of describing that you would reply.") could be narrowed too, but that string applies across every channel — happy to follow up there if maintainers want a broader fix, but I didn't want to change cross-channel prompt behavior in a Discord-scoped PR.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • skills/discord/SKILL.md (modified, +1/-0)

PR #73394: fix(codex,discord): stop duplicate channel reply when autoThread routes to a thread

Description (problem / solution / changelog)

Summary

  • Problem: when a Discord channel mention triggers autoThread: true, the user sees two replies — one message.send reply in the parent channel and a normal final-assistant reply in the auto-created thread. The duplicate comes from the model being told (twice) to call the OpenClaw messaging tool for channel replies, even for the conversational reply that OpenClaw delivery is already going to route to the right surface.
  • Why it matters: every Discord autoThread mention handled by the Codex embedded harness produces a confusing duplicate reply across two surfaces.
  • What changed: the Codex embedded developer-instruction sentence in extensions/codex/src/app-server/thread-lifecycle.ts and the skills/discord/SKILL.md overview now distinguish "normal current-conversation reply" (just emit the final assistant message; OpenClaw routes it) from "explicit out-of-band action" (use the message tool: send to a different conversation, reactions, edits, reads, thread/channel/presence ops).
  • What did NOT change (scope boundary): no runtime/routing logic, no dynamic-tools wiring, no disableMessageTool plumbing. Only the prompt strings the agent reads.

Change Type

  • Bug fix

Scope

  • codex extension (embedded harness developer instructions)
  • discord skill (SKILL.md overview)

Linked Issue/PR

  • Closes #73278
  • This PR fixes a bug or regression

Root Cause

  • Root cause: two prompt sources told the agent the same thing — "use the OpenClaw messaging tool" for channel replies — without distinguishing the conversational reply (which OpenClaw delivery already routes back to the originating channel/thread) from explicit messaging operations. The model then called message.send and produced a final assistant response, so the parent channel got the manual send and the auto-created thread got the normal final response.
    • extensions/codex/src/app-server/thread-lifecycle.ts:226 — embedded developer instructions said "If sending a channel reply, use the OpenClaw messaging tool instead of describing that you would reply."
    • skills/discord/SKILL.md overview said "Use the message tool." with no carve-out for the current-conversation reply.
  • Missing detection / guardrail: prompt strings, no test surface.
  • Contributing context: autoThread: true makes the duplicate especially visible because the two surfaces (parent vs thread) diverge.

Regression Test Plan

  • Coverage level that should have caught this:
    • Documentation/prompt change verified by review
  • Target test or file: prompt strings only; no behavioural code changed.
  • Why this is the smallest reliable guardrail: the bug surface is the wording of two prompt sources. A unit test would only re-assert the new wording verbatim. The fix is reviewed against the issue's failure mode and the existing message tool semantics.

User-visible / Behavior Changes

  • Discord autoThread: true mentions now produce a single normal reply in the auto-created thread instead of a manual message.send reply in the parent channel plus the thread reply.
  • Behaviour for explicit message tool actions (send to a different conversation, react, edit/unsend, read, thread/channel/presence ops) is unchanged.
  • Other channels are unaffected — the developer-instruction wording applies to the embedded Codex harness in general, but the fix preserves "OpenClaw routes the final assistant message back to the originating channel/session" which was already the runtime behaviour.

Security Impact

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No (this PR removes a duplicate outbound message.send)
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Repro + Verification

Steps

  1. Run OpenClaw 2026.4.26 with a Discord channel configured for autoThread: true.
  2. Mention OpenClaw in that parent channel.
  3. Observe replies in the parent channel and the auto-created thread.

Expected

  • Single normal conversational reply lands in the auto-created thread. The parent channel does not receive an additional message.send reply for the same turn.

Actual (before fix)

  • Manual message.send reply lands in the parent channel and a separate final assistant response lands in the auto-created thread.

Evidence

  • Reviewed both prompt sources against the issue's reproduction. The fix narrows the messaging-tool guidance to the explicit out-of-band cases the message tool already supports (send to another conversation, reactions, edits, reads, thread/channel management, presence) and explicitly tells the agent to emit the conversational reply as the final assistant message.

Human Verification

  • Verified scenarios: TypeScript clean on the touched .ts file; both prompt strings rewritten consistently.
  • Edge cases checked: explicit out-of-band message actions (different channel/user, react, edit, read, thread management, presence) — still covered. autoThread: true mention path — single thread reply.
  • What I did NOT verify: a live Discord run with autoThread: true; full pnpm check / pnpm test was not exercised locally, leaving CI as the verification surface.

Compatibility / Migration

  • Backward compatible? Yes (prompt-only change, no API/config surface).
  • Config/env changes? No
  • Migration needed? No

Risks and Mitigations

  • Risk: an existing skill or workflow that intentionally relied on the embedded harness also sending the conversational reply via message.send (e.g., to set Discord-specific options like silent: true or components).
    • Mitigation: such workflows should be expressed as an explicit message.send to a specific to: target with the desired flags — exactly the explicit out-of-band case the new guidance still encourages. The default conversational reply path is now consistent with how OpenClaw delivery already routes the final assistant message.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/codex/src/app-server/thread-lifecycle.ts (modified, +1/-1)
  • skills/discord/SKILL.md (modified, +3/-1)

Code Example

Observed behavior in the live Discord session:
- Parent channel received a manual message-tool reply.
- Auto-created thread received the normal final assistant response.

Relevant prompt sources in the official 2026.4.26 package:
- extensions/codex/src/app-server/thread-lifecycle.ts included guidance equivalent to:
  "If sending a channel reply, use the OpenClaw messaging tool..."
- skills/discord/SKILL.md broadly instructed:
  "Use the `message` tool."

Local package/runtime copies were compared against npm registry tarballs for 2026.4.24, 2026.4.25, 2026.4.25-beta.10, and 2026.4.26; the relevant bundled runtime files matched the registry contents.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Discord channel mentions with autoThread: true can produce two user-visible replies: one manual message.send reply in the parent channel and one normal final response in the created thread.

Steps to reproduce

  1. Run OpenClaw 2026.4.26 (be8c246) with a Discord channel configured for autoThread: true.
  2. Mention OpenClaw in that parent channel.
  3. In the resulting Codex session, the agent receives runtime guidance that says channel replies should use the OpenClaw messaging tool, and the bundled Discord skill says to use the message tool.
  4. Observe the agent call message.send against the parent channel/thread starter and then also complete with a final response that OpenClaw delivers to the created thread.

Expected behavior

A channel mention with autoThread: true should create a thread and produce one normal conversational reply in that thread. The agent should not also send a conversational reply to the parent channel.

Actual behavior

The observed session sent a manual message.send reply in the parent channel and then produced a different final response in the auto-created thread. The final thread delivery path itself appeared to work; the duplicate came from the agent being prompted to use the message tool for the same conversational reply.

OpenClaw version

OpenClaw 2026.4.26 (be8c246)

Operating system

macOS 26.4.1 / Darwin 25.4.0 arm64

Install method

npm global

Model

Codex app-server embedded agent session. Exact upstream model/provider for the observed Discord turn: NOT_ENOUGH_INFO.

Provider / routing chain

Discord channel -> OpenClaw Discord integration -> Codex app-server embedded harness. Exact upstream LLM routing for the observed turn: NOT_ENOUGH_INFO.

Additional provider/model setup details

The issue is prompt/tool-routing related rather than model-provider specific: the bundled developer instruction explicitly told the agent to use the OpenClaw messaging tool for channel replies, and the bundled Discord skill broadly instructed the agent to use message.

Logs, screenshots, and evidence

Observed behavior in the live Discord session:
- Parent channel received a manual message-tool reply.
- Auto-created thread received the normal final assistant response.

Relevant prompt sources in the official 2026.4.26 package:
- extensions/codex/src/app-server/thread-lifecycle.ts included guidance equivalent to:
  "If sending a channel reply, use the OpenClaw messaging tool..."
- skills/discord/SKILL.md broadly instructed:
  "Use the `message` tool."

Local package/runtime copies were compared against npm registry tarballs for 2026.4.24, 2026.4.25, 2026.4.25-beta.10, and 2026.4.26; the relevant bundled runtime files matched the registry contents.

Impact and severity

Affected: Discord users with autoThread: true channel mentions handled by Codex sessions. Severity: Moderate; it creates confusing duplicate replies in different Discord surfaces. Frequency: Observed in the affected 2026.4.26 Discord mention workflow; exact broader frequency is model/session dependent. Consequence: The parent channel receives an unexpected reply while the thread also receives a normal response, making routing and conversation state look inconsistent.

Additional information

A focused fix is to make the Codex runtime guidance and bundled Discord skill distinguish normal current-conversation replies from explicit messaging operations. Normal current-conversation replies should use the final assistant response so OpenClaw delivery can route them to the correct channel/thread; message.send/message.thread-reply should be reserved for explicit messaging actions such as reads, reactions, notifications, or sending to another conversation.

extent analysis

TL;DR

Update the Codex runtime guidance and bundled Discord skill to distinguish between normal conversation replies and explicit messaging operations.

Guidance

  • Review the thread-lifecycle.ts file in extensions/codex/src/app-server to ensure it provides clear guidance on using the OpenClaw messaging tool for channel replies.
  • Update the SKILL.md file in skills/discord to specify when to use the message tool, reserving it for explicit messaging actions.
  • Verify that the changes do not introduce any new issues with conversation state or routing.
  • Test the updated guidance and skill with different Discord mention workflows to ensure consistent behavior.

Example

No code snippet is provided as the issue is related to prompt/tool-routing and not a specific code implementation.

Notes

The fix may require additional changes to the Codex runtime or Discord skill to handle different conversation scenarios and edge cases.

Recommendation

Apply a workaround by updating the Codex runtime guidance and bundled Discord skill to distinguish between normal conversation replies and explicit messaging operations, as this will help prevent confusing duplicate replies in different Discord surfaces.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

A channel mention with autoThread: true should create a thread and produce one normal conversational reply in that thread. The agent should not also send a conversational reply to the parent channel.

#optimization#mixed precision#training loop#device allocation#model download

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Discord autoThread mentions can produce duplicate parent-channel and thread replies [3 pull requests, 1 participants]