Bump Microsoft.WindowsAppSDK from 2.3.1 to 2.4.0

[dependabot]

Updated Microsoft.WindowsAppSDK from 2.3.1 to 2.4.0.

Release notes

Sourced from Microsoft.WindowsAppSDK's releases.

2.4.0

Windows App SDK 2.4.0

Windows App SDK 2.4.0 is the latest stable release on the 2.x line, adding expanded input support, more precise LanguageModel response statuses, and targeted reliability fixes across input, Storage Pickers, MRT Core, app runtime isolation, composition, and XAML tooling.

What's new in WinAppSDK 2.4.0:

• Expanded input support. WinUI 3 apps can now use operating system touchpad and mouse haptics through Windows.Devices.Haptics, along with touchpad single-finger panning, when supported by the operating system and hardware.
• More precise LanguageModel response statuses. The new LanguageModelResponseStatus.UnsupportedLanguage and LanguageModelResponseStatus.LanguageMismatch values let apps distinguish unsupported-language and input/output-language mismatch conditions from generic errors.

Bug fixes:

Bug Fix	Runtime Compatibility Change
Fixed a crash that could occur when a touch or pen contact left a scrollable area with precise timing.	InputPointerSource_DepartingScrollInputCrashFix
Fixed an issue where the Storage Pickers left the calling WinUI app window without keyboard focus after the file dialog closed. The app now restores its previous focus. See GitHub issue microsoft/WindowsAppSDK#​6505.	StoragePickers_RestoreFocusAfterDialogCloses
Fixed a regression where MrmGetFilePathFromName returned ERROR_FILE_NOT_FOUND when the PRI file didn't exist instead of returning the documented fallback path. See GitHub issue microsoft/WindowsAppSDK#​5940.	ResourceManager_RestoreDefaultFallbackPath
Fixed an issue where MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY could be inherited by child processes, disrupting MRT Core and catalog lookups. See GitHub issue microsoft/WindowsAppSDK#​5987.	WindowsAppRuntime_BaseDirectoryIsolation
Fixed a crash when apps using the System Composition Engine called VisualInteractionSource.TryRedirectForManipulation.	N/A, operating system composition bridge fix
Fixed the access modifier on the generated C# entry point helper when DISABLE_XAML_GENERATED_MAIN is defined. See GitHub issue microsoft/microsoft-ui-xaml#​11245.	N/A, build-time tooling change

To see everything that's new and changed, see the full Windows App SDK 2.4.0 release notes.

Try it out

• Download the 2.4.0 NuGet package to use WinAppSDK 2.4 in your app.
• Download and update the WinUI Gallery to see the WinUI 3 updates firsthand.

Getting started

To get started using Windows App SDK to develop Windows apps, check out the following documentation:

• Install developer tools.
• Create a WinUI 3 app.
• Continue your development journey.

2.3.2-expA

Windows App SDK 2.3 Experimental A (2.3.2-experimentalA) 🧪

Windows App SDK 2.3 Experimental A is the latest experimental release, headlined by new DPI-aware window sizing from XAML, a substantial round of App Content Index indexing and reliability improvements, and additional Windows AI and speech APIs. It builds on the Windows App SDK 2.3.1 stable release and adds the experimental-only work described below.

What's new in WinAppSDK 2.3 Experimental A:

• Window.Width and Window.Height. New properties give apps a DPI-aware way to get and set a window's size in logical (client) pixels directly from code or markup, without reaching through Window.AppWindow and doing manual logical-to-physical DPI conversion. Companion Window.MinWidth, Window.MinHeight, Window.MaxWidth, and Window.MaxHeight properties constrain the window's size.
• App Content Index improvements. The experimental App Content Index APIs add faster batch indexing via AppContentIndexer.BatchAddOrUpdate, direct indexing of bitmap and image-stream content (with OCR and semantic options), static ranking boosts for individual content items or regions, ICU-based multilingual tokenization, and automatic recovery from index corruption. Indexing and query paths are also substantially faster, with more stable lexical ranking.
• Structured JSON generation. A new LanguageModel.GenerateStructuredJsonResponseAsync API lets apps generate structured JSON output from the on-device language model, making it easier to get typed, machine-readable results back from a prompt.
• Speech recognition cleanup. The experimental SpeechAudioProvider now implements IClosable, so apps can deterministically release the provider with Close/Dispose when they finish streaming audio.

To see everything that's new and changed, see the full Windows App SDK 2.3 Experimental A release notes.

Try it out

• Download the 2.3.2-experimentalA NuGet package to use WinAppSDK 2.3 in your app.
• Download and update the WinUI Gallery to see the WinUI 3 updates firsthand.

Getting started

To get started using Windows App SDK to develop Windows apps, check out the following documentation:

• Install developer tools.
• Create a WinUI 3 app.
• Continue your development journey.

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 18, 2026, 2:11 PM ET / 18:11 UTC.

ClawSweeper review

What this changes

This PR changes the shared Windows App SDK package version from 2.3.1 to 2.4.0 for the tray, setup UI, functional UI, and WinUI test projects.

Merge readiness

⚠️ Ready for maintainer review - 2 items remain

Keep open. Current main and the latest release still use Windows App SDK 2.3.1, so this one-line shared-runtime upgrade remains necessary. The patch has no source-level defect, but its body lacks post-upgrade real behavior proof required before merge.

