fix(imessage): only strip standalone role-turn markers, not prose ending in a role word by ly-wang19 · Pull Request #96392 · openclaw/openclaw

ly-wang19 · 2026-06-24T11:54:33Z

What Problem This Solves

sanitizeOutboundText (extensions/imessage/src/monitor/sanitize-outbound.ts) strips leaked assistant turn-boundary markers (a standalone assistant: / user: / system: on its own line). But ROLE_TURN_MARKER_RE only anchored the end of the line:

const ROLE_TURN_MARKER_RE = /\b(?:user|system|assistant)\s*:\s*$/gm;

So any ordinary outbound line that merely ends with one of those words + a colon was truncated before delivery to iMessage:

"Please send this reply to the user:"  ->  "Please send this reply to the"   ❌
"Here is a note for the system:"       ->  "Here is a note for the"          ❌

sanitizeOutboundText is on the live iMessage delivery path (channel.ts:339 sanitizeText, monitor/deliver.ts), so this silently drops words from real replies.

Fix

Anchor the marker to the whole line so only a standalone leaked marker is stripped, never a word inside prose:

const ROLE_TURN_MARKER_RE = /^[ \t]*(?:user|system|assistant)\s*:\s*$/gm;

The intended behavior (stripping a standalone assistant: / user: line) is unchanged.

Evidence

Added a regression test; verified by running the regex pipeline:

"Please send this reply to the user:"   before "Please send this reply to the"  ->  after (unchanged) ✅
"Here is a note for the system:"        before "Here is a note for the"         ->  after (unchanged) ✅
"Hello\nassistant:\nuser:"  (standalone) before "Hello"  ->  after "Hello"       (still stripped ✅, existing test)
"First line\nForward to the user:\nmore" before "...Forward to the \n..."        ->  after (unchanged) ✅

Standalone-marker stripping is preserved (existing test stays green); only prose lines that happen to end with the marker word are now left intact.

clawsweeper · 2026-06-24T11:56:11Z

Codex review: needs maintainer review before merge. Reviewed June 25, 2026, 3:59 AM ET / 07:59 UTC.

Summary
The PR anchors the iMessage outbound role-marker sanitizer to standalone lines and adds regression tests for prose ending in role words.

PR surface: Source +2, Tests +9. Total +11 across 2 files.

Reproducibility: yes. Source inspection plus a read-only regex probe show current main truncates prose ending in user:, system:, or assistant: and that the changed pattern preserves those strings while still stripping standalone leaked markers.

Review metrics: none identified.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

none.

Next step before merge

No ClawSweeper repair job is needed because the submitted PR is already the narrow fix and has no concrete review findings.

Security
Cleared: The diff only changes a sanitizer regex and focused unit coverage; it does not touch dependencies, workflows, secrets, permissions, packaging, or code execution surfaces.

Review details

Best possible solution:

Land the narrow regex anchoring fix after ordinary maintainer review and required checks; no broader sanitizer refactor is needed for this bug.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection plus a read-only regex probe show current main truncates prose ending in user:, system:, or assistant: and that the changed pattern preserves those strings while still stripping standalone leaked markers.

Is this the best way to solve the issue?

Yes. Anchoring the role marker to a standalone line is the narrowest maintainable fix; removing the stripper would regress the existing internal-scaffolding guard, and moving this into the shared SDK sanitizer would be broader than the iMessage-only false positive requires.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 793b604b2377.

Label changes

Label justifications:

P2: The PR fixes a real but narrow iMessage outbound text truncation bug with limited blast radius.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body provides copied before/after sanitizer output for affected prose and the standalone-marker control case, which is sufficient for this pure text sanitizer change.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body provides copied before/after sanitizer output for affected prose and the standalone-marker control case, which is sufficient for this pure text sanitizer change.

Evidence reviewed

PR surface:

Source +2, Tests +9. Total +11 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	3	1	+2
Tests	1	9	0	+9
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	12	1	+11

What I checked:

