[Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1)

[sebastian-openclaw]

Summary

OpenClaw Companion v2026.7.1 can become unresponsive when switching to a session whose history load returns approximately 200 messages. The gateway remains healthy while the native WinUI stops updating, and Windows records AppHangB1.

This appears related to synchronous history projection/snapshot rendering, but is distinct from the per-event streaming flood tracked in #1150 and its candidate fix #1158.

Environment

• OpenClaw Companion: v2026.7.1
• Release commit: 4206611f2b2e47cd575e1c8aa94e3e7708f6dd96
• Windows desktop client: OpenClaw.Tray.WinUI.exe

Reproduction

1. Have a session with enough history for the Companion to load the approximately 200-message history window.
2. Switch from another session to that session.
3. Wait while the history response is projected and the resulting snapshot is rendered.

Reproduced on 2026-08-16 around 12:04 local time.

Actual behavior

• The native WinUI becomes unresponsive or stops visually updating.
• Windows records AppHangB1.
• Gateway health remains OK during the UI hang.

Expected behavior

Switching sessions and loading the bounded history window should remain responsive, including for histories containing many agent/tool events.

Exact-release source path

In the v2026.7.1 source, OpenClawChatDataProvider folds the loaded history (up to 200 messages) into timeline state and publishes the resulting snapshot. The Changed handler in OpenClawReactorChatRoot then calls setSnapshot(args.Snapshot), triggering the native WinUI/React render.

Even though this is one publication rather than the per-event publication storm in #1150, projecting and synchronously rendering a large snapshot immediately after a session switch can saturate the UI thread.

Relevant source:

• src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs
• the OpenClawReactorChatRoot snapshot Changed handler

Why this is not a duplicate of existing reports

• [Bug] OpenClaw.Tray.WinUI v2026.7.1 UI hang/crash (AppHang + APPCRASH combase.dll) under heavy agent event streaming #1150 is the canonical report for UI saturation under a high-rate live agent-event stream. Draft PR fix(tray): bound streaming UI dispatch work #1158 bounds/coalesces those per-event paths, but does not appear to batch the initial history projection/render during a session switch.
• Chat UI virtualization (perf on large conversations) #860 was closed by merged PR Virtualize chat timeline rows #898, which virtualized chat timeline rows. That merge is already an ancestor of v2026.7.1, so this hang reproduced with row virtualization present.

Suggested fix/validation area

• Batch or incrementally project history where practical.
• Avoid a large synchronous full-timeline render on the UI thread after session selection.
• Add a current-head WinUI responsiveness test that switches into a session with 200 varied history messages, including dense agent/tool entries.
• Preserve scroll restoration, selection, and terminal event state while batching.

Crash scope

There was also one separate 2026-08-13 crash involving CoreMessagingXP.dll. There is not enough evidence to attribute that crash to this history-load hang, so this report is limited to the recurring AppHang/UI-saturation behavior.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 16, 2026, 3:05 PM ET / 19:05 UTC.

Summary
This is a distinct, still-actionable WinUI responsiveness report. Current main retains the reported history replay and one-shot snapshot path, while the open streaming-flood work addresses a different trigger.

Reproducibility: no. current-main live reproduction has been run. The release reproduction is concrete and the relevant source path is unchanged on current main, making the mechanism source-reproducible but not yet runtime-verified.

Root-cause cluster
Relationship: canonical
Canonical: #1167
Summary: This issue describes the distinct initial-history transition rather than the live streaming-event flood.

Members:

• adjacent_distinct: [Bug] OpenClaw.Tray.WinUI v2026.7.1 UI hang/crash (AppHang + APPCRASH combase.dll) under heavy agent event streaming #1150 - That report concerns high-rate live agent events, while this report concerns a completed history snapshot after selecting a session.
• adjacent_distinct: fix(tray): bound streaming UI dispatch work #1158 - The draft PR is scoped to bounded streaming dispatch work and does not own the initial-history trigger.
• partial_overlap: Virtualize chat timeline rows #898 - Virtualized rows reduce realization cost but do not test or budget the completed history replay and snapshot transition.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

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

