Bug
Messages sent via iMessage sometimes arrive with leading blank lines at the top.
Root Cause
In the block streaming path, emitBlockChunk (pi-embedded-subscribe.js) strips thinking tags and calls .trimEnd() but not .trim(). When Claude's response starts after a stripped thinking block, leading \n\n survives through the entire pipeline:
sanitizeUserFacingText doesn't trimnormalizeStreamingText checks .trim() for skip logic but returns untrimmed textdeliverReplies (iMessage monitor) never trimssendMessageIMessage passes text straight through
Suggested Fix
Simplest targeted fix — in sendMessageIMessage (imessage/send.js), add .trim() after markdown table conversion:
message = convertMarkdownTables(message, tableMode);
message = message.trim(); // <-- add this
Alternatively, changing .trimEnd() to .trim() in emitBlockChunk would fix it for all channels.
Environment
- Clawdbot npm latest 2026.1.24-3
- iMessage channel via imsg-plus
- macOS 15.6 (arm64)
Bug
Messages sent via iMessage sometimes arrive with leading blank lines at the top.
Root Cause
In the block streaming path,
emitBlockChunk(pi-embedded-subscribe.js) strips thinking tags and calls.trimEnd()but not.trim(). When Claude's response starts after a stripped thinking block, leading\n\nsurvives through the entire pipeline:sanitizeUserFacingTextdoesn't trimnormalizeStreamingTextchecks.trim()for skip logic but returns untrimmed textdeliverReplies(iMessage monitor) never trimssendMessageIMessagepasses text straight throughSuggested Fix
Simplest targeted fix — in
sendMessageIMessage(imessage/send.js), add.trim()after markdown table conversion:Alternatively, changing
.trimEnd()to.trim()inemitBlockChunkwould fix it for all channels.Environment