broken view tools call native vs normal brovser view

[danilovmy]

sometimes agent calls tools and tell me about it. But i see - in native chat view the tools call is not same as in browser chat view.

Native

Browser:

It is not a big bug, but i see the difference.

Version: windows 10

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 30, 2026, 4:41 AM ET / 08:41 UTC.

Summary
Keep open: the report is understandable and user-visible, and the current native chat implementation still has native-specific tool activity rendering rather than proven browser-view parity. Related merged fixes improved tool metadata, tool ordering, and stale failed-tool behavior, but I did not find evidence that current main exactly solves this reported visual mismatch.

Reproducibility: no. live current-head Windows/browser reproduction was run. The supplied screenshots show the mismatch on v0.6.3, and current source still shows native-specific multi-tool card wording, so the path is source-reproducible but not fully proven against current main.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
Maintainers should first decide whether native chat should visually match the browser activity card exactly or retain a native-specific presentation before queuing a fix.

Review details

Best possible solution:

Define the intended browser/native parity for tool activity cards, then either adjust the native renderer/provider to show the same useful count, tool names, and details, or document the intentional native-specific presentation with current-head visual proof.

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

No live current-head Windows/browser reproduction was run. The supplied screenshots show the mismatch on v0.6.3, and current source still shows native-specific multi-tool card wording, so the path is source-reproducible but not fully proven against current main.

Is this the best way to solve the issue?

Unclear until maintainers choose the desired parity target. A narrow native chat renderer/provider change is likely maintainable after that decision, but exact browser matching should not be inferred from the report alone.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The screenshots are from OpenClaw Hub v0.6.3, while current main and v0.6.11 include several later native chat fixes, so the exact current-head mismatch still needs a Windows/browser side-by-side check.
• Exact parity may be a UX/product decision: current native cards intentionally use native grouping and labels, while the browser view uses an activity block.

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

Label changes

Label changes:

• add P3: This is a low-urgency but user-visible chat UX parity issue with no evidence of data loss, crash, security impact, or broken message delivery.
• add impact:other: The issue affects maintainers' native chat presentation quality, but it does not fit the owned data-loss, security, crash, message-loss, session-state, or auth-provider impact labels.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: 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.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a low-urgency but user-visible chat UX parity issue with no evidence of data loss, crash, security impact, or broken message delivery.
• impact:other: The issue affects maintainers' native chat presentation quality, but it does not fit the owned data-loss, security, crash, message-loss, session-state, or auth-provider impact labels.

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
• Run the tray app from current head and capture side-by-side native chat and browser chat screenshots for the same multi-tool conversation.

What I checked:

• Reporter screenshot evidence: Downloaded and inspected the issue attachments: the native v0.6.3 screenshot shows a generic single tool card labeled "tool · Tool", while the browser screenshot shows an activity block with many tools and specific names such as Bash and Apply Patch.
• Current native renderer still uses native-specific multi-tool wording: Current main renders multi-step tool bursts as a native "Task · {stepCount} steps" summary with a tool-name list, which is useful but not the same wording/shape as the browser activity header shown in the report. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs:1847, 84fcf8ae626f)
• Tool event mapping is present on current main: Current main maps gateway tool item start/end/error phases into ChatToolStartEvent, ChatToolOutputEvent, and ChatToolErrorEvent, so the remaining question is presentation/parity rather than a missing tool-event pipeline. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:2723, 84fcf8ae626f)
• Related fixed issue is narrower: A prior native-vs-web issue about stale failed tool events was closed by a merged PR that preserves insertion order only for failed-tool turns; that does not prove this generic activity-card parity report is solved. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs:2178, c149f77c813c)
• Related tool metadata work exists: Merged PR 479 added a tool metadata cache and flattened-history recovery, which positively addresses one likely cause of generic tool names, but the current report still needs current-head visual comparison before closure. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:4848, 9478e953dc38)
• Repository policy read and applied: AGENTS.md was read fully; because this concerns chat UI, any future fix should run the required build/shared/tray validation and include visible current-head proof of the changed native chat state. (AGENTS.md:49, 84fcf8ae626f)

Likely related people:

• RBrid: PR history shows this person introduced the Native WinUI chat experience and later merged major native chat reconciliation fixes touching the provider, reducer, and timeline. (role: native chat feature owner and recent area contributor; confidence: high; commits: 08cab69a038c, 5505a85da7df; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Chat/ChatTimelineReducer.cs)
• christineyan4: Merged PR 479 added tool metadata caching, flattened tool-output recovery, and the tool-call visibility toggle, all directly adjacent to this report. (role: tool metadata and chat tool-call contributor; confidence: high; commits: 9478e953dc38; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, tests/OpenClaw.Tray.Tests/ToolMetaCacheTests.cs)
• ranjeshj: Merged PR 466 added ID-based parallel tool-call tracking and truthful interrupted state in the shared chat reducer and native provider paths. (role: tool-call reducer contributor; confidence: medium; commits: ca09b2132a0f; files: src/OpenClaw.Chat/ChatTimelineReducer.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, tests/OpenClaw.Tray.Tests/ChatTimelineReducerTests.cs)
• kenehong: Git history shows XAML review feedback work on the chat tool-card rendering surface before later parity fixes built on it. (role: tool-card UI contributor; confidence: medium; commits: 7dd6bad53b86; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.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.