Codex Desktop 26.616 crashes on startup on Windows Insider Canary Build 26200

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

• #28883
• #28239
• #28153
• #28909

Powered by Codex Action

Additional crash evidence for 26.616.6631.0

Codex Desktop frequently crashes during normal use on:

• Windows 10.0.26200
• Codex 26.616.6631.0
• Chromium / chrome.dll 149.0.7827.115

I captured three separate crashes locally. All three have the same signature:

Exception: 0xC0000005
Module: chrome.dll
Function: chrome!cppgc::internal::WriteBarrier::DijkstraMarkingBarrierSlow
Thread: child-process-snapshot

The latest crash was an invalid pointer read near address 0x342 at:

chrome!cppgc::internal::WriteBarrier::DijkstraMarkingBarrierSlow+0x9f4

Codex logs also repeatedly report:

[electron-sampler] Failed to collect child process snapshot

One occurrence reported:

MODULE_NOT_FOUND
Cannot find module:
...\app\resources\app.asar\.vite\build\child-process-snapshot-worker.js

The referenced file is present inside the installed ASAR:

\.vite\build\child-process-snapshot-worker.js

The packaged application starts this worker with the name:

child-process-snapshot

This worker name exactly matches the crashing thread in all three crashes.

Additional checks:

• The underlying WMI process queries complete normally.
• NODE_OPTIONS and ELECTRON_RUN_AS_NODE are not set.
• Disabling Codex plugins did not stop the crashes.

This appears to involve the Windows electron-sampler child-process snapshot worker, its ASAR loading/lifecycle, or a V8/CppGC interaction in Chromium 149.0.7827.115.

Please investigate the worker creation/error-handling path and whether repeated snapshot workers can outlive or race with their associated V8 context.

For privacy reasons, I cannot share the dump files. The reproducible exception signature and relevant log evidence are included above.

Temporary local workaround

I found a reproducible local workaround for 26.616.6631.0.

The workaround disables only the Windows child-process snapshot collection by making addChildProcessFields() return before it creates the child-process-snapshot worker.

It does not modify the signed Microsoft Store installation. The installed app directory is copied to a user-writable location and only that copy is patched.

Let Codex apply it

Users can give the following instruction to Codex on the affected machine:

Create a local side-by-side hotfix for my installed OpenAI.Codex Windows
Store package. Do not modify anything under Program Files\WindowsApps.

1. Detect the installed package with Get-AppxPackage -Name OpenAI.Codex.
2. Copy its complete app directory to:
   %LOCALAPPDATA%\OpenAI\CodexHotfix\<installed-version>\app
3. Back up the copied resources\app.asar as app.asar.original.
4. In the copied app.asar, perform an equal-length binary ASCII replacement:
   old: async addChildProcessFields(e){try{let r=await
   new: async addChildProcessFields(e){try{return;/**/
5. Require the old sequence to occur exactly once before patching.
6. Require the old sequence to occur zero times and the new sequence exactly
   once after patching.
7. Verify that the ASAR size is unchanged and record the original and patched
   SHA-256 hashes.
8. Create a launcher and desktop shortcut for the copied app\Codex.exe.
9. Keep the Store installation and original ASAR untouched so the workaround
   can be removed by deleting the side-by-side copy.
10. Briefly launch the patched copy with an isolated temporary user-data-dir,
    verify that it stays running, then terminate only processes whose executable
    path is inside the hotfix directory.

Use native PowerShell/.NET byte APIs for the replacement. Do not use a text
editor, do not unpack and rebuild the ASAR, and do not change the byte length.

Codex should inspect the target and confirm all preconditions instead of blindly applying the replacement to another application version.

Exact patch

The target is:

<hotfix copy>\app\resources\app.asar

Replace this ASCII byte sequence:

async addChildProcessFields(e){try{let r=await

with:

async addChildProcessFields(e){try{return;/**/

The actual changed portion is:

let r=await

to:

return;/**/

Both portions are 11 ASCII bytes. This keeps the ASAR file size and every following data offset unchanged. Rebuilding or repacking the ASAR is unnecessary.

The surrounding context is important because let r=await may occur elsewhere. The full old context must occur exactly once.

Manual reproduction

1. Detect the package and paths:

``powershell
$pkg = Get-AppxPackage -Name OpenAI.Codex
$version = $pkg.Version.ToString()
$source = Join-Path $pkg.InstallLocation "app"
$target = Join-Path $env:LOCALAPPDATA "OpenAI\CodexHotfix\$version\app"
``

1. Copy the complete application without following directory junctions:

``powershell
robocopy $source $target /E /COPY:DAT /DCOPY:DAT /XJ /R:2 /W:1
``

1. Back up the copied ASAR:

``powershell
$asar = Join-Path $target "resources\app.asar"
Copy-Item $asar "$asar.original" -Force
``

1. Read the copied ASAR as bytes. Find the complete old ASCII context and confirm that it occurs exactly once.
2. Replace only its let r=await bytes with return;/**/.
3. Write to a temporary file first, then replace the copied ASAR.
4. Verify:

``text
old context count = 0
patched context count = 1
original size = patched size
original SHA-256 != patched SHA-256
``

1. Close the normal Codex Desktop instance and launch:

``powershell
Start-Process (Join-Path $target "Codex.exe")
``

Starting Codex from the Start menu still launches the unmodified Store version. The copied executable or its dedicated shortcut must be used.

Result

• The patched application passes Electron/ASAR startup validation.
• It remains running and starts its normal Codex child processes.
• The child-process-snapshot worker is no longer created.
• Normal conversations and tool execution continue to work.
• Since applying this workaround, I have not observed any new Codex Desktop crashes during normal use.

The expected side effect is that child-process CPU and memory snapshot telemetry is no longer collected. Renderer and main-process telemetry are not changed.

To roll back, close the patched instance and delete %LOCALAPPDATA%\OpenAI\CodexHotfix. The Microsoft Store installation remains unchanged.

This appears to have resolved the frequent crashes on my machine so far. It is still an unsupported temporary workaround rather than a confirmed permanent fix, but the result strongly suggests that bypassing electron-sampler.addChildProcessFields() avoids the crash and further narrows the issue to the Windows child-process snapshot worker or its V8 lifecycle.