[Bug] Windows Companion crashes when opening older sessions that work in browser Dashboard

[schao523]

Summary

Windows Companion crashes when selecting certain older chat sessions from the session picker. The same sessions open successfully in the browser Dashboard against the same Gateway, so the session data and Gateway appear healthy and the failure seems isolated to the Windows Companion / WinUI client.

Environment

• Windows Companion / Windows Hub: v2026.9.3
• OpenClaw CLI / Gateway: v2026.9.4 (3a9d69d)
• Gateway runtime: Node v24.19.0
• Gateway URL: ws://127.0.0.1:18789
• Gateway status: running, connectivity probe OK
• Platform: Windows with OpenClaw Gateway running under WSL/systemd user service

Steps to reproduce

1. Start the OpenClaw Gateway and connect Windows Companion.
2. Open Chat in Windows Companion.
3. Open the session selector at the bottom (currently showing Main session).
4. Select one of the older sessions in the list (for example, older ragenius:... sessions).
5. Windows Companion crashes.
6. Open the browser Dashboard at http://127.0.0.1:18789/.
7. Open the same older session there.

Actual behavior

Windows Companion crashes when the older session is selected.

Expected behavior

The session should open normally in Windows Companion, as it does in the browser Dashboard.

Additional observations

• New/current chats work in Windows Companion.
• The same older chats are readable in the browser Dashboard, which strongly suggests this is a Companion-side rendering/session-loading issue rather than corrupt Gateway/session data.
• Gateway and CLI versions match (2026.9.4), and the Gateway is healthy.
• This appeared after upgrading the OpenClaw Gateway/session environment from an older installation to 2026.9.4.

Please let me know what Windows Companion crash logs or diagnostic bundle would be most useful to attach.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 13, 2026, 11:12 PM ET / September 14, 2026, 03:12 UTC.

Summary
Keep open: this is a concrete crash report against the latest release, and no verified fix is on main. Related reports and an open workaround PR provide useful leads, but this report's terminating exception has not been matched to them.

Reproducibility: no. high-confidence current-main reproduction is established: the report supplies clear steps, but the triggering history and exception stack are unavailable, and native execution was not performed.

Ways to help us reproduce this

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

Next step
Obtain a redacted crash.log or tray-log terminating stack and Windows build, then compare with #1407 (fix(chat): work around WinUI session-switch crash) before commissioning another fix.

Review details

Best possible solution:

Restore crash-free native history viewing without deleting sessions, and provide visible recovery that lets users reopen Companion without restoring a failing chat.

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

No high-confidence current-main reproduction is established: the report supplies clear steps, but the triggering history and exception stack are unavailable, and native execution was not performed.

Is this the best way to solve the issue?

Unclear: compare the terminating stack with the existing session-switch workaround before choosing a repair; another renderer rewrite or history reset is not justified.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The affected session's content shape and terminating exception are unknown; successful browser rendering does not identify the failing native operation.
• The open session-switch workaround may address this crash, but the related discussion also contains broader layout failures that remain uncorrelated.

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

Label changes

Label changes:

• add P1: The latest release crashes during ordinary history viewing, while current chats and browser access remain available.
• add impact:crash-loop: Selecting affected older sessions terminates the native Companion process.
• add issue-rating: 🦪 silver shellfish: 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 latest release crashes during ordinary history viewing, while current chats and browser access remain available.
• impact:crash-loop: Selecting affected older sessions terminates the native Companion process.

Evidence reviewed

What I checked:

• Concrete affected release and behavior: The supplied report identifies Companion v2026.9.3 and Gateway v2026.9.4, gives session-selection steps, and distinguishes crashing older sessions from working current chats and browser Dashboard history.
• Current production history and rendering boundary: The chat root requests history for the selected connected session. ChatHistoryLoader catches request/projection exceptions and publishes accepted history; ReactorChatTimeline builds native ItemsView rows. The scroll controller still invokes StartBringItemIntoView after identity and loaded-state checks. This identifies investigation boundaries, not this report's proven cause. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, bd9ce43b4d9c)
• Release and main retain identical chat source: Separate ls-tree checks for HEAD and v2026.9.3 returned the same Chat directory tree, 8497cefd5c4ebb1770cfe6c56084d9b3f3d7b4b5. GitHub releases/latest also returned v2026.9.3. No inspected evidence establishes a subsequent fix. (src/OpenClaw.Tray.WinUI/Chat, 84928c4370bc)
• Related discussion supplies native crash stacks: [Bug] v2026.9.3: OpenClaw.Tray.WinUI crashes (0xc000027b in Microsoft.UI.Xaml.dll) ~12 s after connect when opening a chat session with history; v2026.7.1-4 fine #1406 includes multiple-machine confirmations, clean portable extraction reproduction, ArrangeOverride exceptions, and sanitized dump-derived ItemsRepeater::MeasureOverride E_INVALIDARG stacks. Later reports also describe background crashes. These strengthen the investigation lead without proving that this issue has the same exception.
• Open workaround already owns a plausible repair: fix(chat): work around WinUI session-switch crash #1407 (fix(chat): work around WinUI session-switch crash) is open and unmerged. It replaces automatic StartBringItemIntoView calls with ScrollView.ScrollTo and reports a native synthetic-history run, while explicitly disclosing incomplete repeated-switch coverage. It is a candidate to compare against this report, not a verified fix for it. (1091062a0987)
• Existing tests do not establish crash-free native switching: The timeline presentation tests assert the current StartBringItemIntoView implementation and test stale-tail identity guards. These source and policy checks do not reproduce a native layout crash with the reporter's history. (tests/OpenClaw.Tray.Tests/ChatTimelinePresentationTests.cs:69, bd9ce43b4d9c)

Likely related people:

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