[Windows ARM64 Desktop] App closes cleanly 10-35 seconds after launch on 26.707.9981.0

Summary

On Windows 11 ARM64, Codex Desktop 26.707.9981.0 enters a clean shutdown loop after launch. The app is visible briefly, its bundled ARM64 worker starts, then exits with code 0x00000000; Windows destroys the AppX container 10-35 seconds after launch. There is no Windows crash event, native exception, or Crashpad report.

This is distinct from #23787: this install has no SQLite migration error or startup dialog.

Environment

• Codex Desktop MSIX package: OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0
• Platform: Windows 11 Home, build 10.0.26200.8457, ARM64, 16 GB RAM
• Main app, bundled worker, and installed per-user Codex executable are all ARM64
• Previous package: 26.707.6957.0

Observed behavior

1. Launch Codex Desktop from the Start menu.
2. Windows logs creation of the AppX process.
3. About five seconds later, the bundled worker starts:

...\\OpenAI.Codex_26.707.9981.0_arm64__...\\app\\resources\\codex.exe

1. The worker exits normally after approximately 9.83 seconds with 0x00000000.
2. Windows destroys the AppX container shortly afterward. Subsequent launches repeat the same cycle.

The previous 26.707.6957.0 app container stayed open for about 40 hours. The first 26.707.9981.0 container remained open for about 4.5 hours, then every later launch closed within 10-35 seconds.

Expected behavior

Codex Desktop should remain open after startup and should display a recoverable error if its internal worker or host bootstrap cannot initialize.

Diagnostics

• No Application Error / Event ID 1000 event, Crashpad dump, out-of-memory event, or GPU fault is recorded for the current failure.
• Re-registering the package with Add-AppxPackage -Register did not change the behavior.
• The app's own startup log shows the Electron window as visible immediately before shutdown, and logs these warnings/errors:
• fs/readFile: The system cannot find the path specified. (os error 3)
• primary runtime update poll: Failed to download primary runtime manifest (404 Not Found)
• remote-control status: expected host connection not found

Those three signals also occur in earlier long-running sessions, so they are included as context rather than asserted as the direct cause.

Relevant local evidence is available on request:

• Windows event log: Microsoft-Windows-AppModel-Runtime/Admin
• Redacted app log: %LOCALAPPDATA%\\Packages\\OpenAI.Codex_2p2nqsd0c76g0\\LocalCache\\Local\\Codex\\Logs\\2026\\07\\15\\codex-desktop-<redacted>-t0-*.log

Please advise whether this clean worker exit is a known ARM64 desktop-app regression and what additional diagnostics would identify the shutdown decision.