Codex Desktop (Windows): null-pointer crash in windows-updater.node kills the app on every launch when Microsoft Store is restricted by group policy

What version of the Codex App are you using?

26.814.5517.0 — package OpenAI.Codex_26.814.5517.0_x64__2p2nqsd0c76g0, Microsoft Store product 9PLM9XGG6VKS.

What subscription do you have?

Not applicable to this bug — the crash occurs during the startup update check, before and independent of any account/plan state.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On a managed Windows machine where the Microsoft Store is restricted by group policy, Codex Desktop crashes the main (browser) process every time it starts, roughly 2 seconds after launch. The UI loads completely and the app is briefly usable, then the whole process dies with no error dialog.

The crash is a null-pointer dereference inside the native updater addon, reached from the startup Store update check.

Crash signature (from the Crashpad minidump in …\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports\):

Exception   0xC0000005  EXCEPTION_ACCESS_VIOLATION, read at 0x0000000000000000
RIP         0x0000000000000000          <- call through a null function pointer
Return addr windows-updater.node +0x2D693   (also on stack: +0x3030E)
Process     browser (main)

Correlation with the app log — the last thing logged before the process dies, on two consecutive launches:

03:56:46.873 info [windows-store-updater] Checking Windows Store for package updates
             buildVersion=26.814.5517.0 manifestBuildVersion=26.818.2441.0 packageIdentity=OpenAI.Codex
03:56:47.508 <last log line>            <- process gone ~0.6s after the store check

03:57:35.566 info [windows-store-updater] Checking Windows Store for package updates
             buildVersion=26.814.5517.0 manifestBuildVersion=26.818.2441.0 packageIdentity=OpenAI.Codex
03:57:35.891 <last log line>            <- process gone ~0.3s after the store check

Both launches produced a Crashpad report (capture_kind: crash, ptype: browser). No errors of any kind are logged before the crash — no exception, no rejected promise, nothing TLS/network related.

Machine policy that triggers it:

HKLM\SOFTWARE\Policies\Microsoft\WindowsStore
    RemoveWindowsStore      = 1
    RequirePrivateStoreOnly = 1
    AutoDownload            = 2

Under RequirePrivateStoreOnly=1, a public-Store product such as OpenAI.Codex is not resolvable via StoreContext. windows-updater.node appears to obtain a WinRT object in this path, get null back, and dereference it without a null check — hence RIP=0.

Supporting evidence that this addon is the Store code path (strings embedded in resources\native\windows-updater.node):

• Windows.Services.Store.StoreContext, Windows.Management.Deployment.PackageManager
• exported: hasUpdate, trySilentDownloadStoreUpdates, trySilentDownloadAndInstallStoreUpdates
• PDB / source path: …\electron\native\windows-updater-addon\windows-updater.cc

What steps can reproduce the bug?

1. Use a Windows machine with the Microsoft Store restricted by policy — specifically RemoveWindowsStore=1 and RequirePrivateStoreOnly=1 under HKLM\SOFTWARE\Policies\Microsoft\WindowsStore.
2. Have Codex Desktop installed at a version older than the current buildVersion in https://persistent.oaistatic.com/codex-app-prod/windows-store-update.json (currently 26.818.2441.0).
3. Launch Codex Desktop.

The app loads its UI, logs [windows-store-updater] Checking Windows Store for package updates, and the main process dies within a second. Every launch, no exceptions.

The version condition matters: per the gating logic in app.asar, the native addon is only called when the remote manifest version is newer than the installed build —

return n && MH(t.buildVersion, e.buildVersion) <= 0 ? `up-to-date`      // early return, addon never called
     : e.isUpdateReady                              ? `update-ready`
     : r                                            ? `waiting-for-store`
     :                                                `should-check-store`; // -> calls the addon -> crash

So the app works fine right after install and starts crashing only once a newer release ships. The 30-minute detection throttle (lastStoreDetectionAttemptAtMs) is in-memory only and resets on every launch, so it never suppresses the check across restarts.

This makes the failure permanent and unrecoverable on such a machine: the crash stops only when the installed version catches up to the manifest, but installing a newer version requires the very Store that policy blocks.

What is the expected behavior?

The updater should treat "Store is unavailable / product not resolvable under policy" as a normal, handled condition rather than crashing the process.

Notably, the app already implements exactly the right fallback — the addon call is wrapped, and a thrown error routes to the MSIX fallback updater, which downloads an MSIX over HTTPS and needs no Store at all:

try { a = await this.options.nativeAddon.trySilentDownloadStoreUpdates(...) }
catch (t) {
  ...
  return { decision: { kind: `fallback`, reason: `store-operation-failed` }, outcome: null };
}

A native access violation bypasses this catch entirely and kills the process, so the intended fallback never gets a chance to run.

Suggested fix: add null checks around the WinRT objects in windows-updater.cc and surface the failure as a JavaScript error instead of dereferencing. With that single change, this environment would recover automatically through the existing MSIX fallback path — no policy change required on the user's side.

Additional information

Ruled out during diagnosis, to save triage time:

• Not an installation problem — Get-AppxPackage reports Status: Ok, package files intact.
• Not WebView2 — runtime present at 151.0.4129.93 (and the app ships its own chrome.dll anyway).
• Not TLS / certificate interception — the crash is a local WinRT call; no network error is logged, and the crash precedes any Store network activity.
• No third-party DLL injection — all 137 loaded modules are Microsoft or Codex's own; no security-software DLLs present.

This is distinct from #35603 (corrupt conversation state leaving the AppX package in NeedsRemediation); here the package stays healthy and the crash is entirely in the updater path.

Happy to provide the minidump or full startup logs if useful.

Start with electron/native/windows-updater-addon/windows-updater.cc and trace the startup Store update check through the native addon. Reproduce with the listed Windows Store policies and an older installed build, then verify that an unavailable Store produces a handled JavaScript error so the existing MSIX fallback runs instead of crashing the browser process.