openclaw - ✅(Solved) Fix Feishu group can double reply when tool-use turns emit visible assistant text [1 pull requests, 1 comments, 2 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#71588Fetched 2026-04-26 05:11:02
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
Participants
Timeline (top)
closed ×1commented ×1cross-referenced ×1

Feishu group chats can receive two bot replies for a single inbound message when an agent turn emits visible assistant text before a tool call and then later emits the final answer.

This is not a duplicate inbound event or two agents handling the same message. In the observed case the inbound Feishu group message was received once and dispatched to one agent once, but the dispatch completed with multiple user-visible replies.

Error Message

For one Feishu group message:

Root Cause

Feishu group chats can receive two bot replies for a single inbound message when an agent turn emits visible assistant text before a tool call and then later emits the final answer.

This is not a duplicate inbound event or two agents handling the same message. In the observed case the inbound Feishu group message was received once and dispatched to one agent once, but the dispatch completed with multiple user-visible replies.

Fix Action

Fix / Workaround

This is not a duplicate inbound event or two agents handling the same message. In the observed case the inbound Feishu group message was received once and dispatched to one agent once, but the dispatch completed with multiple user-visible replies.

  • Feishu monitor logged one inbound group message event.
  • The message was dispatched to one agent/session once.
  • The run produced visible assistant text in a tool-use/intermediate turn, then produced a final answer after the tool completed.
  • The Feishu group received both messages, so users saw the bot reply twice.
  • The dispatch log showed multiple final replies, e.g. queuedFinal=true, replies=2.

PR fix notes

PR #71589: fix(agent): suppress tool-use assistant text

Description (problem / solution / changelog)

Summary

  • suppress assistant messages that are tool-use continuations (stopReason: "toolUse" or tool-call content) from user-visible assistant output
  • keep explicit final_answer phase output deliverable
  • add regression coverage for unphased tool-use assistant text so it does not emit block/partial replies or final assistant text

Fixes #71588.

Notes

The Feishu group trigger policy (groupPolicy=open / requireMention=false) can make this easier to hit because more group messages start agent runs, but it is not the direct root cause. The direct issue is one agent run exposing both intermediate tool-use assistant text and the later final answer as user-visible replies.

Validation

  • corepack pnpm vitest run src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.suppresses-commentary-phase-output.test.ts
  • corepack pnpm tsgo:core
  • corepack pnpm exec oxlint --tsconfig tsconfig.oxlint.core.json src/agents/pi-embedded-subscribe.handlers.messages.ts src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.suppresses-commentary-phase-output.test.ts
  • corepack pnpm exec oxfmt --check src/agents/pi-embedded-subscribe.handlers.messages.ts src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.suppresses-commentary-phase-output.test.ts

Full corepack pnpm lint:core currently fails on an unrelated pre-existing no-array-sort finding in src/agents/cli-runner.spawn.test.ts:1029.

Changed files

  • src/agents/pi-embedded-subscribe.handlers.messages.ts (modified, +31/-2)
  • src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.suppresses-commentary-phase-output.test.ts (modified, +32/-0)

Code Example

{
  "channels": {
    "feishu": {
      "groupPolicy": "open",
      "requireMention": false
    }
  }
}
RAW_BUFFERClick to expand / collapse

Summary

Feishu group chats can receive two bot replies for a single inbound message when an agent turn emits visible assistant text before a tool call and then later emits the final answer.

This is not a duplicate inbound event or two agents handling the same message. In the observed case the inbound Feishu group message was received once and dispatched to one agent once, but the dispatch completed with multiple user-visible replies.

Observed behavior

For one Feishu group message:

  • Feishu monitor logged one inbound group message event.
  • The message was dispatched to one agent/session once.
  • The run produced visible assistant text in a tool-use/intermediate turn, then produced a final answer after the tool completed.
  • The Feishu group received both messages, so users saw the bot reply twice.
  • The dispatch log showed multiple final replies, e.g. queuedFinal=true, replies=2.

Expected behavior

For group chats, intermediate tool-use assistant text should not be delivered as a normal user-visible reply by default. The group should receive either:

  • only the final answer, or
  • an explicit progress/streaming UI if the channel has opted into that behavior.

A tool-use turn such as "I'll check this now" followed by a tool call should stay internal/progress-only and should not be counted as a final group reply.

Related configuration

This is easier to notice when a Feishu bot is configured to answer broadly in groups, for example:

{
  "channels": {
    "feishu": {
      "groupPolicy": "open",
      "requireMention": false
    }
  }
}

That configuration broadens the trigger surface: any group message can start an agent run without an @mention. It is therefore relevant to the impact and reproducibility of the problem.

However, it is not the direct cause of the double reply. The direct cause is that one agent run can expose both tool-use/intermediate assistant text and the later final answer as group-visible replies.

Non-goals / not observed

  • This is not about duplicate Feishu webhook delivery.
  • This is not about two OpenClaw agents or two Feishu bots both responding to the same message.
  • This is not requesting that Docker/bridge networking or group activation policy be changed.

Proposed fix

Suppress assistant messages that end in stopReason: "toolUse" from user-visible reply payloads, unless they are being handled by an explicit progress/streaming surface. They should remain in the transcript for tool-call continuity, but not be emitted as final replies to Feishu groups.

extent analysis

TL;DR

Suppressing assistant messages that end in stopReason: "toolUse" from user-visible reply payloads can prevent double replies in Feishu group chats.

Guidance

  • Identify and filter out intermediate assistant text with stopReason: "toolUse" to prevent them from being sent as final replies.
  • Verify that the dispatch log no longer shows multiple final replies (e.g., queuedFinal=true, replies=2) after implementing the fix.
  • Review the Feishu bot configuration, specifically the groupPolicy and requireMention settings, to ensure they are not contributing to the issue.
  • Test the proposed fix with different scenarios, including various tool-use turns and final answers, to ensure it works as expected.

Example

No code snippet is provided as the issue does not imply a specific code change, but rather a logical adjustment to the message handling process.

Notes

The proposed fix assumes that the issue is solely related to the handling of intermediate assistant text and tool-use turns. If other factors are contributing to the problem, additional debugging may be necessary.

Recommendation

Apply the proposed workaround by suppressing assistant messages that end in stopReason: "toolUse" from user-visible reply payloads, as it directly addresses the identified cause of the issue.

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

For group chats, intermediate tool-use assistant text should not be delivered as a normal user-visible reply by default. The group should receive either:

  • only the final answer, or
  • an explicit progress/streaming UI if the channel has opted into that behavior.

A tool-use turn such as "I'll check this now" followed by a tool call should stay internal/progress-only and should not be counted as a final group reply.

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 Feishu group can double reply when tool-use turns emit visible assistant text [1 pull requests, 1 comments, 2 participants]