fix: strip leading whitespace from sanitizeUserFacingText output by mcinteerj · Pull Request #16158 · openclaw/openclaw

mcinteerj · 2026-02-14T10:49:31Z

Summary

LLM responses frequently begin with \n\n, causing visible blank lines at the top of messages on WhatsApp (and other channels). This fixes the root cause in sanitizeUserFacingText rather than scattering trimStart() across multiple delivery paths.

lobster-biscuit

Repro Steps

Send a message that triggers an LLM response beginning with \n\n (common with Claude Opus 4.6)
Observe blank lines at the top of the WhatsApp message

Root Cause

sanitizeUserFacingText in src/agents/pi-embedded-helpers/errors.ts uses trimmed for empty-checks but returns the untrimmed stripped variable:

const stripped = stripFinalTagsFromText(text);
const trimmed = stripped.trim();
if (!trimmed) {
  return stripped;  // ← returns whitespace-only string instead of ""
}
// ...
return collapseConsecutiveDuplicateBlocks(stripped);  // ← returns untrimmed

Fix

Two one-line changes:

Empty input path: return "" instead of whitespace-only stripped
Final return: apply .trimStart() after collapseConsecutiveDuplicateBlocks

This is the single funnel point — all reply paths (auto-reply, heartbeat, outbound) flow through sanitizeUserFacingText via normalizeReplyPayload, so the fix applies universally without touching delivery code.

Behavior Changes

Messages with leading \n or \n\n will have that whitespace stripped before delivery
Whitespace-only text now returns "" instead of the whitespace string
No change to trailing whitespace or internal newlines

Codebase and GitHub Search

Supersedes fix(whatsapp): strip leading whitespace from outbound messages #8052 (same issue, but fixes at 3 delivery paths instead of root cause)
Supersedes fix: trim leading blank lines on first emitted chunk only (#5530) #10612 (same symptom, different approach)
normalizeReplyPayload in src/auto-reply/reply/normalize-reply.ts calls sanitizeUserFacingText — confirmed single funnel point

Tests

4 new test cases added to pi-embedded-helpers.sanitizeuserfacingtext.e2e.test.ts:

Test	Status
strips leading newlines from LLM output	✅
strips leading whitespace and newlines combined	✅
preserves trailing whitespace and internal newlines	✅
returns empty for whitespace-only input	✅

All 15 tests pass (11 existing + 4 new).

pnpm lint    ✅ 0 warnings, 0 errors
pnpm build   ✅ clean
pnpm test:e2e (sanitizeuserfacingtext) ✅ 15/15 passed

Manual Testing

Tested by observing WhatsApp message output before/after the change — leading blank lines no longer appear.

Sign-Off

Models used: Claude Opus 4.6 (analysis + implementation)
Submitter effort: High — traced through normalize-reply → sanitizeUserFacingText → errors.ts, identified root cause, checked for duplicate PRs, wrote focused fix with tests
Agent notes: Bug independently discovered by two agents (Keith 🪿 and Kev 🦈) experiencing identical symptoms on the same model. Root cause confirmed by code inspection, not speculation.

Greptile Overview

Greptile Summary

Fixes leading whitespace in LLM responses by modifying sanitizeUserFacingText in src/agents/pi-embedded-helpers/errors.ts. The function now returns an empty string for whitespace-only input and strips leading whitespace from the final output using .trimStart(). This addresses the root cause of blank lines appearing at the top of WhatsApp messages when Claude Opus 4.6 responses begin with \n\n.

Changes:

Returns "" instead of whitespace-only string when input is empty after trimming
Applies .trimStart() to the final return value after collapseConsecutiveDuplicateBlocks
Adds 4 new test cases covering leading newlines, combined whitespace/newlines, trailing whitespace preservation, and empty input

The fix is well-targeted at the single funnel point where all reply paths flow through normalizeReplyPayload, avoiding the need to patch multiple delivery paths.

Confidence Score: 5/5

This PR is safe to merge with minimal risk
The changes are minimal (two one-line modifications), well-tested with 4 new test cases, and address a real bug at the correct abstraction level. The fix applies .trimStart() uniformly to all non-error output paths without affecting error message formatting. All existing tests continue to pass, and the new tests verify the specific behavior changes.
No files require special attention

_{Last reviewed commit: efdcf74}

LLM responses frequently begin with \n\n, which survives through sanitizeUserFacingText and reaches the channel as visible blank lines. Root cause: the function used trimmed text for empty-checks but returned the untrimmed 'stripped' variable. Two one-line fixes: 1. Return empty string (not whitespace-only 'stripped') for blank input 2. Apply trimStart() to the final return value Fixes the same issue as openclaw#8052 and openclaw#10612 but at the root cause (sanitizeUserFacingText) rather than scattering trimStart across multiple delivery paths.

Co-authored-by: Tak Hoffman <[email protected]>

@mcinteerj

…anks @mcinteerj)