Repository policy: Root and extensions AGENTS.md were read fully; the review applied the PR evidence, plugin-boundary, scoped-policy, and read-only review requirements. (AGENTS.md:1, 793b604b2377)
Current-main bug: Current main uses an end-anchored role-marker regex, so it can match the suffix of prose lines ending in user/system/assistant plus colon. (extensions/imessage/src/monitor/sanitize-outbound.ts:10, 793b604b2377)
Focused PR diff: The PR changes only the role-marker regex to require a full standalone line and adds sanitizer regression cases for prose ending in role words. (extensions/imessage/src/monitor/sanitize-outbound.ts:10, fef7f3bbfa30)
Outbound monitor path: iMessage monitor delivery sanitizes payload text before resolving sendable parts, chunking, and sending through the iMessage transport. (extensions/imessage/src/monitor/deliver.ts:39, 793b604b2377)
Direct outbound path: The iMessage channel outbound handler also applies sanitizeOutboundText before plain-text sanitization. (extensions/imessage/src/channel.ts:339, 793b604b2377)
Behavior probe: A read-only Node regex probe showed current main truncates prose ending in user/system/assistant while the proposed whole-line regex preserves those lines and still strips standalone markers. (extensions/imessage/src/monitor/sanitize-outbound.ts:10, 793b604b2377)

Likely related people:

joelnishanth: Merged PR fix(imessage): prevent echo loop from leaking internal metadata and amplifying NO_REPLY into queue overflow #33295 added the outbound sanitizer and delivery wiring that this PR narrows. (role: original sanitizer feature author; confidence: high; commits: adb9234d0375; files: src/imessage/monitor/sanitize-outbound.ts, src/imessage/monitor/deliver.ts)
scoootscooob: Moved the iMessage channel implementation from src/imessage to extensions/imessage and removed shim imports, carrying the sanitizer path into the current plugin location. (role: channel migration owner; confidence: medium; commits: 0ce23dc62d37, 439c21e078f1; files: extensions/imessage/src/monitor/sanitize-outbound.ts, extensions/imessage/src/monitor/deliver.ts)
shakkernerd: Current-main blame for the sanitizer and iMessage delivery wiring points to a recent mainline commit that carried these extension files. (role: recent area contributor; confidence: medium; commits: 365279b86f47; files: extensions/imessage/src/monitor/sanitize-outbound.ts, extensions/imessage/src/monitor/deliver.ts, extensions/imessage/src/channel.ts)
vincentkoc: Live PR metadata for the merged iMessage echo-loop hardening PR shows vincentkoc merged the sanitizer introduction. (role: merger of original sanitizer PR; confidence: medium; commits: adb9234d0375; files: src/imessage/monitor/sanitize-outbound.ts, src/imessage/monitor/deliver.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

…ing in a role word ROLE_TURN_MARKER_RE anchored only the end of the line (\b...:\s*$), so any outbound line that merely ended with 'user:'/'system:'/'assistant:' was truncated — e.g. 'Please send this reply to the user:' lost its last word. Anchor the marker to the whole line so only a standalone leaked turn marker (its own line) is stripped; standalone-marker behavior is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

vincentkoc · 2026-06-25T08:05:44Z

Merged via squash.

Prepared head SHA: fef7f3bbfa302acc3b9a2e932280dc6208d75093
Landed commit: 770b19f496c1637774e660d31306105b671d1526

…ing in a role word (openclaw#96392) ROLE_TURN_MARKER_RE anchored only the end of the line (\b...:\s*$), so any outbound line that merely ended with 'user:'/'system:'/'assistant:' was truncated — e.g. 'Please send this reply to the user:' lost its last word. Anchor the marker to the whole line so only a standalone leaked turn marker (its own line) is stripped; standalone-marker behavior is unchanged. Co-authored-by: ly-wang19 <[email protected]> Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

openclaw-barnacle Bot added channel: imessage Channel integration: imessage size: XS labels Jun 24, 2026

vincentkoc force-pushed the fix/imessage-anchor-role-turn-marker branch from 24002d5 to fef7f3b Compare June 25, 2026 07:54

vincentkoc merged commit 770b19f into openclaw:main Jun 25, 2026
87 checks passed

github-actions Bot mentioned this pull request Jun 25, 2026

📡 Upstream Digest — 2026-06-25 10:35 UTC curtismercier/openclaw-mods#1150

Open

clawsweeper Bot mentioned this pull request Jul 9, 2026

fix(imessage): apply canonical outbound sanitizer #101430

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(imessage): only strip standalone role-turn markers, not prose ending in a role word#96392

fix(imessage): only strip standalone role-turn markers, not prose ending in a role word#96392
vincentkoc merged 1 commit into
openclaw:mainfrom
ly-wang19:fix/imessage-anchor-role-turn-marker

ly-wang19 commented Jun 24, 2026

Uh oh!

clawsweeper Bot commented Jun 24, 2026 •

edited

Loading

Uh oh!

Uh oh!

vincentkoc commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

ly-wang19 commented Jun 24, 2026

What Problem This Solves

Fix

Evidence

Uh oh!

clawsweeper Bot commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

vincentkoc commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

clawsweeper Bot commented Jun 24, 2026 •

edited

Loading