Bug: user chat messages may render double

[calebeden]

While attempting to reproduce #899, I ran into a scenario where the app started rendering user messages twice. After doing this for a few messages, it went back to working normally for subsequent messages. The messages only appear once when I looked through the gateway web dashboard, and after relaunching the companion app, they now only show once as expected. The agent only ever saw a single copy of each message, so this is a rendering issue in the app.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 1, 2026, 2:45 PM ET / 18:45 UTC.

Summary
Keep open: current main contains the earlier user-bubble rendering fix and local echo suppression, but this fresh report says the Windows Companion visually double-rendered user messages while the gateway dashboard and agent saw only one copy, with no later merged fix or open PR owning this recurrence. The same reporter also has the broader related report at #899 open, so this should stay linked rather than closing one half prematurely.

Reproducibility: no. The report includes screenshots and clear observations, but the symptom was transient, no deterministic steps or logs for this exact double-render path are available, and this read-only Linux review did not run the WinUI app.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Manual review is appropriate because the symptom is real but transient, paired with an open same-author report, and needs a current-head Windows UI trace before a narrow repair can be assigned.

Review details

Best possible solution:

Use the current MCP chat automation plus visible WinUI/LVT proof to determine whether the duplicate is in the timeline snapshot or only the renderer, then fix the narrow chat provider/timeline path with regression coverage.

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

No. The report includes screenshots and clear observations, but the symptom was transient, no deterministic steps or logs for this exact double-render path are available, and this read-only Linux review did not run the WinUI app.

Is this the best way to solve the issue?

Unclear. The prior user-bubble TextBlock reset fix and current echo suppression are sensible narrow fixes, but this recurrence needs a fresh current-head trace before choosing renderer, provider, or reset-gating changes.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• There is no deterministic current-main reproduction yet; the screenshots establish a real occurrence, but not whether the duplicate exists in ChatDataSnapshot entries or only in the WinUI visual tree.
• The report overlaps Bug: user chat bubble rendering #899, but the double-render variant may be a distinct native-rendering or reset-gating edge case.

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

Label changes

Label changes:

• add P2: The issue is a user-visible native chat rendering defect with limited blast radius and no evidence of crash, security impact, or backend data loss.
• add impact:message-loss: The Companion visually duplicated or misrendered user chat messages even though the gateway and agent observed only one message.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P2: The issue is a user-visible native chat rendering defect with limited blast radius and no evidence of crash, security impact, or backend data loss.
• impact:message-loss: The Companion visually duplicated or misrendered user chat messages even though the gateway and agent observed only one message.

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
• Use app.chat.reset, app.chat.send, and app.chat.snapshot through winnode or raw MCP to compare snapshot entries against visible WinUI output.

What I checked:

• Issue report evidence: The issue body reports that user messages rendered twice only in the Companion app, appeared once in the gateway web dashboard, were seen once by the agent, and returned to normal after relaunch.
• Current user-bubble render path: Current main renders user prompt text through a selection-enabled TextBlock and ApplyPlainSelectableInlines, which is the same native UI surface implicated by the screenshots rather than gateway storage. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs:1133, 14022dc71222)
• Local echo suppression path: SendMessageAsync adds one optimistic local user entry and tracks the sent text so role=user chat echoes can be consumed instead of creating a second provider entry. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:327, 14022dc71222)
• Echo suppression handling: OnChatMessageReceived consumes matching local user echoes and otherwise renders remote user messages, so the exact double-render symptom needs a trace to distinguish provider state from visual duplication. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1781, 14022dc71222)
• Regression coverage exists but is not enough for this recurrence: Tray tests cover the standard local user echo suppression path, but this report is transient and tied to visible render state rather than a deterministic provider-only sequence. (tests/OpenClaw.Tray.Tests/OpenClawChatDataProviderTests.cs:400, 14022dc71222)
• Related open report: The reporter explicitly says this happened while trying to reproduce the broader open native chat-bubble rendering issue, whose screenshots/logs show a related first-render versus reopen mismatch.

Likely related people:

• shanselman: Authored the earlier user-bubble rendering fix and the current MCP chat automation commands used for the related repro/proof workflow. (role: recent area contributor; confidence: high; commits: 87dc3dc79d7c, 14022dc71222; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, tests/OpenClaw.Tray.Tests/ChatUserBubbleTextContractTests.cs, src/OpenClaw.Tray.WinUI/App.CapabilityHandlers.cs)
• RBrid: Recent GitHub file history shows substantial native chat timeline and data-provider work, including reset gating and multi-segment chat behavior adjacent to the reported surface. (role: feature-history owner; confidence: high; commits: 4e7982bafb86, 3fdfbfad837f, 5505a85da7df; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Chat/ChatTimelineReducer.cs)
• bkudiess: Recent chat data-provider history includes the slash-command catalog work, which touched the same provider/composer area involved in post-reset chat sends and current diagnostic paths. (role: recent adjacent contributor; confidence: medium; commits: a3c5e0bf6fce; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawComposer.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.

[calebeden]

Working on diagnosing the issue, it might be related to queued messages. When sending in quick succession, I don't get the exact kind of duplication from earlier, but I do start seeing duplicated and interleaved messages.

As before, this is resolved when restarting the app which fetches the transcript from the gateway