Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bug: commentary-phase text still leaks into Discord replies on 2026.4.11 with openai-codex/gpt-5.4 [1 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#65132•Fetched 2026-04-12 13:25:26
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
cass-clearlycass-clearly
Participants
cass-clearlycass-clearly
Timeline (top)
cross-referenced ×1

On OpenClaw 2026.4.11, commentary-phase assistant text is still leaking into user-visible Discord replies when using openai-codex/gpt-5.4.

This appears related to the existing commentary leak family (#61734, #61814, #61474), but I observed it on Discord and on a version whose changelog already claims commentary/history visibility hardening.

Root Cause

Notes

  • A gateway restart does not appear to be a reliable fix. I observed the leak after a fresh gateway restart.
  • This seems especially notable because the 2026.4.11 changelog says commentary and leaked tool XML should be hidden from user-visible history/replies and follow-up replies should use final_answer only.
  • I am intentionally omitting any local paths, session IDs, auth tokens, API keys, or user-identifying details from this report.

Fix Action

Fixed

PR fix notes

PR #65140: fix(agents): suppress commentary text in visible replies

Description (problem / solution / changelog)

Summary

Fixes a remaining commentary leak path related to #65132.

This change does two things:

  • suppresses buffered OpenAI WS partial text until the item phase is known, and drops it entirely when that phase resolves to commentary
  • makes visible assistant text extraction ignore commentary blocks and prefer final_answer blocks when both exist in the same assistant message

Why

On 2026.4.11 I was able to reproduce a Discord-visible leak where internal planning text tagged phase: "commentary" reached the user with openai-codex/gpt-5.4.

The two main gaps addressed here were:

  1. response.output_text.delta partials were emitted before phase was known
  2. mixed-phase assistant messages could still contribute commentary text to visible reply extraction

Changes

  • src/agents/openai-ws-stream.ts
    • buffer response.output_text.delta per item_id
    • wait for response.output_item.added/done to determine item phase
    • flush only for final_answer
    • discard buffered commentary partials
  • src/agents/pi-embedded-utils.ts
    • return empty visible text for top-level commentary assistant messages
    • ignore commentary text blocks via textSignature.phase
    • when final_answer blocks exist, use only those for visible extraction

Tests

Added/updated tests covering:

  • buffered final text flushes once final_answer phase is known
  • buffered commentary partials are suppressed
  • commentary-only assistant messages produce no visible text
  • mixed commentary + final_answer assistant messages only expose final_answer

Validation

Ran:

  • pnpm exec vitest run src/agents/openai-ws-stream.test.ts src/agents/pi-embedded-utils.test.ts

Changed files

  • src/agents/openai-ws-stream.test.ts (modified, +124/-0)
  • src/agents/openai-ws-stream.ts (modified, +66/-12)
  • src/agents/pi-embedded-utils.test.ts (modified, +50/-0)
  • src/agents/pi-embedded-utils.ts (modified, +54/-1)

Code Example

Need act verify each sample exists in library. update via API. maybe use read skill? none.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

On OpenClaw 2026.4.11, commentary-phase assistant text is still leaking into user-visible Discord replies when using openai-codex/gpt-5.4.

This appears related to the existing commentary leak family (#61734, #61814, #61474), but I observed it on Discord and on a version whose changelog already claims commentary/history visibility hardening.

What leaked

A user-visible reply briefly included an internal-looking planning line like:

Need act verify each sample exists in library. update via API. maybe use read skill? none.

That text was not the final user-facing answer.

Why this looks like a real commentary leak

Session history for the affected turn shows:

  • the leaked text was stored as assistant content
  • its signature metadata marked it as phase: "commentary"
  • the actual user-facing answer was produced later in the same turn as a separate final_answer

So this does not look like prompt injection or user-provided text being echoed back. It looks like commentary-phase content being surfaced to channel delivery.

Expected behavior

Only final_answer content should be visible to the user. Commentary / scratch / pre-tool planning text should never be delivered to Discord.

Actual behavior

Commentary-phase text became visible in the Discord chat before the final answer.

Environment

  • OpenClaw: 2026.4.11
  • Surface: Discord
  • Provider/model: openai-codex/gpt-5.4
  • Runtime: gateway-managed bot
  • Streaming mode on channel: off

Notes

  • A gateway restart does not appear to be a reliable fix. I observed the leak after a fresh gateway restart.
  • This seems especially notable because the 2026.4.11 changelog says commentary and leaked tool XML should be hidden from user-visible history/replies and follow-up replies should use final_answer only.
  • I am intentionally omitting any local paths, session IDs, auth tokens, API keys, or user-identifying details from this report.

Related

  • #61734
  • #61814
  • #61474
  • #61688
  • #62409

Suspected area

Possibly a Discord delivery / reply mirror / follow-up path that is still bypassing the phase-aware visibility filter, even after the 2026.4.11 hardening work.

extent analysis

TL;DR

Review and update the phase-aware visibility filter in the Discord delivery pathway to ensure commentary-phase content is not surfaced to users.

Guidance

  • Investigate the Discord delivery/reply mirror/follow-up path to identify where the phase-aware visibility filter is being bypassed.
  • Verify that the final_answer content is being correctly generated and separated from commentary-phase content.
  • Check the implementation of the commentary/history visibility hardening changes in version 2026.4.11 to ensure they are correctly applied to the Discord surface.
  • Test the behavior with different provider/models and runtime configurations to determine if the issue is specific to openai-codex/gpt-5.4 or a more general problem.

Example

No specific code snippet can be provided without more information about the implementation details, but the fix likely involves updating the logic that handles Discord reply generation to correctly filter out commentary-phase content.

Notes

The issue may be related to a previous family of commentary leak bugs (#61734, #61814, #61474), and the fix may involve re-examining and refining the solutions applied to those issues.

Recommendation

Apply a workaround to the Discord delivery pathway to explicitly filter out commentary-phase content until a more permanent fix can be implemented, as the root cause of the issue is likely related to the bypassing of the phase-aware visibility filter.

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

Only final_answer content should be visible to the user. Commentary / scratch / pre-tool planning text should never be delivered to Discord.

#api#model compatibility#GPU setup#container setup#orchestration issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING