fix(whatsapp): strip leading whitespace from outbound messages by FelixFoster · Pull Request #8052 · openclaw/openclaw

FelixFoster · 2026-02-03T14:26:58Z

The Problem

LLM responses frequently start with newlines, causing empty space at the top of WhatsApp messages. This looks broken or poorly formatted on mobile devices.

The Fix

Added .trimStart() to the text payload in three key delivery paths:

src/web/auto-reply/deliver-reply.ts: The main auto-reply path.
src/infra/outbound/deliver.ts: General outbound delivery logic (ensures chunks are also trimmed).
src/channels/plugins/outbound/whatsapp.ts: Programmatic sending (e.g., via tools).

Verification

Verified that trailing whitespace is preserved (harmless on WhatsApp).
Verified that empty strings (or strings becoming empty after trim) are handled safely.

Greptile Overview

Greptile Summary

This PR addresses leading blank space in WhatsApp deliveries (often caused by LLMs starting responses with newlines) by applying trimStart() in multiple outbound paths:

WhatsApp outbound plugin: trims text before calling sendMessageWhatsApp.
Core outbound delivery (deliverOutboundPayloads): trims the overall text and each chunk before sending, and skips sending if trimming produces an empty string.
Web auto-reply delivery: trims each text chunk before replying and skips empty results.

It also includes small, unrelated changes in cron timer/job comments and runCommandWithTimeout spawn logic (stdin-inherit fallback).

Confidence Score: 4/5

This PR is generally safe to merge; the trimming changes are localized, with one likely missed WhatsApp caption path.
The main behavior change (leading-whitespace stripping) is straightforward and guarded against empty sends in core delivery. The only notable issue found is that media captions in the web auto-reply path are not trimmed, so the user-visible bug can still occur for media replies. Other touched areas (cron comments, spawn fallback) don’t show obvious functional regressions from the diff shown.
src/web/auto-reply/deliver-reply.ts (media caption path), and verify cron/spawn changes are intended for this PR’s scope.

_{(5/5) You can turn off certain types of comments like style here!}

greptile-apps

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-03T14:28:39Z

src/cron/service/jobs.ts

+    // If it's a one-shot job and we missed the window, run it ASAP
+    // unless it's ancient history (which we might want to flag, but for now run it).
+    // The previous logic just returned schedule.atMs, which is correct for "next run",
+    // but the scheduler needs to know it's *runnable*.
    return job.schedule.atMs;


[P3] Comment doesn’t match the code behavior. computeJobNextRunAtMs still returns job.schedule.atMs for one-shot jobs, so overdue jobs remain represented as a timestamp in the past; the scheduler is what interprets now >= nextRunAtMs as runnable. The comment says “run it ASAP … scheduler needs to know it’s runnable”, which implies returning nowMs (or similar) rather than the original atMs.

Consider rewording this comment to reflect the actual behavior (keeping atMs so it stays due until success).

Prompt To Fix With AI

This is a comment left during a code review. Path: src/cron/service/jobs.ts Line: 46:50 Comment: [P3] Comment doesn’t match the code behavior. `computeJobNextRunAtMs` still returns `job.schedule.atMs` for one-shot jobs, so overdue jobs remain represented as a timestamp in the past; the scheduler is what interprets `now >= nextRunAtMs` as runnable. The comment says “run it ASAP … scheduler needs to know it’s runnable”, which implies returning `nowMs` (or similar) rather than the original `atMs`. Consider rewording this comment to reflect the actual behavior (keeping `atMs` so it stays due until success). How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-03T14:28:42Z

Additional Comments (1)

src/web/auto-reply/deliver-reply.ts
[P1] Caption trimming is inconsistent with text-only trimming. deliverWebReply now strips leading whitespace for text-only chunks, but media captions (caption = remainingText.shift() || undefined) can still start with newlines/spaces (common for LLM output), so the original formatting issue can persist for media-first replies.

This matters when mediaList.length > 0 and the first caption chunk begins with whitespace.

A minimal fix is to trimStart() (and potentially skip empty) for caption similarly to the text-only path.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/web/auto-reply/deliver-reply.ts
Line: 101:103

Comment:
[P1] Caption trimming is inconsistent with text-only trimming. `deliverWebReply` now strips leading whitespace for text-only chunks, but media captions (`caption = remainingText.shift() || undefined`) can still start with newlines/spaces (common for LLM output), so the original formatting issue can persist for media-first replies.

