[Bug] Native chat markdown: text after "——" is truncated; long lines/table cells don't wrap

[GoldenHornKing95]

Environment

• Windows Hub: v2026.7.1-4 (stable, x64)
• OS: Windows 10 LTSC 21H2 (build 19044.2311), zh-CN locale
• Gateway: OpenClaw 2026.8.2 on WSL2
• Chat content: Chinese (CJK), markdown-formatted agent replies

Bug 1 — text truncated after certain markdown constructs

Agent replies containing the CJK em-dash —— lose everything after it in the native chat window.

Repro: an agent reply containing 快速视图——在聊天框试试，如果没反应告诉我 renders only 快速视图 in Hub chat. The same message renders fully in the web Control UI, so the content is intact server-side — this looks like a native renderer issue.

Bug 2 — long lines don't wrap

Long single-line text (especially inside markdown table cells) does not wrap to the window width in the native chat window; lines appear cut off. The same content wraps correctly in the web Control UI.

Expected: native chat renders markdown at parity with the web Control UI.
Actual: truncation after ——; no wrapping of long lines/table cells.

[clawsweeper]

Codex review: this still needs some work. Reviewed October 3, 2026, 4:40 PM ET / 20:40 UTC.

Summary
Keep open: merged table and list-wrapping improvements do not establish that the exact CJK truncation or long-table-cell symptoms are fixed. Related clipping reports overlap, but none accounts for both reported cases.

Reproducibility: no. high-confidence current-main reproduction has been established. The exact CJK sentence is actionable, but native execution and representative long-cell input remain needed to separate text loss from layout clipping.

Next step
Verify the exact sentence and long prose/table cells in current native chat, compare visible text with copied message content, and capture redacted diagnostics before selecting a bounded repair.

Review details

Best possible solution:

Preserve complete CJK text and finite-width prose/table reflow in the active Reactor path while retaining inert links, images, and disabled HTML.

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

No high-confidence current-main reproduction has been established. The exact CJK sentence is actionable, but native execution and representative long-cell input remain needed to separate text loss from layout clipping.

Is this the best way to solve the issue?

Unclear until the failing layer is identified. A focused repair in the active Reactor parsing or width-layout path is preferable to changing the retired local renderer or assuming the dependency upgrade fixes both symptoms.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The exact CJK sentence and long prose/table cells have not been verified on current native chat, so missing text cannot yet be distinguished from visual clipping.

Codex review notes: model internal, reasoning medium; reviewed against 7127c16d537c.

Label changes

Label changes:

No label changes.

Label justifications:

• P2: The report identifies unreadable native-chat output in an official release, with limited scope and no demonstrated core-runtime outage.
• impact:ux-friction: Native replies lose readable content while the same messages remain accessible through the web Control UI.

Evidence reviewed

What I checked:

• Concrete affected-release report: The issue identifies official Windows Hub v2026.7.1-4, Windows 10 LTSC with zh-CN locale, and an exact Chinese sentence whose suffix disappears in native chat while remaining visible in the web Control UI. The supplied human discussion contains no current-version confirmation.
• Active production renderer and dependency boundary: Assistant text enters BuildSafeMarkdown, which sanitizes it and calls Microsoft.UI.Reactor.Factories.Markdown with Tables and NoHtml enabled. This is the active path, rather than the older local ChatMarkdownRenderer. The tray project currently pins both Reactor packages to preview.12. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs:577, 7127c16d537c)
• Exact sentence bypasses sanitizer transformations: Sanitize returns strings containing neither '[' nor '!' unchanged. The reported sentence meets that condition, so this sanitizer does not explain its missing suffix; parsing or native layout still needs verification. (src/OpenClaw.Tray.WinUI/Chat/ChatMarkdownSanitizer.cs:78, 7127c16d537c)
• Existing table proof has narrower coverage: Merged fix(chat): render Markdown tables #1260 (fix(chat): render Markdown tables) exercises a short English financial table at 320 pixels. The downloaded screenshot was inspected and shows the complete table and separate code fence. Current tests assert wrapping properties and cell widths, but this fixture does not exercise the reported CJK sentence or a genuinely long table cell. (tests/OpenClaw.Tray.UITests/ReactorMarkdownTableProofTests.cs:17, 7127c16d537c)
• Table implementation predates the affected build: The table merge commit is contained in both the reported v2026.7.1-4 tag and latest release v2026.9.4. Its presence therefore does not independently establish that this later report is resolved. (4ae1c366afca)
• Merged list mitigation preserves the dependency pin: fix(chat): avoid session-switch crashes without clipping Markdown lists #1426 (fix(chat): avoid session-switch crashes without clipping Markdown lists) documents rolling Reactor back to preview.12 and replacing list-row horizontal stacks with Auto/Star grids. Current mounted tests check complete English list text and reflow at 240 and 600 pixels. This is positive list-specific evidence, not proof of CJK or long-cell recovery. (tests/OpenClaw.Tray.UITests/ReactorMarkdownListProofTests.cs:25, 3dda3cf87fb9)

Likely related people:

• shanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Barbara Kudiess: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.

[github-actions]

This issue has been automatically marked as stale due to inactivity.
Please add updated OpenClaw Windows details or it will be closed.

[clawsweeper]

🦞🔧
ClawSweeper is automatically building a fix for this issue.

The issue review finished and no active implementation pull request was found.

Automatic implementation progress:

• State: Queued
• Detail: Review complete; no active implementation PR was found. The Codex implementation worker is queued.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/36378047537
• Updated: 2026-09-28T04:36:56.381Z
• Opt out: add clawsweeper:manual-only or clawsweeper:human-review.