Windows app unlaunchable ("This app can't open") - MSIX ships a file at a 275+ char path; 26.721 also re-flags itself in use

The ChatGPT desktop app for Windows (Store packages OpenAI.Codex 26.721.4979.0 and OpenAI.CodexBeta 26.715.3651.0) became permanently unlaunchable on my Windows 11 Home PC (build 26200, default settings): the window closes instantly, then Windows shows "This app can't open." Reinstalling, repairing, and resetting never helped.

Root cause (diagnosed with full event-log analysis and AppxBlockMap hash verification):

• The package ships this file at a 275-character absolute path (279 in the Beta):

C:\Program Files\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\resources\app.asar.unpacked\node_modules\@worklouder\device-kit-oai\node_modules\@worklouder\wl-device-kit\node_modules\serialport\node_modules\@serialport\bindings-cpp\build\release\bindings.node

• That exceeds Windows' default 260-char MAX_PATH (LongPathsEnabled=0 is the default).
• Windows' package-health check can't see the file, so it marks the package "Modified, NeedsRemediation." Every file hash-verifies perfectly against the AppxBlockMap - nothing is actually modified.
• Launches then fail, and even while the app is running it dies the moment it respawns a child process: AppModel-Runtime event ID 6, error 0x3CFC (ERROR_NEEDS_REMEDIATION), "error encountered while checking the machine-level package status."
• Because every fresh install ships the same path, reinstalling gets re-flagged within minutes - users are stuck with no way out through normal means.

Workaround attempted:

1. Set HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled = 1
2. Reboot (services cache the old value)
3. Fully remove and reinstall the app to clear the stuck machine-level verdict

UPDATE - the workaround only partially holds, and the difference between your two builds is diagnostic:

• Beta build 26.715.3651.0 (same >260-char path): stays Status=Ok and runs fine after the workaround, including through active use.
• Stable build 26.721.4979.0: freshly reinstalled with Status=Ok and stable while idle (verified 3+ min with child-process churn), but within ~1 minute of ACTIVE use it hits 0x3CFC on a child-process spawn again (post-reboot, LongPathsEnabled=1 in every process; observed 2026-07-28 23:43:36 local) and the package is re-marked "Modified, NeedsRemediation." So something 26.721 does at runtime that 26.715 does not (updater? elevated helper spawn?) re-triggers the machine-level status failure independent of the path-length trigger.

Suggested fixes: (1) flatten or shorten the dependency chain under app.asar.unpacked (the five nested node_modules levels under @worklouder/device-kit-oai) so the longest shipped path stays safely under 260 characters from the WindowsApps package root - every default-configured Windows machine is exposed; and (2) investigate what child-process spawn 26.721 performs during active use that fails the machine-level package status check even on a long-path-enabled, freshly-rebooted system where 26.715 passes.