Summary

When the active model returns assistant content as phase-tagged text blocks (type: "text" with textSignature.phase), buildEmbeddedRunPayloads ships the raw streamed assistantTexts to channel-delivery payloads, which includes the commentary phase blocks. The final_answer-only filter (extractAssistantVisibleText) is only consulted as a fallback when streaming captured nothing.

End-user impact: reasoning summaries ("Need answer. Current? ...", "Responding to user's food list...") get delivered to iMessage / Telegram / etc. alongside or instead of the final reply.

Version: 2026.5.7. Provider: openai-codex/gpt-5.5 via OAuth. The same issue would affect any provider whose responses include textSignature.phase blocks.

Reproduction

1. Configure an agent with model: "openai-codex/gpt-5.5" (or any other provider that returns phase-tagged blocks).
2. Send a non-trivial question (one that elicits some internal reasoning).
3. Observe the channel-delivered reply (iMessage / Telegram / etc).

The delivered text frequently contains both a commentary-phase preamble and the final_answer. Sometimes only the commentary if the run terminated before final_answer was emitted.

An openclaw agent --json probe of the same agent + session is clean, because result.payloads[*].text comes from a separate construction path that already calls extractAssistantVisibleText correctly. So the bug isn't visible from CLI testing — only from real channel delivery.

Root cause

dist/pi-embedded-Bcz04p2i.js, function buildEmbeddedRunPayloads (around line 1346 in 2026.5.7):

const answerTexts = suppressAssistantArtifacts ? [] : (
    shouldPreferRawAnswerText && fallbackRawAnswerText ? [fallbackRawAnswerText]
    : hasAssistantTextPayload ? nonEmptyAssistantTexts     // <-- raw streamed chunks, includes commentary
    : fallbackAnswerText ? [fallbackAnswerText]            // <-- phase-filtered, only used as fallback
    : []
).filter((text) => !shouldSuppressRawErrorText(text));

nonEmptyAssistantTexts is params.assistantTexts.filter(...) — the raw streamed chunks the provider emitted during the run. The codex stream doesn't surface textSignature.phase per-chunk, so these contain both phases concatenated.

fallbackAnswerText is extractAssistantVisibleText(params.lastAssistant), which already correctly filters for phase: "final_answer" (or returns the unphased content when no phase tags exist). But it's only used when hasAssistantTextPayload is false — i.e. when streaming was empty, which is rare for non-empty turns.

The filter logic exists elsewhere in the codebase and works:

• extractAssistantVisibleText (used by CLI/JSON output path)
• shouldSuppressAssistantEventForLiveChat in live-chat-projector (used by TUI display)
• The commentary enum is documented in protocol-validators with the comment "Classifies an assistant message as interim commentary or final answer text"

The channel-delivery payload builder is just the one place this filter isn't applied.

Suggested fix

When the assistant message has explicit phase metadata, route through the already-phase-filtered fallbackAnswerText instead of the raw stream. Non-phase-tagged providers (Anthropic API, OpenAI API path, etc.) are unaffected because lastAssistantHasPhaseMetadata returns false for them.

const lastAssistantHasPhaseMetadata = (() => {
    const c = params.lastAssistant && params.lastAssistant.content;
    if (!Array.isArray(c)) return false;
    for (const b of c) {
        if (!b || b.type !== "text" || !b.textSignature) continue;
        try {
            const sig = typeof b.textSignature === "string"
                ? JSON.parse(b.textSignature) : b.textSignature;
            if (sig && sig.phase) return true;
        } catch (e) {}
    }
    return false;
})();
const answerTexts = suppressAssistantArtifacts ? [] : (
    lastAssistantHasPhaseMetadata && fallbackAnswerText ? [fallbackAnswerText]
    : shouldPreferRawAnswerText && fallbackRawAnswerText ? [fallbackRawAnswerText]
    : hasAssistantTextPayload ? nonEmptyAssistantTexts
    : fallbackAnswerText ? [fallbackAnswerText]
    : []
).filter((text) => !shouldSuppressRawErrorText(text));

I've been running this patch locally against 2026.5.7 for a few hours without regressions; reasoning-trigger probes and plain conversational turns both deliver only the final_answer block.

Why this matters

Affects every channel-delivered reply on phase-tagging providers — iMessage (BlueBubbles), Telegram, etc. The CLI path being clean made it hard to spot until I started reading session JSONL files and comparing messageContent.content[*].textSignature.phase against what landed in the actual channel.

Happy to open a PR if helpful.