Repository navigation
[Bug] 2026.9.3: tray connects as node but no window ever opens — UI thread spins in InitialTailPositioner LayoutUpdated to StartBringItemIntoView loop #1409
Description
Summary
On 2026.9.3, OpenClaw.Tray.WinUI starts, shows its tray icon, and connects to the gateway as a node normally — but no window is ever created and clicking the tray does nothing. The UI thread pegs one core permanently inside an initial scroll-to-tail positioning loop in the chat list, and because that runs inside Application.Start, window creation never completes.
This does not reproduce on 2026.7.1.0, where the same machine's UI thread loop had a different signature (see "Regression range" below).
Environment
- OpenClaw Companion: 2026.9.3.0 (
ProductVersion 2026.9.3+84928c4370bc52d7f19127c65a637c7a28aab46e), Unpackaged install under%LOCALAPPDATA%\OpenClawTray\ - OpenClaw Gateway: 2026.9.3, protocol 4, loopback bind reached over an SSH tunnel
- OS: Windows 11 Pro 10.0.26200, x64
- Node mode enabled; gateway handshake succeeds (
hello-ok,Node status: Connected)
Symptoms
- Tray icon appears and reports connected.
- No main window is ever shown.
Process.MainWindowHandle == 0. - Clicking the tray icon does nothing.
OpenClaw.Tray.WinUIburns ~100% of one core indefinitely (439.6 s CPU across ~8 minutes of uptime).Win32_PerfFormattedData_PerfProc_Threadshows thread 0 at 97–99%, ThreadState 2 (Running).- Background work is unaffected — the node stays connected and the log keeps advancing.
Evidence
Four dotnet-stack report samples of the live process (three consecutive, plus one more after a deliberate revert-and-reproduce) all land on the same UI-thread stack:
Thread (0x5818):
[Native Frames]
Microsoft.WinUI!ABI.Microsoft.UI.Xaml.Controls.IItemsViewMethods.StartBringItemIntoView(class WinRT.IObjectReference,int32,class Microsoft.UI.Xaml.BringIntoViewOptions)
Microsoft.WinUI!Microsoft.UI.Xaml.Controls.ItemsView.StartBringItemIntoView(int32,class Microsoft.UI.Xaml.BringIntoViewOptions)
OpenClaw.Tray.WinUI!OpenClawTray.Chat.<ReactorItemsViewScrollController>...__InitialTailPositioner.StartTailRequest(value class OpenClawTray.Chat.TailNavigationRequest)
OpenClaw.Tray.WinUI!OpenClawTray.Chat.<ReactorItemsViewScrollController>...__InitialTailPositioner+<>c__DisplayClass20_0.<OnLayoutUpdated>b__0()
Microsoft.InteractiveExperiences.Projection!ABI.Microsoft.UI.Dispatching.DispatcherQueueHandler.Do_Abi_Invoke(int)
Microsoft.WinUI!ABI.Microsoft.UI.Xaml.IApplicationStaticsMethods.Start(class WinRT.IObjectReference,class Microsoft.UI.Xaml.ApplicationInitializationCallback)
Microsoft.WinUI!Microsoft.UI.Xaml.Application.Start(class Microsoft.UI.Xaml.ApplicationInitializationCallback)
OpenClaw.Tray.WinUI!OpenClawTray.Program.Main(class System.String[])
A second thread sits in GC.RunFinalizers → WinRT.IObjectReference.Finalize(), consistent with WinRT wrappers being allocated and discarded at rate inside the loop.
Reading: InitialTailPositioner handles LayoutUpdated and calls ItemsView.StartBringItemIntoView to position the chat at the newest message. That bring-into-view invalidates layout, which re-fires LayoutUpdated, which requests it again. The cycle never converges. Because it runs on the dispatcher inside Application.Start, the window never finishes being created.
Diagnostic trap worth noting
Process.Responding reports True throughout, which makes the app look healthy to any monitoring that checks it. .NET evaluates Responding against the main window, and with MainWindowHandle == 0 there is no window to test, so it answers vacuously. Anyone triaging this should check MainWindowHandle alongside Responding.
Relatedly, each tray click spawns a second process that logs Previous session did not exit cleanly and exits — it is trying to hand off to the pegged instance and failing. The log fills with what look like repeated crashes but are actually failed activations.
Reproduction / confirmation
- Launch
2026.9.3with node mode enabled and an existing agent session. - Observe the tray connects but no window appears; sample the process CPU and per-thread load.
- Set
"UseLegacyWebChat": truein%APPDATA%\OpenClawTray\settings.jsonand restart → window appears, CPU drops to 3–6%. - Set it back to
falseand restart → the failure reproduces immediately and identically, and a fresh stack sample lands on the same frames.
Step 4 was run deliberately to confirm the workaround is load-bearing rather than coincidental.
What does NOT help
"ShowChatToolCalls": false— mitigated the previous 2026.7.x UI-thread loop on this machine; has no effect on this one.- Deleting
last-chat-state.jsonto prevent thread restore — still 100% CPU, stillMainWindowHandle == 0. The positioner runs regardless of restored state, so this is not per-session-state dependent. - Resetting the agent session — the loop is in initial positioning, not in transcript volume.
Workaround
"UseLegacyWebChat": true in %APPDATA%\OpenClawTray\settings.json. This routes chat through the WebView surface and takes the native ItemsView chat out of service. Window creation then completes and the app is usable.
Regression range and probable culprit
ReactorItemsViewScrollController appears nowhere in this machine's 2026.7.1.0 stack captures (that build's loop was in ReactorHostControl.RenderLoop → ReactorChatComposer / ToolCallCardRenderer → LocalizationHelper.GetString). So this looks introduced in 2026.9.3.
The same class and LayoutUpdated handling were reworked immediately before this release:
- [Bug] Windows Hub chat: async content load (images/tables/progress cards) pins scroll at old position #1286 — "async content load pins scroll at old position" (names
Chat/ReactorItemsViewScrollController.cs,InitialTailPositioner,LayoutUpdated) - [Bug] Windows Hub chat auto-scrolls back to an old position after each assistant reply #1285 — "chat auto-scrolls back to an old position after each assistant reply"
- [Bug]: Chat does not auto-scroll to most recent message #1148 — "chat does not auto-scroll to most recent message" (still open)
Those changes were fixing "scroll settles in the wrong place"; this looks like the resulting "scroll never settles". A convergence guard on the tail request (bail once the target is satisfied, or cap re-entrant requests per layout pass) would likely close it.
Full dotnet-stack captures (three concurring samples plus the post-revert confirmation) are available on request — happy to paste them or attach if useful.
Activity
clawsweeper commentedon Sep 13, 2026
Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 12, 2026, 10:46 PM ET / September 13, 2026, 02:46 UTC.
Summary
Keep open: the released-build launch failure has concrete stack samples and a reversible workaround, and current main retains the affected code. An open workaround PR touches the same native call but explicitly does not establish that this hang is fixed.
Reproducibility: unclear. on current main: the reporter provides a strong release-level native/legacy reversal and repeated hot-stack samples, but no current-main native run establishes the precise hang mechanism.
Regression provenance
Possible regression — suspected (failure trace). No predecessor PR is attributed.
Ways to help us reproduce this
Next step
Route urgent native investigation through the scroll owner, coordinate with #1407 (fix(chat): work around WinUI session-switch crash), and establish whether navigation returns before choosing a repair.
Review details
Best possible solution:
Keep initial native tail positioning responsive and preserve reader anchoring, with a recovery launcher or Doctor action that can select the existing legacy surface when normal windows cannot open.
Do we have a high-confidence way to reproduce the issue?
Unclear on current main: the reporter provides a strong release-level native/legacy reversal and repeated hot-stack samples, but no current-main native run establishes the precise hang mechanism.
Is this the best way to solve the issue?
Unclear: a convergence cap is not yet justified because the handler already detaches before navigation; first determine whether the native call returns and whether the overlapping ScrollView workaround removes this launch failure.
AGENTS.md: found and applied where relevant.
Remaining risk / open question:
Codex review notes: model internal, reasoning medium; reviewed against bd9ce43b4d9c.
Label changes
Label changes:
P0: The current release reportedly opens no usable window, and recovery requires manually editing settings.impact:crash-loop: The reported sustained UI-thread hang leaves desktop interaction unavailable while consuming a CPU core.impact:ux-release-blocker: The launch and recovery path is blocked without an accessible in-product way to select the working chat surface.issue-rating: 🦐 gold shrimp: Current issue advisory state selects this label.clawsweeper:needs-info: Current issue advisory state selects this label.clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.Label justifications:
P0: The current release reportedly opens no usable window, and recovery requires manually editing settings.impact:ux-release-blocker: The launch and recovery path is blocked without an accessible in-product way to select the working chat surface.impact:crash-loop: The reported sustained UI-thread hang leaves desktop interaction unavailable while consuming a CPU core.Evidence reviewed
What I checked:
src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:181, bd9ce43b4d9c)src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, bd9ce43b4d9c)tests/OpenClaw.Tray.Tests/ChatTimelinePresentationTests.cs:55, bd9ce43b4d9c)Likely related people:
How this review workflow works
@clawsweeper re-reviewcomments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.@clawsweeper re-reviewor@clawsweeper re-runon an open PR or issue to request a fresh review only.@clawsweeper reviewto request a fresh review only.@clawsweeper autofix,@clawsweeper automerge,@clawsweeper fix ci, or@clawsweeper address review.@clawsweeper explainto ask for more context, or@clawsweeper stopto stop active automation.