codex - 💡(How to fix) Fix Windows desktop app silently closed/restarted after 26.506 update; no crash artifact recorded

Summary

Codex Desktop on Windows appeared to close unexpectedly and then relaunch shortly afterward. Local investigation did not find a fresh WER crash dump or Crashpad report, so this looks like a silent app/container restart rather than a normal reported crash.

Environment

• Product: Codex Desktop, Windows Store build
• Package: OpenAI.Codex_26.506.2212.0_x64__2p2nqsd0c76g0
• App release from Sentry scope: [email protected]
• Electron: 41.2.0
• Chrome runtime: 146.0.7680.179
• Node: 24.14.0
• OS: Windows 10.0.26200
• Hardware context from app scope: x64 desktop, 32 logical CPUs, roughly 33 GB RAM

Timeline, local time America/Sao_Paulo

• 2026-05-08 12:39:17: Windows AppX registered OpenAI.Codex_26.506.2212.0, replacing OpenAI.Codex_26.429.8261.0.
• 2026-05-08 13:20:24: AppModel-Runtime logged creation of Codex process 38196 for OpenAI.Codex_2p2nqsd0c76g0!App.
• 2026-05-08 13:20:34: AppModel-Runtime logged the Codex Desktop AppX container being destroyed.
• 2026-05-08 13:20:39: AppModel-Runtime logged a new Codex launch, process 16608.
• Current live process tree after relaunch had multiple Codex renderer/helper processes and app-server process codex under the new launch.

Evidence checked

• Windows Application log, AppModel-Runtime/Admin, AppHost/Admin, AppXDeploymentServer/Operational, TWinUI/Operational, and System log around the event.
• %LOCALAPPDATA%\CrashDumps: no recent Codex/OpenAI dump.
• %PROGRAMDATA%\Microsoft\Windows\WER\ReportQueue: no recent Codex AppCrash/AppHang queue item.
• %PROGRAMDATA%\Microsoft\Windows\WER\ReportArchive: only older stale Codex AppHang reports from April on older packages, not tied to this incident.
• %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\Crashpad\reports: empty for this incident.
• %USERPROFILE%\.codex\logs_2.sqlite: no fresh crash/fatal entry around the close/relaunch window. Recent errors were unrelated tool-routing errors from later investigation.

App telemetry/breadcrumb notes

The Sentry session.json for the current relaunch showed:

• status: ok
• errors: 1
• started: 2026-05-08 13:20:40 -03
• release: [email protected]

The Sentry scope breadcrumbs after relaunch contained repeated console errors around 13:20:48:

parseLineType: Invalid firstChar ...
processFile: invalid rawLine ...

The invalid line payload was related to a Moved to: ... file path emitted by a previous workflow. I am omitting the raw local path here because it contains a local username/workspace path.

Later breadcrumbs also showed repeated sampler warnings:

[electron-sampler] Failed to collect child process snapshot
Command failed: powershell.exe -NoProfile -NonInteractive -Command ... Get-CimInstance Win32_Process ...

There was a large number of live powershell.exe/pwsh.exe helper processes at the time of investigation. Most were parented by a separate desktop app (Wispr Flow), but Codex also had a few active pwsh children. This may be a confounder for the sampler warnings, but it does not explain why Codex’s AppX container was destroyed and relaunched without a crash artifact.

Expected behavior

If the Windows desktop app closes/restarts unexpectedly, it should either preserve the session without visible disruption or leave a clear crash/restart artifact that explains the reason.

Actual behavior

The user saw the Codex app close unexpectedly. Windows logs show an AppX container destroy followed by a fresh launch five seconds later. No fresh WER/Crashpad artifact was recorded, and local Codex logs did not contain a clear fatal/crash record.

Redactions

I intentionally omitted/redacted local usernames, raw %USERPROFILE% paths, thread IDs, submission IDs, session/user IDs, process UUIDs, report UUIDs, and raw prompt/response text from local SQLite/session logs.