[Windows][26.915.4065.0] Store auto-update deregisters old version, fails to register new one (0x80073D28, packaged sandbox service) — app becomes silently unlaunchable

What version of the Codex App are you using (From “About Codex” dialog)?

26.908.4834.0 (Microsoft Store package OpenAI.Codex_26.908.4834.0_x64__2p2nqsd0c76g0), before the failed auto-update to 26.915.4065.0. After applying the fix below the app runs 26.915.4065.0.

What subscription do you have?

pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.9445 x64 (Windows 11). User account is a member of the local Administrators group, but the Store auto-update path runs non-elevated.

What issue are you seeing?

The Microsoft Store background auto-update terminated the running Codex app and then failed to register the new version, leaving no launchable Codex on the machine at all. Clicking the Start-menu entry does absolutely nothing: no window, no process, no error dialog.

Timeline (2026-09-19, local time, from AppXDeploymentServer/Operational and TWinUI/Operational event logs):

1. ~11:32 — Store stages OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0 (files fully present in C:\Program Files\WindowsApps).
2. 16:41 — The running 26.908.4834.0 instance is terminated by the update; registration of 26.915.4065.0 fails with 0x80073D28 — ERROR_PACKAGED_SERVICE_REQUIRES_ADMIN_PRIVILEGES ("Failed to reach state Approved").
3. After the failed update, the old version is deregistered and the new version is left staged-but-unregistered.
4. Every subsequent launch attempt (Start-menu click) triggers an on-demand RegisterByFamilyName (AppXDeploymentServer event 603), which fails with 0x80073D28 each time. TWinUI event 1621 records "Attempted activation of the app … operation completed successfully" — from Windows' perspective the activation "succeeded", yet no process is ever created.

Root cause: the 26.915.4065.0 manifest adds a packaged service that the 26.908.4834.0 manifest did not have:

<desktop6:Extension Category="windows.service"
    Executable="app/resources/codex-windows-sandbox-service.exe" …/>

Registering a packaged service requires elevation; the Store auto-update path never elevates (no UAC prompt), so registration can never succeed on this channel. The failure then leaves the package in the worst possible state: old version deregistered, new version not registered, and zero user-visible feedback.

This is the same root cause as #46370 (new packaged LocalSystem sandbox service, non-elevated registration fails with 0x80073D28), but with a materially worse outcome: in #46370 the in-app updater left the old version registered and the app remained usable; here the Store background update deregistered the old version first, leaving the machine without a working Codex and no recovery guidance. OpenAI's own enterprise deployment docs already document that 0x80073D28 requires administrator installation — but the consumer Store channel can never provide that elevation.

Fix that worked (elevated PowerShell):

Add-AppxPackage -RegisterByFamilyName -MainPackage OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0

After this, the app opens normally, the registered version is 26.915.4065.0, and CodexSandboxService is installed and running.

What steps can reproduce the bug?

1. Install Codex from the Microsoft Store on Windows 11 (version 26.908.4834.0, no packaged service in the manifest).
2. Wait for the Store background auto-update to 26.915.4065.0 (or trigger it from the Store's download queue). No UAC prompt appears.
3. The running app is closed by the update; registration of the new version fails with 0x80073D28.
4. Click the Codex entry in the Start menu. Nothing happens — no window, no process, no error.
5. Check Microsoft-Windows-AppXDeploymentServer/Operational: each click produces a RegisterByFamilyName (event 603) failing with 0x80073D28, with updateList: OpenAI.Codex_26.908.4834.0_x64__2p2nqsd0c76g0 is updating to OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0.

What is the expected behavior?

• A Store-distributed update must not ship a component that fundamentally cannot be installed through that channel (a packaged service requiring elevation, on a channel that never elevates). Either ship the service through a path that can request UAC, or defer service registration to a privileged first-launch step.
• If registration fails, the updater must fail loudly: a visible error surface (dialog / Windows notification) with the error code and recovery instructions.
• The update must never end in a state where the old version is deregistered and the new version is unregistered — that combination makes the app silently unlaunchable with no diagnostic surface for a typical user.

Additional information

• Same underlying cause as #46370, different and more severe symptom because the Store background update path deregistered the previous version. Also related: #44702, #44695.
• Verified working recovery: elevated PowerShell → Add-AppxPackage -RegisterByFamilyName -MainPackage OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0.
• Not attaching full logs since they contain machine-specific information; the sanitized event timeline above covers the failure window. Happy to provide more details on request.

No repository files or tests are named. Start by tracing the Microsoft Store update path and AppXDeploymentServer event 603 around registration of the packaged service, then compare the old and new package manifests. Done means the Store update cannot leave the app unlaunchable, and registration failures provide visible recovery guidance.