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

[jaythejet]

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.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex MSIX package self-corrupts to Modified, NeedsRemediation within minutes of launch, making the app unlaunchable ("This app can't open") #35737

Powered by Codex Action

[jaythejet]

UPDATE / correction to the report above: the claim that Beta 26.715 stays healthy turned out to be wrong — it just fails more slowly. On the same machine, OpenAI.CodexBeta 26.715.3651.0 survived ~1h45m of active use and then failed identically (AppModel-Runtime Id=6, 0x3CFC x5 at 2026-07-29 01:02:46 local; AppX container destroyed; package re-flagged Modified, NeedsRemediation). So BOTH current builds self-corrupt during active use — 26.721 within ~1 minute, 26.715 within a couple of hours.

This matches the deeper investigation in #35737 (sandbox/ACL pass appearing to modify the package's own install folder during use). Worth repeating from my verification: all 9,544 package files hash-verify clean against the AppxBlockMap while the package is flagged, so the corruption is security-descriptor/verdict state, not file contents.

Practical workaround until a fixed build ships: full Remove-AppxPackage + Store reinstall restores a working session each time (minutes-to-hours of active use per cycle). LongPathsEnabled=1 remains necessary on default machines for the separate MAX_PATH issue in the OP, but does not prevent the self-corruption.