fix(auto-reply): truncate user-facing text on UTF-16 boundary by zenglingbiao · Pull Request #97299 · openclaw/openclaw

zenglingbiao · 2026-06-27T18:20:28Z

Summary

Replace String.prototype.slice(0, N) with truncateUtf16Safe() in two auto-reply text truncation paths — agent-runner message preview (497 chars) and plan working label (77 chars) — to prevent broken Unicode when non-BMP characters straddle the truncation boundary.

What Problem This Solves

Two user-facing text truncation paths in src/auto-reply/reply/ use raw .slice(0, N) which can split UTF-16 surrogate pairs:

agent-runner-execution.ts:756 — Agent message preview truncated to 497 chars: message.slice(0, 497)
dispatch-from-config.ts:2568 — Plan "working label" truncated to 77 chars: collapsed.slice(0, 77)

Both produce dangling surrogates when an emoji or non-BMP CJK character falls at the truncation boundary, displaying garbled � to users in chat channels.

Root Cause

String.prototype.slice() operates on UTF-16 code units, not Unicode code points
Non-BMP characters (emoji, rare CJK, etc.) use 2 code units (surrogate pairs)
Slicing at an arbitrary index can cut between the high and low surrogate

Why This Fix

Chosen approach: Use the existing truncateUtf16Safe utility from src/shared/utf16-slice.ts (same utility used by sibling PRs fix(shared): use UTF-16 safe truncation in assistant error formatting #97289 and fix(cron): truncate failure alert error text on UTF-16 boundary #97298)
Lines changed: +4 −2 across 2 files

User Impact

Affected: Agent-runner message previews and plan status labels displayed in chat channels (Telegram, Slack, Discord, etc.)
Before: Text could end with � when containing emoji near the truncation boundary
After: Text always truncated on valid code-point boundaries

Evidence

Terminal proof testing both boundaries (497-char and 77-char) with emoji straddling the cutoff:

Before (.slice(0, N)): Both boundaries produce dangling surrogates — FAIL
After (truncateUtf16Safe): Both boundaries truncate safely — PASS

Real Behavior Proof

$ node --import tsx proof.mjs
=== Test 1: 497-char boundary (agent-runner message) ===
Input length: 498

BEFORE .slice(0, 497): length = 497 | dangling = FAIL
AFTER  truncateUtf16Safe:  length = 496 | dangling = PASS

=== Test 2: 77-char boundary (plan working label) ===
Input length: 78

BEFORE .slice(0, 77): length = 77 | dangling = FAIL
AFTER  truncateUtf16Safe:  length = 76 | dangling = PASS

=== SUMMARY ===
Before (main): FAIL — dangling surrogates detected
After (fix):   PASS — all truncations UTF-16 safe

Tests and Validation

pnpm check passed
TypeScript compilation verified
Manual proof script confirms both boundaries are fixed

Use truncateUtf16Safe in agent-runner-execution (message preview) and dispatch-from-config (plan working label) to prevent surrogate pair splitting when non-BMP characters straddle truncation boundaries.

clawsweeper · 2026-06-27T18:21:35Z

Codex review: passed. Reviewed June 27, 2026, 4:38 PM ET / 20:38 UTC.

Summary
The PR imports truncateUtf16Safe and uses it for the Codex usage-limit preview and verbose working-label truncation paths in auto-reply.

PR surface: Source +2. Total +2 across 2 files.

Reproducibility: yes. Current main uses raw slice(0, N) at both reported user-facing truncation sites, and the PR body includes terminal before/after output showing dangling surrogates before the fix and safe truncation after it.

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:

[P2] Add focused regression assertions for the 497-character usage-limit preview and 77-character working-label boundary if maintainers want durable coverage before landing.

Risk before merge

[P1] No focused regression test was added for these two exact boundary constants, so durable coverage currently depends on source inspection, CI, and the PR body's terminal proof.

Maintainer options:

Decide the mitigation before merge
Land the narrow helper substitution after exact-head gates; add focused boundary regression assertions only if maintainers want durable coverage before merge.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

[P2] No repair lane is needed because the open PR already contains the narrow change and exact-head automerge can rely on review, check, and mergeability gates.

Security
Cleared: The diff only imports and calls an existing local string helper; it does not touch dependencies, workflows, permissions, secrets, package resolution, or code execution surfaces.

Review details

Best possible solution:

Land the narrow helper substitution after exact-head gates; add focused boundary regression assertions only if maintainers want durable coverage before merge.

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

Yes. Current main uses raw slice(0, N) at both reported user-facing truncation sites, and the PR body includes terminal before/after output showing dangling surrogates before the fix and safe truncation after it.

Is this the best way to solve the issue?

Yes. Reusing the existing dependency-free truncateUtf16Safe helper at the two presentation truncation sites is the narrowest maintainable fix; duplicating Unicode logic or changing channel delivery would be unnecessary.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

add status: 🚀 automerge armed: This PR is in ClawSweeper's automerge lane. Sufficient (terminal): The PR body includes copied terminal output showing before/after behavior for both changed boundaries, with dangling surrogates before and safe truncation after.
remove status: 👀 ready for maintainer look: Current PR status label is status: 🚀 automerge armed.

Label justifications:

P2: The PR fixes a bounded user-facing Unicode truncation bug in auto-reply/status text without broad compatibility, config, or persistence impact.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
status: 🚀 automerge armed: This PR is in ClawSweeper's automerge lane. Sufficient (terminal): The PR body includes copied terminal output showing before/after behavior for both changed boundaries, with dangling surrogates before and safe truncation after.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes copied terminal output showing before/after behavior for both changed boundaries, with dangling surrogates before and safe truncation after.

Evidence reviewed

PR surface:

Source +2. Total +2 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	2	4	2	+2
Tests	0	0	0	0
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	4	2	+2

What I checked:

Current main still slices the Codex usage-limit preview unsafely: extractCodexUsageLimitMessage sanitizes the user-facing message and still returns message.slice(0, 497) before appending ..., so a surrogate pair can be split at the 497-code-unit boundary. (src/auto-reply/reply/agent-runner-execution.ts:756, c29e1fe764f3)
Current main still slices the working label unsafely: normalizeWorkingLabel collapses label whitespace and still returns collapsed.slice(0, 77).trimEnd() before appending ..., so the status label has the same UTF-16 boundary issue. (src/auto-reply/reply/dispatch-from-config.ts:2568, c29e1fe764f3)
Existing helper matches the required contract: truncateUtf16Safe delegates to sliceUtf16Safe, whose boundary checks back off or advance around dangling surrogate halves before calling native slice. (src/shared/utf16-slice.ts:46, c29e1fe764f3)
PR diff is narrow and uses the existing helper: The branch only adds two imports and replaces the two raw truncation calls with truncateUtf16Safe; it does not change routing, config, persistence, dependencies, or channel adapters. (src/auto-reply/reply/agent-runner-execution.ts:754, 74a0a32ed925)
Latest release also lacks this fix: Release v2026.6.10 still contains both raw slice calls, so the PR is not obsolete relative to shipped code. (src/auto-reply/reply/agent-runner-execution.ts:755, aa69b12d0086)
Codex usage-limit text is a real upstream error surface: The sibling Codex source defines UsageLimitReachedError display text and a UsageLimitExceeded error kind; this PR only changes OpenClaw's local presentation truncation after that text is surfaced. (../codex/codex-rs/protocol/src/error.rs:424, e2398d0b1667)

Likely related people:

mushuiyu886: git blame on both current raw auto-reply truncation lines points to the landed squash commit that carried these files into their current shape. (role: current-main implementation provenance; confidence: medium; commits: 65fec9d787e3; files: src/auto-reply/reply/agent-runner-execution.ts, src/auto-reply/reply/dispatch-from-config.ts)
Peter Steinberger: git log -S 'slice(0, 77)' traces the working-label truncation to the structured execution item events commit authored by Peter Steinberger. (role: introduced adjacent working-label behavior; confidence: high; commits: 996dccb19ca1; files: src/auto-reply/reply/dispatch-from-config.ts)
Bartok9: Live PR metadata for the merged helper PR shows Bartok9 authored the commit that added the dependency-free UTF-16-safe helper reused here. (role: adjacent helper contributor; confidence: high; commits: e09b9dfc1ba9; files: src/shared/utf16-slice.ts, src/utils.ts)
vincentkoc: The merged helper PR was landed by vincentkoc, making this person a useful routing candidate for the shared helper import boundary. (role: recent helper merger; confidence: medium; commits: e09b9dfc1ba9; files: src/shared/utf16-slice.ts, src/utils.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.

Takhoffman · 2026-06-27T20:31:30Z

@clawsweeper automerge

clawsweeper · 2026-06-27T20:31:34Z

🦞✅
ClawSweeper merged this PR after the passing review.

Source: clawsweeper[bot]
Feedback: structured ClawSweeper verdict: pass (sha=74a0a32ed9254e5a46befb15c9d14fca19d0a4b1)
Merge status: merged by ClawSweeper automerge
Merged at: 2026-06-27T20:39:33Z
Merge commit: 1b8b8500cee0

What merged:

The PR imports truncateUtf16Safe and uses it for the Codex usage-limit preview and verbose working-label truncation paths in auto-reply.
PR surface: Source +2. Total +2 across 2 files.
Reproducibility: yes. Current main uses raw slice(0, N) at both reported user-facing truncation sites, and ... ludes terminal before/after output showing dangling surrogates before the fix and safe truncation after it.

Automerge notes:

No ClawSweeper repair was needed after automerge opt-in.

The automerge loop is complete.

Automerge progress:

2026-06-27 20:32:39 UTC review queued 74a0a32ed925 (queued)

2026-06-27 20:39:02 UTC review passed 74a0a32ed925 (structured ClawSweeper verdict: pass (sha=74a0a32ed9254e5a46befb15c9d14fca19d0a...)

2026-06-27 20:39:35 UTC merged 74a0a32ed925 (merged by ClawSweeper automerge)

…aw#97299) Summary: - The PR imports `truncateUtf16Safe` and uses it for the Codex usage-limit preview and verbose working-label truncation paths in auto-reply. - PR surface: Source +2. Total +2 across 2 files. - Reproducibility: yes. Current main uses raw `slice(0, N)` at both reported user-facing truncation sites, and ... ludes terminal before/after output showing dangling surrogates before the fix and safe truncation after it. Automerge notes: - No ClawSweeper repair was needed after automerge opt-in. Validation: - ClawSweeper review passed for head 74a0a32. - Required merge gates passed before the squash merge. Prepared head SHA: 74a0a32 Review: openclaw#97299 (comment) Co-authored-by: zenglingbiao <[email protected]> Approved-by: takhoffman

fix(auto-reply): truncate user-facing text on UTF-16 boundary

74a0a32

Use truncateUtf16Safe in agent-runner-execution (message preview) and dispatch-from-config (plan working label) to prevent surrogate pair splitting when non-BMP characters straddle truncation boundaries.

openclaw-barnacle Bot added the size: XS label Jun 27, 2026

clawsweeper Bot merged commit 1b8b850 into openclaw:main Jun 27, 2026
149 of 158 checks passed

zenglingbiao mentioned this pull request Jun 28, 2026

fix(shared): use UTF-16 safe truncation in assistant error formatting #97289

Merged

Haderach-Ram mentioned this pull request Jun 28, 2026

Ecosystem Digest — 2026-06-28 Haderach-Ram/openclaw-radar#64

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(auto-reply): truncate user-facing text on UTF-16 boundary#97299

fix(auto-reply): truncate user-facing text on UTF-16 boundary#97299
clawsweeper[bot] merged 1 commit into
openclaw:mainfrom
zenglingbiao:fix/utf16-safe-auto-reply-truncation

zenglingbiao commented Jun 27, 2026

Uh oh!

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

Uh oh!

Takhoffman commented Jun 27, 2026

Uh oh!

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

zenglingbiao commented Jun 27, 2026

Summary

What Problem This Solves

Root Cause

Why This Fix

User Impact

Evidence

Real Behavior Proof

Tests and Validation

Uh oh!

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

Uh oh!

Uh oh!

Takhoffman commented Jun 27, 2026

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading