Greptile Summary

This PR adds stripToolCallXml() to sanitize raw <tool_call> / <tool_result> XML that some models emit as plain text, and wires it into the extractAssistantText() sanitization chain between stripModelSpecialTokens and stripDowngradedToolCallText. The implementation is clean, correct, and consistent with the existing stripMinimaxToolCallXml pattern.

Key changes:

• New stripToolCallXml() in pi-embedded-utils.ts: fast-path regex guard, non-greedy paired-block removal, stray-tag fallback cleanup.
• Integration in extractAssistantText(): placement in the chain is sensible — after MiniMax-specific and special-token stripping, before downgraded-text and thinking-tag stripping.
• 7 unit tests + 1 integration test covering paired blocks, attributed tags, stray/unclosed tags, empty input, no-op, and end-to-end through extractAssistantText.

One style note: Stripping whole-line <tool_call> / <tool_result> blocks leaves the surrounding newlines intact, resulting in consecutive blank lines in user-facing output (e.g. \n\n\n between surrounding text). This is consistent with stripMinimaxToolCallXml's behavior and is documented in the test, but a shared post-pass that collapses 3+ newlines to 2 in extractAssistantText would improve message presentation across all strippers.

Confidence Score: 4/5

• Safe to merge; the new stripper is correct, well-tested, and follows established patterns with no risk of breaking existing behaviour.
• The implementation is straightforward regex-based text sanitization with no side-effects, proper fast-path guards, and non-greedy patterns that avoid ReDoS. Tests cover the important cases. The only minor concern is cosmetic (surplus blank lines in stripped output) rather than a correctness or security issue.
• No files require special attention.

_{Last reviewed commit: 23c1173}

Re: trailing whitespace in closing tags — the existing stripMinimaxToolCallXml regexes also match exact closing tags without trailing whitespace tolerance. These leaked XML tags are generated by specific model versions in a consistent format. Adding \s* before the closing > would broaden the regex beyond what's observed in practice. If a model variant starts emitting trailing spaces, we can tighten the regex then.

Friendly ping — cleaned up my PR backlog to make review easier. This fixes tool_call/tool_result XML leaking into user-visible channel messages (reported in #40879). The approach mirrors the existing stripMinimaxToolCallXml pattern. Happy to rebase when CI is green.

Closing this as implemented after Codex review.

Current main already strips leaked <tool_call> / <tool_result> XML on the canonical assistant-visible text path, with broader coverage than this PR, and that implementation is already present in release v2026.4.22.

What I checked:

• Canonical sanitizer already strips tool-call XML: stripToolCallXmlTags() is implemented as a stateful sanitizer that removes <tool_call> / <tool_result> payloads, handles truncated blocks, and avoids early close on quoted </tool_call> text. (src/shared/text/assistant-visible-text.ts:199, 7d9172d5e093)
• Sanitizer is wired into the user-visible extraction pipeline: The canonical assistant-visible pipeline applies stripToolCallXmlTags() before downgraded-tool stripping, and extractAssistantText() routes assistant text through sanitizeAssistantVisibleText(). Session/history extraction also uses the shared sanitizer profile. (src/shared/text/assistant-visible-text.ts:581, 7d9172d5e093)
• Tests cover the reported leak and stricter edge cases: Current tests cover closed <tool_call>/<tool_result> blocks, truncated openings, mismatched closers, quoted </tool_call> inside JSON strings, and the combined canonical sanitizer path. (src/shared/text/assistant-visible-text.test.ts:108, 7d9172d5e093)
• Shipped in latest release: The same assistant-visible sanitizer implementation is present at release tag v2026.4.22 (00bd2cf7a376f1fba26291c6c4766f1f15cbdfa5), so the fix is already shipped. (src/shared/text/assistant-visible-text.ts:199, 00bd2cf7a376)

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review notes: reviewed against 7d9172d5e093; fix evidence: release v2026.4.22, commit 00bd2cf7a376.