@mcinteerj

…anks @mcinteerj)

@mcinteerj

…anks @mcinteerj)

@mcinteerj

* fix: strip leading empty lines in sanitizeUserFacingText (#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (#16158) (thanks @mcinteerj)

…nclaw#16158) * fix: strip leading whitespace from sanitizeUserFacingText output LLM responses frequently begin with \n\n, which survives through sanitizeUserFacingText and reaches the channel as visible blank lines. Root cause: the function used trimmed text for empty-checks but returned the untrimmed 'stripped' variable. Two one-line fixes: 1. Return empty string (not whitespace-only 'stripped') for blank input 2. Apply trimStart() to the final return value Fixes the same issue as openclaw#8052 and openclaw#10612 but at the root cause (sanitizeUserFacingText) rather than scattering trimStart across multiple delivery paths. * Changelog: note sanitizeUserFacingText whitespace normalization Co-authored-by: Tak Hoffman <[email protected]> --------- Co-authored-by: Tak Hoffman <[email protected]>

@mcinteerj

) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj)

The block streaming delivery path (onBlockReply) bypasses sanitizeUserFacingText, so the trimStart fix from openclaw#16158/openclaw#16280 doesn't apply to users with blockStreaming enabled (the default). Adds trimStart() to the cleaned text in the block reply payload construction, consistent with the non-streaming path.

…nclaw#16158) * fix: strip leading whitespace from sanitizeUserFacingText output LLM responses frequently begin with \n\n, which survives through sanitizeUserFacingText and reaches the channel as visible blank lines. Root cause: the function used trimmed text for empty-checks but returned the untrimmed 'stripped' variable. Two one-line fixes: 1. Return empty string (not whitespace-only 'stripped') for blank input 2. Apply trimStart() to the final return value Fixes the same issue as openclaw#8052 and openclaw#10612 but at the root cause (sanitizeUserFacingText) rather than scattering trimStart across multiple delivery paths. * Changelog: note sanitizeUserFacingText whitespace normalization Co-authored-by: Tak Hoffman <[email protected]> --------- Co-authored-by: Tak Hoffman <[email protected]>

@mcinteerj

) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj)

@mcinteerj

) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj)

The block streaming delivery path (onBlockReply) bypasses sanitizeUserFacingText, so the trimStart fix from openclaw#16158/openclaw#16280 doesn't apply to users with blockStreaming enabled (the default). Adds trimStart() to the cleaned text in the block reply payload construction, consistent with the non-streaming path.

…nclaw#16158) * fix: strip leading whitespace from sanitizeUserFacingText output LLM responses frequently begin with \n\n, which survives through sanitizeUserFacingText and reaches the channel as visible blank lines. Root cause: the function used trimmed text for empty-checks but returned the untrimmed 'stripped' variable. Two one-line fixes: 1. Return empty string (not whitespace-only 'stripped') for blank input 2. Apply trimStart() to the final return value Fixes the same issue as openclaw#8052 and openclaw#10612 but at the root cause (sanitizeUserFacingText) rather than scattering trimStart across multiple delivery paths. * Changelog: note sanitizeUserFacingText whitespace normalization Co-authored-by: Tak Hoffman <[email protected]> --------- Co-authored-by: Tak Hoffman <[email protected]>

@mcinteerj

) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj)

@mcinteerj

) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj)

…nclaw#16158) * fix: strip leading whitespace from sanitizeUserFacingText output LLM responses frequently begin with \n\n, which survives through sanitizeUserFacingText and reaches the channel as visible blank lines. Root cause: the function used trimmed text for empty-checks but returned the untrimmed 'stripped' variable. Two one-line fixes: 1. Return empty string (not whitespace-only 'stripped') for blank input 2. Apply trimStart() to the final return value Fixes the same issue as openclaw#8052 and openclaw#10612 but at the root cause (sanitizeUserFacingText) rather than scattering trimStart across multiple delivery paths. * Changelog: note sanitizeUserFacingText whitespace normalization Co-authored-by: Tak Hoffman <[email protected]> --------- Co-authored-by: Tak Hoffman <[email protected]> (cherry picked from commit 3881af5) # Conflicts: # CHANGELOG.md