This matters when `mediaList.length > 0` and the first caption chunk begins with whitespace.

A minimal fix is to `trimStart()` (and potentially skip empty) for `caption` similarly to the text-only path.

How can I resolve this? If you propose a fix, please make it concise.

FelixFoster · 2026-02-11T03:03:16Z

Thanks @greptile-apps! Fixed in bd79b33. Added trimStart() to media captions.

greptile-apps · 2026-02-11T03:03:45Z

Perfect! The media caption fix looks good at src/web/auto-reply/deliver-reply.ts:101-102. You're properly handling the optional text by trimming rawCaption only when it exists, then using undefined for the caption if it's empty after trimming.

This closes the gap I flagged in the review. The PR now consistently trims leading whitespace across all WhatsApp text and media caption paths. 🎯

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.

) * 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 #8052 and #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]>

…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]>

openclaw-barnacle · 2026-02-21T04:47:15Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

…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

…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

…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]>

openclaw-barnacle · 2026-03-09T04:06:00Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

ImLukeF · 2026-03-12T00:34:48Z

Superseded with #43539.

openclaw-barnacle bot added the channel: whatsapp-web Channel integration: whatsapp-web label Feb 3, 2026

greptile-apps bot reviewed Feb 3, 2026

View reviewed changes

FelixFoster force-pushed the fix/whatsapp-whitespace-strip branch from ecba4a7 to ad354a8 Compare February 3, 2026 14:35

GodsBoy mentioned this pull request Feb 12, 2026

Usage tracking broken for setup-token auth (missing user:profile scope) #4614

Closed

mcinteerj mentioned this pull request Feb 14, 2026

fix: strip leading whitespace from sanitizeUserFacingText output #16158

Merged

mcinteerj mentioned this pull request Feb 14, 2026

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

Merged

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

openclaw-barnacle bot added stale Marked as stale due to inactivity and removed stale Marked as stale due to inactivity labels Feb 21, 2026

fix(whatsapp): trim leading whitespace from media captions

2467927

FelixFoster force-pushed the fix/whatsapp-whitespace-strip branch from bd79b33 to 2467927 Compare February 26, 2026 12:14

openclaw-barnacle bot added the size: XS label Feb 26, 2026

This comment was marked as spam.

Sign in to view

chore(protocol): update generated swift models

303f15c

openclaw-barnacle bot added the app: macos App: macos label Mar 3, 2026

openclaw-barnacle bot added the stale Marked as stale due to inactivity label Mar 9, 2026

ImLukeF mentioned this pull request Mar 12, 2026

fix(whatsapp): trim leading whitespace in direct outbound sends #43539

Merged

20 tasks

ImLukeF closed this Mar 12, 2026

jalagrange mentioned this pull request Mar 29, 2026

[Docs]: OAuth tokens require undocumented system prompt identity for non-Haiku models — pi-ai handles it, but service_tier gap remains #56873

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(whatsapp): strip leading whitespace from outbound messages#8052

fix(whatsapp): strip leading whitespace from outbound messages#8052
FelixFoster wants to merge 2 commits intoopenclaw:mainfrom
FelixFoster:fix/whatsapp-whitespace-strip

FelixFoster commented Feb 3, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 3, 2026

Uh oh!

greptile-apps bot commented Feb 3, 2026

Uh oh!

FelixFoster commented Feb 11, 2026

Uh oh!

greptile-apps bot commented Feb 11, 2026

Uh oh!

openclaw-barnacle bot commented Feb 21, 2026

Uh oh!

This comment was marked as spam.

openclaw-barnacle bot commented Mar 9, 2026

Uh oh!

ImLukeF commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

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

Uh oh!

The Problem

The Fix

Verification

Greptile Overview

Greptile Summary

Confidence Score: 4/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot commented Feb 3, 2026

Uh oh!

FelixFoster commented Feb 11, 2026

Uh oh!

greptile-apps bot commented Feb 11, 2026

Uh oh!

openclaw-barnacle bot commented Feb 21, 2026

Uh oh!

This comment was marked as spam.

openclaw-barnacle bot commented Mar 9, 2026

Uh oh!

ImLukeF commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

FelixFoster commented Feb 3, 2026 •

edited by greptile-apps bot

Loading