[Bug] 2026.9.3: tray connects as node but no window ever opens — UI thread spins in InitialTailPositioner LayoutUpdated to StartBringItemIntoView loop

[Vivek-Rav]

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

1. Tray icon appears and reports connected.
2. No main window is ever shown. Process.MainWindowHandle == 0.
3. Clicking the tray icon does nothing.
4. OpenClaw.Tray.WinUI burns ~100% of one core indefinitely (439.6 s CPU across ~8 minutes of uptime).
5. Win32_PerfFormattedData_PerfProc_Thread shows thread 0 at 97–99%, ThreadState 2 (Running).
6. 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

1. Launch 2026.9.3 with node mode enabled and an existing agent session.
2. Observe the tray connects but no window appears; sample the process CPU and per-thread load.
3. Set "UseLegacyWebChat": true in %APPDATA%\OpenClawTray\settings.json and restart → window appears, CPU drops to 3–6%.
4. Set it back to false and 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.json to prevent thread restore — still 100% CPU, still MainWindowHandle == 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.

[clawsweeper]

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

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

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:

• Repeated managed stack samples cannot distinguish one non-returning WinUI call from repeated calls; adding a retry cap without that distinction may leave the launch failure unchanged.

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

Label changes

Label changes:

• add P0: The current release reportedly opens no usable window, and recovery requires manually editing settings.
• add impact:crash-loop: The reported sustained UI-thread hang leaves desktop interaction unavailable while consuming a CPU core.
• add impact:ux-release-blocker: The launch and recovery path is blocked without an accessible in-product way to select the working chat surface.
• add issue-rating: 🦐 gold shrimp: 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:

• 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:

• Concrete released-build failure: The supplied issue snapshot identifies v2026.9.3, four reported live stack samples in InitialTailPositioner.StartTailRequest, sustained UI-thread CPU use, and a deliberate native-to-legacy-to-native reversal that restores and then breaks window opening. (84928c4370bc)
• Current callback does not unconditionally resubscribe: OnLayoutUpdated calls DetachLayout before dispatching navigation. A successful StartTailRequest returns true without rearming LayoutUpdated. This does not establish the report's proposed repeated-handler mechanism; the native call could itself remain busy, or another lifecycle transition could retrigger positioning. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:181, bd9ce43b4d9c)
• No repair in current main: The release-to-main comparison produced no differences in the scroll controller or tail-navigation policy. The latest GitHub release remains v2026.9.3, published September 12, 2026. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, bd9ce43b4d9c)
• Existing tests cover guards, not native convergence: The timeline tests assert handler cleanup, discrete requests, and observation-only ViewChanged behavior; pure policy tests reject stale identities and generations. These checks do not exercise a real WinUI initialization hang. (tests/OpenClaw.Tray.Tests/ChatTimelinePresentationTests.cs:55, bd9ce43b4d9c)
• Open overlapping workaround: fix(chat): work around WinUI session-switch crash #1407 (fix(chat): work around WinUI session-switch crash) replaces StartBringItemIntoView with ScrollView.ScrollTo in this exact owner. Its body explicitly excludes proof that the sustained UI-thread hang is resolved, so it is relevant coordination work but not a verified fix or duplicate target.
• Earlier reports do not establish this fix: The human closing comment on [Bug] Windows Hub chat: async content load (images/tables/progress cards) pins scroll at old position #1286 says it was closed as a duplicate of [Bug]: Chat does not auto-scroll to most recent message #1148, not through a new repair. The reporter's comment at [Perf] Windows Hub idle: OpenClaw.Tray.WinUI pegs one CPU core continuously (~100%+), causing window-drag jank #1287 (comment) explicitly distinguishes the older Reactor render loop from this newer navigation hang.

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)
• Scott Hanselman: 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.