Windows Codex app exits silently after Microsoft Store update scan fails

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #31989

Powered by Codex Action

I reviewed #31989. It appears related, especially its Store update lifecycle failure mode, but my captured exit differs:

• codex.exe exited with code 0x00000000, not 0xc0000409.
• Windows logged StoreAgentScanForUpdatesFailure0 with 80072efd immediately before the exit.
• The installed version was already 26.707.3748.0.
• The app can run for minutes or hours before exiting.

I am keeping this issue open for now because the exact failure signature is different, but maintainers may merge or close it as a duplicate if they confirm the same root cause.

I found two newer related issues:

• #33320
• #33321

They appear to be related to Windows background Microsoft Store update behavior causing the app to exit.

My case has some additional evidence:

• codex.exe exits with code 0x00000000 (captured with ProcDump)
• Windows Event Viewer logs StoreAgentScanForUpdatesFailure0 with error 80072efd immediately before the exit
• The app can run normally for minutes or hours before exiting

This may be another manifestation of the same Store updater lifecycle issue.

ARM64 variant — root cause identified: serialport native module delay-load crash

Windows 11 build 26200 (ARM64), Codex app 26.707.9981.0 arm64 (MSIX). Symptoms match this thread: the app window silently disappears seconds after launch whenever it has network connectivity, with nothing in the app logs (they just cut off mid-stream) and no Windows crash dialog. The backend codex.exe survives as an orphaned process each time. The app is fully stable offline — the crash only fires once it connects (e.g. right after launch when online, or when reconnecting Wi-Fi and switching threads).

Parsed the Crashpad minidump the app writes to %LOCALAPPDATA%\Packages\OpenAI.Codex_...\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports:

• Exception 0xc06d007f (VcppException / delay-load: entry point not found), raised in KERNELBASE.dll, identical address across multiple dumps — 100% reproducible.
• The crashing thread's stack is inside app.asar.unpacked\node_modules\@worklouder\device-kit-oai\node_modules\@worklouder\wl-device-kit\node_modules\serialport\node_modules\@serialport\bindings-cpp\prebuilds\win32-arm64\node.napi.node.
• The dump also contains codex-micro-hid-event / codex-micro-joystick-event / codex-micro-device-state-changed strings, so this looks like the device-kit/HID integration.

So the win32-arm64 serialport prebuild delay-loads a Windows API that's missing on this OS build, and the failed delay-load takes down the entire Electron main process.

The offline/online behavior suggests the device-kit path is feature-flag gated (the crash consistently follows the "Features enabled" flag fetch after connect), which might allow a server-side mitigation while a fixed build ships. Users can't remove the module locally since it's inside the protected WindowsApps MSIX.

Also observed on the same machine (possibly secondary): after reconnecting, the backend app-server occasionally exits with code=1 during plugin manifest reconciliation, and the desktop app surfaces the last harmless stderr WARN ("ignoring interface.defaultPrompt[0]...") as if it were the fatal error, which makes that error screen misleading.

Happy to share the full minidump privately if useful.

I noticed a related investigation in #33374 identifying a possible device-kit / native module crash path on Windows ARM64.

My machine is x64, but the symptoms are similar:

• silent exit
• no Application Error
• CLI continues working
• process exits without a visible crash dialog

I captured a ProcDump dump where codex.exe exits with code 0x00000000.
If there is a shared Electron/native module lifecycle issue across architectures, I can provide the dump privately.

I can reproduce a closely related Windows desktop failure with more specific AppX package-registration evidence.

Environment

• Codex Windows app: 26.721.4979.0
• Windows 25H2, build 26200.8655, 64-bit
• Microsoft Store installation

Observed behavior

After an in-app browser navigation hung, the Codex app disappeared/closed. Microsoft Store then displayed a Restore option for Codex. Reopening/restoring temporarily recovered the app, but the behavior repeated.

The Store package had updated from 26.721.3996.0 to 26.721.4979.0 before the first reproduction.

Windows event evidence

Microsoft-Windows-AppXDeploymentServer/Operational recorded repeated events at the same times as the app disappearance/restart:

• Event 603: RepairAppRegistrationOption with ForceTargetApplicationShutdownOption
• The recorded calling process was explorer.exe
• Event 649 repeatedly reported repairing ACLs for the installed Codex WindowsApps package
• Multiple repair-registration attempts occurred within minutes, followed by the Codex app restarting
• Get-AppxPackage OpenAI.Codex subsequently reported package status Ok

