[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: this still needs some work. Reviewed September 22, 2026, 6:27 PM ET / 22:27 UTC.

Summary
Keep open. The sustained history-load hang remains unresolved by the available evidence. The released dependency rollback mitigates a related crash, and the open scrolling workaround explicitly does not establish resolution of this hang.

Reproducibility: no. high-confidence current-main reproduction is established. Released-build dumps provide a concrete large-history restoration trigger and native hotspot, but the current-main sustained hang has not been demonstrated.

Next step
Route current-main hang confirmation through karkarl and the existing scrolling investigation; an overlapping PR is open and the native failure does not yet have a proven bounded repair.

Review details

Best possible solution:

Make initial tail positioning complete reliably without blocking native layout, preserve final-message visibility and reader position, and provide visible safe-start recovery that does not require resetting conversation history.

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

No high-confidence current-main reproduction is established. Released-build dumps provide a concrete large-history restoration trigger and native hotspot, but the current-main sustained hang has not been demonstrated.

Is this the best way to solve the issue?

Unclear. The evidence favors investigating initial native tail positioning over assuming synchronous history projection is the cause; replacing it must also preserve accurate final-row navigation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Neither the released dependency rollback nor the open workaround establishes that the sustained native UI-thread hang is resolved on current main.
• An extent-based scrolling workaround must still reach the actual final message in mixed-height histories and preserve the reader's scroll-away position.

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

Label changes

Label changes:

• add P0: Automatic session restoration can leave Companion permanently unresponsive, with reported recovery requiring firewall intervention and conversation reset; this meets the required blocked-recovery override despite the manually selected P1.
• remove P1: Current review triage priority is P0, so this older priority label is no longer current.

Label justifications:

• P0: Automatic session restoration can leave Companion permanently unresponsive, with reported recovery requiring firewall intervention and conversation reset; this meets the required blocked-recovery override despite the manually selected P1.
• impact:crash-loop: Reported native UI hangs stop dispatcher progress and require process termination while the Gateway remains healthy.
• impact:ux-release-blocker: Affected users cannot recover inside the frozen Companion and have resorted to external network controls and ControlUI intervention.

Evidence reviewed

What I checked:

• Current main retains the reported native call: At reviewed main c706308, the layout callback dispatches StartTailRequest, which validates the tail and calls ItemsView.StartBringItemIntoView. This matches the reported dump boundary but does not independently prove a current-main hang. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, c7063081a2a5)
• Reported hangs have a concrete native hotspot: The September 4 and September 12 comments report startup/restoration hangs on released builds, including v2026.9.3. Redacted dump findings place the UI thread in StartBringItemIntoView with a valid final-row index. The latter report recovered only after blocking Companion networking and resetting the affected conversation through ControlUI. See [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167 (comment) and [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167 (comment).
• Released crash mitigation is not a verified hang fix: The v2026.9.4 release includes fix(chat): avoid session-switch crashes without clipping Markdown lists #1426 (fix(chat): avoid session-switch crashes without clipping Markdown lists). That merged change restores Reactor preview.12 and expressly preserves row-targeted scrolling. Its body records incomplete large-history switching proof. The previously affected c7c6fb0 build already referenced Reactor preview.12, so the rollback alone cannot establish resolution of the older sustained hang. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:104, c7063081a2a5)
• Affected release used the restored dependency version: The GitHub contents endpoint confirms Microsoft.UI.Reactor 0.1.0-preview.12 in the released build cited by the September 4 hang report. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:85, c7c6fb06be03)
• Open workaround has explicitly limited coverage: fix(chat): work around WinUI session-switch crash #1407 (fix(chat): work around WinUI session-switch crash) remains open at 1091062. It reports one successful selection into a synthetic 77-message history, but the extended switching loop did not complete and the sustained hang remains unverified. Its body explicitly limits its claim to the confirmed crash. (1091062a0987)
• Removing the layout wait is not established resolution: improve(chat): remove an unnecessary wait when opening chat history #1449 (improve(chat): remove an unnecessary wait when opening chat history) remains open. Its native experiment, with a disclosed temporary compatibility overlay, reproduced the invalid-anchor crash and completed zero session switches; the author correctly describes this as negative diagnostic evidence. (f683edcae3b4)

Likely related people:

• karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• dotMorten: 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.

[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

[ShiroePL]

Additional live repro + process dump data

I can reproduce a hang that appears closely related to #1167, but my trigger is different: I do not manually switch sessions.

The Companion hangs during startup/reconnect when it automatically restores the large default/main session.

This is from the released Windows Companion build, not current main, so I don't want to overstate it as the current-head trace requested above. However, I captured a full process dump while the UI was hung, and it narrows the hotspot considerably.

Environment

• OpenClaw Companion: 2026.7.1-4
• Product commit: c7c6fb06be036de512d824986a6eee6eca14abdb
• File version: 2026.7.2.0
• Gateway: 2026.9.1
• Process: OpenClaw.Tray.WinUI.exe
• Session: default/main session with a large history
• Repeated chat.history response size: approximately 311 KB

Reproduction

My reproduction does not require manually switching sessions.

The Companion automatically restores the default/main session during startup or reconnect.

The reliable reproduction for me is:

1. Start OpenClaw Companion while the Gateway is reachable, or reconnect the Companion to the Gateway.
2. The Companion automatically restores the default/main session.
3. It requests chat.history for that session (~311 KB response).
4. The history is loaded and the UI becomes permanently unresponsive.

If the Gateway is unreachable when the Companion starts, the WinUI remains responsive.

Reconnecting to the Gateway triggers the session restoration/history-load path and can reproduce the hang.

The relevant log sequence is consistently:

[GatewayClient] Sending frame: chat.history
Wizard response payload kind=Object len=311126

Other reproductions were around 311072–311186 bytes.

After this point, gateway/node health and tick traffic continues while the native UI is frozen.

Windows records an Application Hang (Event ID 1002). The process is eventually terminated after remaining unresponsive.

Dump result

I captured a full dump with dotnet-dump while Responding=False.

The process was consuming approximately one full CPU core during the hang, so this appears to be a CPU-bound UI-thread spin rather than a deadlock.

The main UI thread was captured in this path:

Program.Main
-> Application.Start
-> DispatcherQueueHandler.Do_Abi_Invoke
-> InitialTailPositioner.b__0()
-> InitialTailPositioner.StartTailRequest
-> ItemsView.StartBringItemIntoView(index, BringIntoViewOptions)
-> IItemsViewMethods.StartBringItemIntoView

The relevant OpenClaw code appears to be:

src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs

Specifically, OnLayoutUpdated detaches the layout handler and enqueues a dispatcher callback, which then calls StartTailRequest. The dump catches the UI thread after that callback enters the native WinUI ItemsView.StartBringItemIntoView() call.

In this reproduction, history retrieval/parsing has already completed before the hang. The UI thread is captured inside the native StartBringItemIntoView() call, and that call does not return for the duration of the observed hang.

The apparent sequence is therefore:

large history restored
-> ItemsView populated
-> initial tail-follow / tail positioning
-> LayoutUpdated
-> dispatcher callback
-> InitialTailPositioner.StartTailRequest
-> ItemsView.StartBringItemIntoView(...)
-> native WinUI call does not return
-> UI thread consumes ~1 core
-> DispatcherQueue stops making progress
-> Application Hang

This suggests that, at least for this reproduction, the immediate hotspot is initial tail positioning / StartBringItemIntoView() on the populated ItemsView, rather than JSON parsing or history projection itself.

So I would consider this a refinement of #1167 rather than proof of the original suspected mechanism: the large-history restore still triggers the failure, but the captured hotspot is downstream in the initial tail-scroll path.

This also appears directly related to the initial-tail positioning concern previously tracked in #1054: the dump catches the UI thread inside the same StartBringItemIntoView path discussed there.

This seems distinct from the snapshot-coalescing work in #1301: the process dump catches the UI thread after snapshot/history application, inside the native tail-scroll path.

Dump availability

I retained the full dump locally, but I'm intentionally not attaching it because it is a full heap dump and may contain session/auth data.

I can provide additional redacted thread stacks / dump-derived diagnostics if useful.

If needed, I can also try to reproduce the same case against a current main/nightly build to provide the current-head trace requested in the earlier review.