Priority: P2
Reviewed head: 9688a39d3b878c62c20e34c09afdd07169bd00c7

Review scores

Measure	Result	What it means
Overall readiness	🦞 diamond lobster (5/6)	PR readiness rating was derived from proof quality, review findings, security review, and reviewer confidence.
Proof confidence	🌊 off-meta tidepool	Not applicable: Real behavior proof is not required for maintainer- or bot-authored pull requests.
Patch quality	🦞 diamond lobster (5/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: Real behavior proof is not required for maintainer- or bot-authored pull requests.
Evidence reviewed	7 items	Current main still needs the change: Current main sets the shared Windows App SDK version to 2.3.1, while this PR changes only that property to 2.4.0. Shared consumer boundary: Three production WinUI projects and the WinUI test project take Microsoft.WindowsAppSDK from the shared property, so the edit is the repository's established version-control point. Runtime-aware CI coverage: CI reads the shared version, installs that exact Windows App Runtime, then runs functional UI, setup, and real WinUI test suites.
Findings	None	None.
Security	None	None.

How this fits together

A repository-wide build property supplies the Windows App SDK version to the native Windows UI projects. Restore and packaging resolve that runtime before the tray, setup experience, and UI tests run.

flowchart LR
  Version[Shared package version] --> Restore[NuGet restore]
  Restore --> Tray[Tray desktop app]
  Restore --> Setup[Setup UI]
  Restore --> Functional[Functional UI]
  Restore --> Tests[WinUI runtime tests]
  Tray --> Device[Installed Windows device]
  Setup --> Device

Loading

Before merge

• Resolve merge risk (P1) - Windows App SDK 2.4.0 changes the runtime used by the packaged tray and setup UI; green CI does not by itself demonstrate installation and startup over an existing user installation.
• Complete next step (P2) - A maintainer needs to collect or accept the missing installed-runtime proof; no narrow code repair is indicated.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Shared runtime scope	1 property changed, 3 production projects and 1 WinUI test project consume it	A small diff changes the runtime version across every native Windows UI consumer.

Merge-risk options

Maintainer options:

1. Capture Windows upgrade proof (recommended)
   Build the current head, install or upgrade it on Windows, and attach redacted startup evidence for the tray and setup UI before merging.
2. Accept CI-only coverage
   Merge based on the completed Windows CI suite while explicitly accepting the remaining installed-upgrade uncertainty.

Technical review

Best possible solution:

Retain the shared-property upgrade and attach redacted current-head Windows proof that a 2.4.0 build installs or upgrades cleanly and starts the tray and setup UI.

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

Not applicable: this is a dependency-maintenance PR rather than a report of broken behavior.

Is this the best way to solve the issue?

Yes. Updating the existing repository-wide version property is the narrowest maintainable path; the remaining requirement is upgrade behavior proof, not another implementation route.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against d3151955c316.

Labels

Label changes:

• add rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🌊 off-meta tidepool and patch quality is 🦞 diamond lobster.
• remove rating: 🐚 platinum hermit: Current PR rating is rating: 🦞 diamond lobster, so this older rating label is no longer current.

Label justifications:

• P2: This is a normal-priority shared desktop-runtime upgrade with successful CI and a remaining compatibility proof need.
• merge-risk: 🚨 compatibility: Changing the shared Windows App SDK version can alter packaged runtime behavior for existing Windows installations.
• rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🌊 off-meta tidepool and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: Real behavior proof is not required for maintainer- or bot-authored pull requests.

Evidence

What I checked:

• Current main still needs the change: Current main sets the shared Windows App SDK version to 2.3.1, while this PR changes only that property to 2.4.0. (Directory.Build.props:4, d3151955c316)
• Shared consumer boundary: Three production WinUI projects and the WinUI test project take Microsoft.WindowsAppSDK from the shared property, so the edit is the repository's established version-control point. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:76, d3151955c316)
• Runtime-aware CI coverage: CI reads the shared version, installs that exact Windows App Runtime, then runs functional UI, setup, and real WinUI test suites. (.github/workflows/ci.yml:178, 9688a39d3b87)
• Completed PR checks: The supplied PR context reports successful win-x64 and win-arm64 builds, the main test job, setup-connect and recovery E2E checks, and repository hygiene. These are strong supplemental validation but not a contributor-provided real behavior artifact. (9688a39d3b87)
• Release remains on the old version: Release v2026.7.1 points at commit 4206611, whose shared property is still 2.3.1, so the requested upgrade is neither released nor already implemented on main. (Directory.Build.props:4, 4206611f2b2e)
• Feature-history routing: Blame attributes the current-main shared version line to the current-history boundary at commit 4206611; history also contains a prior merged Windows App SDK dependency update by Dependabot. (Directory.Build.props:4, 4206611f2b2e)

Likely related people:

• Scott Hanselman: The current-main shared package-version line is attributed to the 4206611 history boundary, and that commit is the latest release commit. (role: recent area contributor; confidence: medium; commits: 4206611f2b2e; files: Directory.Build.props)
• dependabot[bot]: Repository history includes its prior merged Windows App SDK upgrade on the same shared version file. (role: prior dependency updater; confidence: medium; commits: c79141641d24; files: Directory.Build.props)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

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

History

Review history (1 earlier review cycle)

• reviewed 2026-08-17T06:18:19.084Z sha 9688a39 :: needs maintainer review before merge. :: none