There was no Codex shell command that uninstalled the app or deleted its files, and no normal application-crash event was recorded.

This looks like a Store update/package registration or ACL repair loop that force-terminates the active Codex process, rather than a normal app crash. The in-app browser navigation may only be exposing the already-broken registration state.

Expected behavior

A Store update or registration check should not force-close an active Codex session, make the app appear uninstalled, or require restoration through Microsoft Store.

I also submitted the reproduction through Codex in-app feedback and shared the diagnostic session. I am intentionally not posting the session ID, local paths, account details, or full logs publicly; those can be provided through a private channel if maintainers need them.

Follow-up after a full Windows restart: the issue persists, so rebooting does not clear the broken registration state.

Post-reboot timeline:

• System booted at 17:09:44 local time.
• At 17:11:29, AppXDeploymentServer Event 603 again started RegisterByPackageFullName for Codex with RepairAppRegistrationOption and ForceTargetApplicationShutdownOption; caller: explorer.exe.
• Event 649 immediately reported ACL repair for the Codex WindowsApps package, followed by "ACLs repaired successfully. Register next time should succeed."
• At 17:12:13, Windows Update (svchost.exe,wuauserv) staged and registered the same package again with ForceTargetApplicationShutdownOption and RegisterHighestVersion.
• At 17:13:48, the explorer.exe repair-registration and Event 649 ACL-repair sequence repeated.
• At 17:14:26, Windows Update again staged and registered the same package.

The user-facing result remained the same: Microsoft Store showed Restore, and attempting to open a previous Codex conversation caused the app to disappear/require restoration again.

Additional data-integrity checks:

• The affected conversation JSONL files still exist.
• The conversation remains present in Codex's session index.
• Read-only SQLite PRAGMA quick_check returned ok for both the Codex state and log databases.

This suggests the conversations are not actually deleted; the app/package is being force-terminated or losing registration while the UI is opening/restoring a previous conversation. The registration/ACL loop survives a reboot.

I found a related investigation in #33374.

The reported behavior suggests a possible Windows AppX / Store package registration issue:

• AppXDeploymentServer events 603 and 649
• ForceTargetApplicationShutdownOption
• ACL repair / package re-registration loop

My case may be related:

• codex.exe exits with code 0x00000000 (ProcDump)
• StoreAgentScanForUpdatesFailure0 with error 80072efd occurs immediately before exit
• No normal APPCRASH event is generated

I will check AppXDeploymentServer/Operational logs if the issue reproduces again.

I captured another reproduction on July 28, 2026, and the timing again closely correlates the Codex exit with a Microsoft Store update scan failure.

Timeline:

• 11:07:37 — AppModel-Runtime Event 210: the OpenAI.Codex desktop AppX container was created.
• 11:07:37 — Events 211 and 201: codex.exe process 3256 was added to the container and launched.
• 11:09:43 — AppModel-Runtime Event 217: the OpenAI.Codex desktop AppX container was destroyed.
• 11:09:43 — Windows Error Reporting logged StoreAgentScanForUpdatesFailure0 with error 80072efd.
• 11:09:44 — the same StoreAgent failure report was archived.

I did not manually close Codex. The app ran for approximately 2 minutes and 6 seconds before silently exiting.

There were no matching OpenAI.Codex deployment, repair, registration, ForceTargetApplicationShutdownOption, or TerminateApplications events in AppXDeploymentServer/Operational around the exit time.

This is now the second captured reproduction where StoreAgentScanForUpdatesFailure0 occurs at almost exactly the same time that Codex silently exits. Together with the previous ProcDump result showing exit code 0x00000000, this suggests the Codex updater or lifecycle logic may be exiting the app after a failed Store update scan, without successfully relaunching it.

This issue is still reproducible on my Windows PC and is now preventing me from reliably using the Codex desktop app for development.

I captured another clean reproduction:

• 11:07:37 — OpenAI.Codex AppX container created and codex.exe launched
• 11:09:43 — OpenAI.Codex AppX container destroyed
• 11:09:43 — Windows Error Reporting logged StoreAgentScanForUpdatesFailure0
• Error code: 80072efd
• I did not manually close Codex

This is the second captured reproduction where the Codex exit occurs at essentially the same time as a Microsoft Store update scan failure.

A previous ProcDump capture also showed codex.exe exiting with code 0x00000000, with no standard APPCRASH event.

The issue has remained unresolved for more than a month and currently makes the Windows desktop app unreliable for normal development work.

Could a maintainer please confirm whether this is being tracked internally, or whether additional logs / a dump would help?