Next step
Capture a current-head Windows trace with dense 200-message history before selecting a bounded repair that preserves session, scroll, and terminal-event behavior.

Review details

Best possible solution:

Add a native current-head session-switch proof using 200 mixed history messages, then budget the history-to-render workload at the provider/timeline boundary without changing the authoritative completed transcript.

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

No current-main live reproduction has been run. The release reproduction is concrete and the relevant source path is unchanged on current main, making the mechanism source-reproducible but not yet runtime-verified.

Is this the best way to solve the issue?

Unclear. Blindly batching can increase render churn, so the best repair should follow a native current-head trace with dense tool and agent history while preserving existing timeline invariants.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A history message can expand into several timeline and tool-card entries, so a count-only 200-message repair may miss the expensive real-world shape or regress scroll and terminal-event invariants.

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

Label changes

Label changes:

• add P1: The report describes an AppHang during ordinary session switching that leaves the desktop client unusable until recovery.
• add impact:crash-loop: The reported AppHangB1 leaves the native client unresponsive while loading history.
• 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.

Label justifications:

• P1: The report describes an AppHang during ordinary session switching that leaves the desktop client unusable until recovery.
• impact:crash-loop: The reported AppHangB1 leaves the native client unresponsive while loading history.

Evidence reviewed

What I checked:

• Current history rebuild: Current main orders and folds every returned history message into a rebuilt timeline while holding the provider state lock. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1104, fc9add75eda7)
• One-shot UI snapshot: After history completes, the provider posts one completed snapshot; the chat root immediately applies it with setSnapshot. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1829, fc9add75eda7)
• Existing large-row proof is narrower: The native UI test proves virtualization and scrolling for 241 generic rows, but it does not exercise a history response with dense tool and agent entries or measure session-switch responsiveness. (tests/OpenClaw.Tray.UITests/ChatTimelineVirtualizationProofTests.cs:34, fc9add75eda7)
• Release-to-main comparison: The provider, chat root, and virtualized timeline have no diff from reported release v2026.7.1 to current main, so no current-main fix provenance exists. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1047, fc9add75eda7)
• Current path attribution: Blame attributes the present history publication method to the imported v2026.7.1 source commit; earlier per-line provenance is not available in this checkout. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1829, 4206611f2b2e)

Likely related people:

• Scott Hanselman: Current-line blame attributes the history rebuild and publication path to the v2026.7.1 imported source commit. (role: current history-path contributor; confidence: medium; commits: 4206611f2b2e; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawReactorChatRoot.cs)
• TurboTheTurtle: Merged work on the virtualized native chat timeline is directly relevant to validating any history-rendering repair. (role: adjacent timeline contributor; confidence: high; commits: fcc74778a35c; files: src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs, tests/OpenClaw.Tray.UITests/ChatTimelineVirtualizationProofTests.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.

[MilkyWay008]

Saw the AppHangB1 when switching into a dense session, that is the client folding ~200 messages into one render on the UI thread, so it freezes no matter how healthy the gateway is. Until the batched projection lands, the practical stopgap is keeping those hot sessions lean (archive or clear older chats so the load stays under the render threshold, and avoid the really dense ones for now). I would grab a current-head Windows trace during the switch too, since it looks like no fix exists on main yet, that will pin the trigger fast. Oh also, btw, I built a portable Hermes OTG and I run it on USB as my rescue agent for exactly these client-froze-and-wont-recover moments, check it, imo it'll help you. https://github.com/MilkyWay008/Hermes-OTG

[dotMorten]

@sebastian-openclaw I was trying to reproduce this issue and generated a bunch of long fake sessions.
It felt pretty snappy to me and is clearly using virtualization for rendering. Am I missing something in how I'm trying to reproduce it?

Recording.2026-08-18.093421.mp4