fix(mxc): align build and UBR checks with mxc-sdk platform detection - #810
fix(mxc): align build and UBR checks with mxc-sdk platform detection#810QQSHI13 wants to merge 2 commits into
Conversation
Previously, clicking a session in the Sessions tab or a chat toast
notification always opened the default/main session instead of the
specific session.
Changes:
- Add App.PendingChatSessionKey as a fallback when HubWindow does not
exist (background notifications, closed HubWindow).
- Thread sessionKey through ToastActivationRouter (Action<string?>).
- Embed sessionKey in chat toast arguments and route it on activation.
- ChatPage (functional): consume pending key from both HubWindow and
App fallbacks; use !string.IsNullOrEmpty guard to treat empty string
as null.
- ChatPage (WebView): consume pending key and append &session={key} to
the navigation URL, or pass it through GatewayChatHelper on initial
WebView init.
- SessionsPage: write key to CurrentApp.PendingChatSessionKey in
addition to hub.PendingChatSessionKey.
- Update tests for the new OpenChat Action<string?> contract.
Fixes session routing for both native FunctionalUI and legacy WebView2
chat surfaces.
The MxcAvailability probe used stale build constants (26300 / UBR 8289) instead of matching the @microsoft/mxc-sdk getPlatformSupport() values (build >= 26100, UBR >= 7965 for builds 26100-26500, no UBR minimum for builds >= 26500). This caused false-negative sandbox unavailability on newer Windows builds that the SDK considers supported. Changes: - Replace exact-equality build check with minimum-build (>= 26100) check - Align UBR minimum from 8289 to 7965 - Relax UBR requirement for builds >= 26500 (SDK policy) - Update tests to cover the expanded build range
|
Codex review: needs real behavior proof before merge. Reviewed June 24, 2026, 8:56 AM ET / 12:56 UTC. Summary Reproducibility: yes. source-reproducible for the blocking patch defect: current Tray tests explicitly forbid the ChatPage call shape introduced by this PR. The MXC runtime claim itself was not reproduced because this read-only review has no Windows/MXC proof from the contributor. Review metrics: 3 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Drop the stale ChatPage hunk and land MXC support through a maintainer-approved, proof-backed policy path with required validation and redacted Windows runtime evidence. Do we have a high-confidence way to reproduce the issue? Yes, source-reproducible for the blocking patch defect: current Tray tests explicitly forbid the ChatPage call shape introduced by this PR. The MXC runtime claim itself was not reproduced because this read-only review has no Windows/MXC proof from the contributor. Is this the best way to solve the issue? No. The narrow maintainable path is to remove the stale ChatPage change and resolve MXC support through the canonical proof-backed policy direction rather than merging a standalone broadened gate. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 260fb90c6dc7. Label changesLabel justifications:
Evidence reviewedSecurity concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
Problem
MxcAvailability.Probe() was using stale build constants that didn't match the @microsoft/mxc-sdk getPlatformSupport() source of truth:
This caused false-negative sandbox unavailability on newer Windows Insider builds that the SDK considers fully supported.
Root Cause
The C# code had to reimplement the SDK's getPlatformSupport() because the tray app is a native WinUI 3 application with no bundled Node.js runtime, so it cannot call the TypeScript SDK at runtime. The reimplementation was not kept in sync when the SDK updated its requirements.
Changes
src/OpenClaw.Shared/Mxc/MxcAvailability.cs:
tests/OpenClaw.Shared.Tests/Mxc/MxcAvailabilityTests.cs:
Validation
All MxcAvailability tests pass with the new constants (14 passed, 0 failed).