[Windows][26.915.3509.0] In-app updater stages package but leaves old version registered after LocalSystem sandbox service was added
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.915.31029
What subscription do you have?
plus
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64 Windows 10 Pro 22H2
What issue are you seeing?
The Codex Windows desktop in-app updater detected and downloaded package 26.915.3509.0, then closed the application. However, the registered package remained on 26.911.7940.0.
Reopening Codex returned to the old version, and the update was still shown as incomplete.
The updater log reported that the update was successfully downloaded:
2026-09-18T04:09:55.987Z [windows-store-updater] Checking for update: buildVersion=26.911.7940.0 manifestBuildVersion=26.915.3509.0
2026-09-18T04:10:00.421Z [windows-store-updater] completed=true hasUpdate=true overallState=Completed
2026-09-18T04:10:00.421Z [sparkle] action=download_completed result=succeeded
AppXDeploymentServer recorded a successful SYSTEM-context staging operation for:
OpenAI.Codex_26.915.3509.0_x64__2p2nqsd0c76g0
However, the staging summary showed "Registration cost: 0 ms", and I could not find a subsequent successful registration/finalization operation from the updater.
The target package manifest introduces a packaged LocalSystem service:
- packagedServices capability
- localSystemServices capability
- Service name: CodexSandboxService.OpenAI.Codex
- Executable: app/resources/codex-windows-sandbox-service.exe
- Startup type: auto
- Account: localSystem
As a diagnostic test, a separate non-elevated registration attempt failed with:
0x80073D28: The package installation failed because administrator privileges are required.
Administrator privileges are required to install a packaged service.
Running the same package-family registration from an elevated Windows PowerShell 5.1 process succeeded.
After elevated registration:
- The registered package version became 26.915.3509.0
- Package status became Ok
- CodexSandboxService.OpenAI.Codex was installed and running
- Codex opened normally
This appears to be an updater/elevation handoff problem related to the newly added packaged LocalSystem sandbox service.
What steps can reproduce the bug?
- Start Codex on Windows 10 x64 with MSIX package version 26.911.7940.0.
- Wait for the in-app updater to offer version 26.915.3509.0.
- Click the Update button.
- The update downloads and Codex closes.
- Reopen Codex.
- Observe that the registered package is still 26.911.7940.0 and the update remains incomplete.
- Check the AppX deployment events: version 26.915.3509.0 was staged, but registration was not completed.
- As a diagnostic test, run the following from a non-elevated Windows PowerShell 5.1 process:
Add-AppxPackage -RegisterByFamilyName -MainPackage 'OpenAI.Codex_2p2nqsd0c76g0' -ForceApplicationShutdown
- The command fails with 0x80073D28 because installing the packaged service requires administrator privileges.
- Run the same command from an elevated Windows PowerShell 5.1 process.
- Registration succeeds and the new version works.
What is the expected behavior?
The in-app updater should recognize that the target package installs a packaged LocalSystem service and complete registration using the required privileged deployment path.
If elevation is required, it should request elevation through UAC.
The updater should not close Codex and silently leave the previous package version registered. If registration fails, it should show a clear error message and recovery instructions.
Additional information
Related issues with similar user-visible update failures:
- #25770
- #35366
- #38843
- #44702
This report may have a different underlying cause: the target version adds a packaged LocalSystem sandbox service, and non-elevated registration now fails with 0x80073D28.
Potentially related sandbox-service work:
- #42341
- #45542
I can provide a sanitized AppX deployment event timeline if needed. I have not attached the complete application logs because they contain local paths and other machine-specific information.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the Windows in-app updater's AppX registration path around the packaged CodexSandboxService.OpenAI.Codex service. Reproduce the failure with the supplied Add-AppxPackage command and compare non-elevated and elevated deployment events. Done means the update completes through the required privileged path, or clearly reports UAC and recovery instructions without leaving the old package registered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- desktop, operating-systems, release
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100