Possible chat rendering issue

[shanselman]

When I put in this text in the node app chat "it's in teh windows tray up, it's just along list of sessions with names liek copilot/acp and subagent" it rendered like this. Maybe an issue with the copilot/acp text? Interestingly, if I click the copy paste hover button I DO get the text back.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 28, 2026, 3:44 AM ET / 07:44 UTC.

Summary
Keep open: the report is a current, actionable native chat rendering bug, and I did not find a merged fix or canonical issue that already owns this exact collapsed user-bubble symptom.

Reproducibility: Do we have a high-confidence way to reproduce the issue? Not fully: the issue provides the exact prompt and screenshot, and source inspection explains the copy-versus-render split, but I did not run the Windows tray UI in this read-only Linux review.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
The bug is narrow and the likely native chat rendering files and validation path are clear, but the repair lane should still gather visible Windows UI proof.

Review details

Best possible solution:

Add a focused native chat regression and fix the user-bubble TextBlock/layout path so the exact prompt renders visibly while the copy action continues to return the original text.

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

Do we have a high-confidence way to reproduce the issue? Not fully: the issue provides the exact prompt and screenshot, and source inspection explains the copy-versus-render split, but I did not run the Windows tray UI in this read-only Linux review.

Is this the best way to solve the issue?

Is this the best way to solve the issue? Yes: keep this as a narrow native chat rendering bug and fix the user-bubble display path rather than merging it into the separate ACP session-list cleanup.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live Windows tray reproduction was run in this read-only Linux review; a fix PR should include visible current-head proof of the exact prompt rendering correctly.

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

Label changes

Label changes:

• add impact:message-loss: The report is about chat message text being visually suppressed in the native UI even though the copied payload remains intact.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal priority user-visible chat rendering bug with limited blast radius and no evidence of data loss or crash.
• impact:message-loss: The report is about chat message text being visually suppressed in the native UI even though the copied payload remains intact.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.UITests/OpenClaw.Tray.UITests.csproj --no-restore
• Capture visible current-head Windows tray chat proof showing the exact prompt renders correctly.

What I checked:

• Issue screenshot and text: The attached image shows the user message rendered as small empty-looking bubbles at 12:37 while adjacent assistant messages render normally; the issue body says copying the hover action returns the original prompt text.
• User bubble display path: Current main renders user prompt text through RenderUserEntry by creating a selection-enabled TextBlock and applying messageText through ApplyPlainSelectableInlines. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs:1112, d08a3e749973)
• Copy path remains separate: The hover copy action sends entry.Text directly to ClipboardHelper, which matches the report that copy works even when the visible bubble is wrong. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs:856, d08a3e749973)
• FunctionalUI TextBlock inline behavior: FunctionalUI has special handling to avoid clearing inlines when TextBlockElement.Text is empty, so the likely fix area includes the TextBlock/inlines render path rather than gateway message storage. (src/OpenClawTray.FunctionalUI/FunctionalUI.cs:1041, d08a3e749973)
• Adjacent prior fix is not the same symptom: The older closed clipping report was tied to markdown list rows measured by a horizontal StackPanel; tests now guard list rows with Grid Auto/Star columns, but this issue is a plain user prompt bubble rather than a list item. (tests/OpenClaw.Tray.UITests/MarkdownRendererListTests.cs:8, d08a3e749973)
• No open implementation PR found: GitHub search found no PR referencing this issue or the ACP/copilot rendering terms; the same search found a separate session-list issue, which is adjacent but not the rendering bug.

Likely related people:

• RBrid: Authored the native chat surface, markdown renderer work, and adjacent chat text-vanish/list-clipping fixes that cover the same renderer family. (role: feature owner and recent area contributor; confidence: high; commits: 6d21b6a810d2, 08c7dfc78aeb, fbfffe5ecc16; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs, tests/OpenClaw.Tray.UITests/MarkdownRendererListTests.cs)
• shanselman: Merged the native WinUI chat PR and has recent chat/FunctionalUI-related commits in the same surface, in addition to reporting this issue. (role: recent area contributor and merger; confidence: medium; commits: a9e421308d08, 733f9c291908, bc97b817584e; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, src/OpenClawTray.FunctionalUI/FunctionalUI.cs)
• kmahone: Merged the prior chat text-vanish and list-clipping fixes, which are adjacent to this rendering path and useful routing context. (role: merger of adjacent rendering fixes; confidence: medium; commits: fbfffe5ecc16, 62103341c6a2; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs)

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.

[clawsweeper]

🦞⚠️
Automatic implementation stopped before completion.
Reason: The automatic implementation worker stopped before all deterministic gates completed. Open the workflow run for the exact blocker.
Worker: https://github.com/openclaw/clawsweeper/actions/runs/28316917944