[Windows] Codex desktop updater repeatedly fails with 0x80190194
What happened?
The Windows Codex desktop app repeatedly detects an update but cannot install it. The same failure returns on each retry, and it has recurred across more than one release.
Environment
- OS: Windows 10 Enterprise 25H2, x64 (build 26200.9168)
- Package:
OpenAI.Codex(Microsoft Store/MSIX app) - Installed version:
26.803.10989.0 - Update target observed:
26.810.7004.0
Steps to reproduce
- Install the Windows desktop app from the official Microsoft Store listing.
- Launch Codex and leave it running.
- Let the app detect a newer package.
- Start the update and retry after it fails.
Expected behavior
The update should download and install successfully, or the app should fall back to a supported Microsoft Store installation/update path and present a clear recovery action.
Actual behavior
The app reports that it is unable to install the ChatGPT/Codex update. The updater log repeatedly records an HTTP/MSIX staging failure:
[windows-store-updater] ... buildVersion=26.803.10989.0 manifestBuildVersion=26.810.7004.0 packageIdentity=OpenAI.Codex
[windows-store-updater] ... hasUpdate=true ... overallState=SilentDownloadNotAllowed
[windows-updater] Failed to install prepared Windows update ... 0x80190194
The staged manifest currently contains the package URL but no length or SHA-256 metadata:
{
"buildVersion": "26.810.7004.0",
"length": null,
"packagePath": "https://persistent.oaistatic.com/codex-app-prod/releases/26.810.7004.0/ChatGPT-x64.msix",
"sha256": null
}
The same 0x80190194 failure occurred during an earlier update cycle as well.
What I checked
- Microsoft Store/AppX-related services (AppXSvc, ClipSVC, DoSvc, and InstallService) were running.
- Microsoft Store automatic-download policy was enabled (
AutoDownload=2). - The official Store product ID was recognized by
winget, but it did not offer a newer package at the time of testing. - No app data, project files, or
.codexstate was deleted.
Workaround
Using the Microsoft-signed Store Installer from the official OpenAI Windows app documentation and choosing Update successfully moved the app from an older package version to 26.803.10989.0. The next update then failed again with the same updater error.
Possible root cause
The Windows updater appears to receive a staged update manifest whose package metadata is incomplete, then fails while the MSIX staging session reads the manifest and marks the update as SilentDownloadNotAllowed even though Store auto-download is enabled. The 0x80190194 error may indicate a missing/unavailable resource in the updater/CDN or a mismatch between the app's update manifest and the Store package metadata.
Related Windows updater reports include #25770, #24010, and #35366, but I could not find an existing open issue for this exact 0x80190194 / SilentDownloadNotAllowed combination.
I can provide additional sanitized log excerpts and timestamps if maintainers need them.
1 Comment
Fresh recurrence on another Windows 10 x64 device, observed on 2026-08-21 15:04 (UTC+8).
Environment
19045.5737, x64OpenAI.Codex, package status OK26.818.2441.026.818.3698.0Reproduction
Unable to check for ChatGPT updates.Not found (404).Sanitized app log evidence:
A cache-busted live check at the timestamp above showed:
windows-store-update.json: HTTP 200, advertises26.818.3698.0https://persistent.oaistatic.com/codex-app-prod/releases/26.818.3698.0/ChatGPT-x64.msix: HTTP 404The previous target,
26.818.2441.0, showed the same CDN 404 during the prior update cycle and is now available with HTTP 200. This suggests the update manifest is advancing before the fallback MSIX is uploaded or fully propagated.The user intentionally wants the explicit Help → Check for Updates action to work without enabling global Microsoft Store automatic updates. When the Store silent-download path is unavailable, the updater should either:
The app package itself launches normally, the manifest is reachable, and the Store check reports
hasUpdate=true, so reinstalling or resetting the local package does not appear to address this failure mode.