@mcinteerj

) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) (cherry picked from commit 50a6e0e) # Conflicts: # CHANGELOG.md

…nclaw#16158) * fix: strip leading whitespace from sanitizeUserFacingText output LLM responses frequently begin with \n\n, which survives through sanitizeUserFacingText and reaches the channel as visible blank lines. Root cause: the function used trimmed text for empty-checks but returned the untrimmed 'stripped' variable. Two one-line fixes: 1. Return empty string (not whitespace-only 'stripped') for blank input 2. Apply trimStart() to the final return value Fixes the same issue as openclaw#8052 and openclaw#10612 but at the root cause (sanitizeUserFacingText) rather than scattering trimStart across multiple delivery paths. * Changelog: note sanitizeUserFacingText whitespace normalization Co-authored-by: Tak Hoffman <[email protected]> --------- Co-authored-by: Tak Hoffman <[email protected]> (cherry picked from commit 3881af5) # Conflicts: # CHANGELOG.md # src/agents/pi-embedded-helpers/errors.ts

@mcinteerj

) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) (cherry picked from commit 50a6e0e) # Conflicts: # CHANGELOG.md

…nclaw#16158) * fix: strip leading whitespace from sanitizeUserFacingText output LLM responses frequently begin with \n\n, which survives through sanitizeUserFacingText and reaches the channel as visible blank lines. Root cause: the function used trimmed text for empty-checks but returned the untrimmed 'stripped' variable. Two one-line fixes: 1. Return empty string (not whitespace-only 'stripped') for blank input 2. Apply trimStart() to the final return value Fixes the same issue as openclaw#8052 and openclaw#10612 but at the root cause (sanitizeUserFacingText) rather than scattering trimStart across multiple delivery paths. * Changelog: note sanitizeUserFacingText whitespace normalization Co-authored-by: Tak Hoffman <[email protected]> --------- Co-authored-by: Tak Hoffman <[email protected]>

@mcinteerj

) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj) * fix: strip leading empty lines in sanitizeUserFacingText (openclaw#16158) (thanks @mcinteerj)

openclaw-barnacle bot added agents Agent runtime and tooling size: XS experienced-contributor labels Feb 14, 2026

steipete self-assigned this Feb 14, 2026

mcinteerj and others added 2 commits February 14, 2026 09:20

Changelog: note sanitizeUserFacingText whitespace normalization

a9db342

Co-authored-by: Tak Hoffman <[email protected]>

Takhoffman force-pushed the fix/trim-leading-whitespace-reply branch from 72e2b92 to a9db342 Compare February 14, 2026 15:22

Takhoffman merged commit 3881af5 into openclaw:main Feb 14, 2026
9 checks passed

steipete added a commit that referenced this pull request Feb 14, 2026

fix: strip leading empty lines in sanitizeUserFacingText (#16158) (th…

56ad4c9

…anks @mcinteerj)

steipete added a commit that referenced this pull request Feb 14, 2026

fix: strip leading empty lines in sanitizeUserFacingText (#16158) (th…

90a8394

…anks @mcinteerj)

steipete added a commit that referenced this pull request Feb 14, 2026

fix: strip leading empty lines in sanitizeUserFacingText (#16158) (th…

5d29c8f

…anks @mcinteerj)

steipete mentioned this pull request Feb 14, 2026

fix: strip leading empty lines in sanitizeUserFacingText #16280

Merged

mcinteerj mentioned this pull request Feb 14, 2026

fix: strip leading whitespace in block streaming reply path #16422

Merged

github-actions bot mentioned this pull request Mar 1, 2026

cherry-pick: upstream bugfix commits (2026-03-01-0443) hughdidit/DAISy-Agency#140

Closed

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: strip leading whitespace from sanitizeUserFacingText output#16158

fix: strip leading whitespace from sanitizeUserFacingText output#16158
Takhoffman merged 2 commits intoopenclaw:mainfrom
mcinteerj:fix/trim-leading-whitespace-reply

mcinteerj commented Feb 14, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

mcinteerj commented Feb 14, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Repro Steps

Root Cause

Fix

Behavior Changes

Codebase and GitHub Search

Tests

Manual Testing

Greptile Overview

Greptile Summary

Confidence Score: 5/5

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mcinteerj commented Feb 14, 2026 •

edited by greptile-apps bot

Loading