Windows ARM64 app crash-loops on launch — ChatGPT.exe exports no napi_* symbols, serialport addon dies with delay-load 0xC06D007F

Summary

The Codex desktop app on Windows ARM64 crash-loops: the window appears, runs for ~10–15 seconds, then the whole app exits. No error dialog, no Windows Application Error event — but Crashpad writes a minidump on every launch. Reinstalling (including wiping all LocalCache app data) does not help; a fresh install crashes on first launch.

Symptoms match #27574, but I was able to root-cause it from the minidump on my machine.

Environment

Device: Surface, Windows 11 on ARM64 (Snapdragon / Qualcomm Adreno GPU), OS build 10.0.26200
App: OpenAI.Codex MSIX from Microsoft Store, version 26.707.9981.0, arm64 (OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0)
Crashing process: Electron main process (ptype=browser in the Crashpad annotations)

Root cause (from minidump analysis)

Exception code is 0xC06D007F — the VC++ delay-load helper's "procedure not found" exception, raised from KERNELBASE!RaiseException.

Parsing the DelayLoadInfo structure pointed to by the exception parameter:

Failing (importing) module: app\resources\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
Delay-loaded DLL name: node.exe
Missing procedure: napi_create_function
hmodCur (module the delay-load resolved to): ChatGPT.exe — i.e. the node-gyp delay-load hook correctly redirected node.exe to the host executable.

So the redirect works, but the host exe doesn't have the symbol. Reading the PE export table of the ARM64 ChatGPT.exe confirms it: the export directory contains only 2 named exports, and zero napi_* / node_api_* symbols. A healthy Electron executable exports the full Node-API surface. The ARM64 build appears to have been linked without the Node export list.

Any NAPI prebuilt that loads in the main process will therefore kill the app; on my machine the trigger is the serialport addon loaded by @worklouder/device-kit-oai roughly 10–15 seconds after startup.

Why it looks like a sudden regression

The app ran fine for ~9 hours overnight (July 14→15), then began crash-looping on every launch the morning of July 15 with no local changes, no app update (same version before/after), and it still crashes after a complete uninstall + data wipe + fresh Store install. That strongly suggests the device-kit/serialport load is gated by a server-side (Statsig) feature flag that was recently enabled — which would mean every Windows ARM64 user is affected as of that flag flip.

If that's right, there are two fixes:

Short term: turn the flag off for win32/arm64 (or skip loading @worklouder/device-kit-oai when the host exe lacks NAPI exports).
Proper fix: link the ARM64 ChatGPT.exe with the Node-API export list like the x64 build.

Repro

Windows 11 ARM64 machine.
Install Codex app from the Microsoft Store (26.707.9981.0).
Launch. Window appears, app exits ~10–15 s later.
A new .dmp appears in %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports\ with exception 0xC06D007F.

Happy to share a minidump privately if useful.

Possibly related

**Codex Windows App crashes after launch** #27574 (same disappear-after-launch symptom on x64 — may or may not be the same cause)
Unrelated but observed in logs: the updater polls a "primary runtime manifest" that 404s every 30 s for this build (primary_runtime_update_poll_failed ... 404 Not Found).

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

Windows desktop app crashes after update to 26.707.9981.0 due to serialport.node / napi_module_register #33380
[Windows ARM64 Desktop] App closes cleanly 10-35 seconds after launch on 26.707.9981.0 #33376
[Windows App] Repeated serialport.node delay-load failures cause severe UI lag #33375

Powered by Codex Action

Independent confirmation from another Windows 11 ARM64 system (Surface Laptop 7) running Codex Desktop 26.707.9981.0 arm64.

I parsed a Crashpad minidump and got the same delay-load failure:

exception: 0xC06D007F
delay-loaded DLL: node.exe
missing procedure: napi_create_function
failing addon: @serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node
load path: @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport

I also traced the packaged renderer/main-process code. The Codex Micro bridge is gated by the numeric Statsig gate 3207467860. When enabled, the bridge calls codexMicro.getState() on mount; the main-process service then lazily requires @worklouder/device-kit-oai, which loads the failing native addon. No Codex Micro / Work Louder device was connected or explicitly enabled.

Timeline from the app logs:

the same app version ran normally for several hours;
the last healthy session completed a successful Statsig value refresh;
the next launch entered the crash loop;
every subsequent launch exited within roughly 6–11 seconds.

Additional isolation:

Windows app Repair completed successfully but did not change the behavior;
launching with a fresh temporary Chromium user-data directory reproduced the same crash;
Microsoft Defender recorded no detection/block event and Code Integrity recorded no relevant block;
two reproductions occurred while Defender real-time protection was temporarily disabled during a Defender servicing window.

This makes the server-side gate explanation substantially stronger and rules out local profile corruption or Defender interference on this machine.

Suggested immediate mitigation: disable gate 3207467860 for win32/arm64, or avoid initializing Codex Micro unless the integration is explicitly enabled and the native addon can load safely. I can provide the minidump privately if needed.

Independent confirmation from a third Windows 11 ARM64 machine (Snapdragon, 12 cores, OS build 10.0.26200) — Codex Desktop 26.707.9981.0 arm64 from the Microsoft Store, same crash loop starting the morning of July 15.

Minidump analysis matches the OP exactly:

exception 0xC06D007F raised from KERNELBASE.dll (delay-load helper)
DelayLoadInfo: szDll = node.exe, szProcName = napi_create_function, dwLastError = 127 (ERROR_PROC_NOT_FOUND)
hmodCur = base of ChatGPT.exe (so the node.exe→host-exe redirect worked; the export is simply missing)
failing module: app.asar.unpacked\node_modules\@worklouder\device-kit-oai\...\@serialport\bindings-cpp\prebuilds\win32-arm64\node.napi.node
crashing thread stack: ntdll loader frames + KERNELBASE + node.napi.node, i.e. death during N-API module registration

Additional data points:

Two launches this morning, both identical: window appears (rendererWindowVisible=true in the main-process log), then the log stops cold ~9–17 s after process start and the Crashpad dump is written <1 s later. No graceful-shutdown lines.
This machine does have real USB serial devices attached (embedded dev boards), and the crash presents identically to the reports from machines with none — consistent with the server-side gate theory rather than device enumeration being the trigger.
Same unrelated primary_runtime_update_poll_failed ... 404 Not Found noise in the logs as the OP.

Happy to provide the 44 MB minidump privately if useful.

Independent confirmation on another Windows 11 ARM64 machine.

Environment:

Windows build: 10.0.26200, ARM64, 12 logical processors
Store package: OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0
Desktop release in logs: 26.707.72221
Bundled app-server: 0.144.2

Reproduction:

Launch creates 6 processes initially, then 8 processes by ~3.5 seconds.
The complete ChatGPT.exe process tree disappears at ~7 seconds.
A fresh Crashpad dump is written (44,594,842 bytes).
Reinstalling the same Store package did not help.

I independently decoded the minidump's exception stream and DelayLoadInfo and got the same result:

Exception: 0xC06D007F
Exception address: KERNELBASE.dll+0x1233c4
Importing module: @serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node
Dependency chain: @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport
Delay-loaded DLL: node.exe
Missing procedure: napi_create_function
dwLastError: 127
hmodCur: base address of packaged ChatGPT.exe

The desktop log reaches a rendered/ready main window and initializes the in-app browser backend, then ends abruptly. Recoverable WSL-not-installed and SSH-authentication warnings are present but do not own the native exception.

The dump is available privately if an OpenAI maintainer provides a safe upload route; I am not attaching it publicly because it may contain process memory. This corroborates that the issue is deterministic in the shipped ARM64 package / enabled Codex Micro path, rather than corrupted user state.

I can reproduce this issue on a Snapdragon X Elite Windows ARM64 machine.

Environment:

Codex Desktop: 26.707.9981.0
Package: OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0
Windows 11 ARM64 build 26200/26220
CPU: Qualcomm Snapdragon X Elite X1E78100
Bundled app-server: 0.144.2
Separately installed Codex CLI: 0.144.4 aarch64-pc-windows-msvc

Observed behavior:

The desktop window opens normally.
The app-server initialization handshake succeeds.
The bundled Codex CLI initializes successfully.
The window reaches ready-to-show.
Approximately 7–12 seconds later, the entire desktop process exits.
No Application Error event or standard crash dump is created.
The standalone terminal CLI continues to work normally.

I also see the primary-runtime manifest 404 and the absence of a windows-aarch64 entry in the primary-runtime configuration, but these may only be correlated symptoms rather than the direct cause.

Reinstalling, repairing, resetting, disabling WSL execution, switching sandbox modes, and clearing Codex state did not resolve the issue.

Second on this, just started having this happen this morning. I thought it was related to Windows 11 updates or my Parallels VM so I started digging. Ironically enough, I use this VM for reverse engineering and dump analysis... how fitting.

ChatGPT Windows ARM64 startup crash
Package: OpenAI.Codex 26.707.9981.0 arm64
Internal release: 26.707.72221
Environment: Windows 11 ARM64 build 26200, Parallels ARM VM
Exception: 0xc06d007f / ERROR_PROC_NOT_FOUND
Process: ChatGPT.exe
Faulting module: node.napi.node
Failure bucket:
APPLICATION_FAULT_c06d007f_node.napi.node!Unknown
Failure hash:
{452a3e12-0781-9875-9e9b-b5a1825deba5}
Native module:
@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node

I tried reset/re-install, GPU-cache removal, and disabling GPU acceleration. None of that resolved it. After finding the crash dumps I put them through WinDbg and traced it to this serial port plugin that seems to have a missing binding (ERROR_PROC_NOT_FOUND).

Setting computer_use = false and apps = false in config.toml does not fix it either.

The real fix is to update the arm64 package for the serialport, or allowing it to be gracefully disabled instead of this hard crash.

Independent confirmation from a Surface Laptop 7 (Windows 11 Enterprise ARM64 build 26200) using Store package OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0.

The app had remained healthy in one long session from July 14 until a restart on July 15. Every launch after the restart exited within roughly 6-8 seconds. A Crashpad dump decodes to the same failure reported here:

exception 0xC06D007F
delay-loaded DLL node.exe
missing procedure napi_create_function
last error 127
importing module @serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node
dependency path @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport

The restart happened immediately after adding an Azure DevOps MCP server, which initially made MCP look suspicious. I verified the MCP configuration separately with Codex CLI (codex mcp list and codex mcp get azure-devops --json), confirmed that the server transport/config parses and launches, and observed that the desktop app-server completes its handshake before the native browser-process crash. This is useful isolation: MCP was only the reason for restarting the desktop app, not the failing subsystem.

I also ran the current Microsoft-signed installer from OpenAI's official download link. It retained the same Store package version and reproduced the crash with a new 44 MB dump at 18:15:21 local time. I have not attached the dump publicly because it may contain process memory and local identifiers.

This independently confirms that repair/reinstall and MCP removal are not viable mitigations; disabling the Codex Micro gate for win32/arm64 remains the safest immediate rollback.

▎ Corroborating the Statsig theory with hard timeline evidence from my machine (Surface, Snapdragon X Plus, 26.707.9981.0): the app ran fine on this exact version for ~24h (installed Jul 14 15:38 UTC), including an 11-hour session on Jul 15. That session died mid-use at Jul 15 15:51:13 UTC — the same second a [statsig-refresh-diagnostics] interval refresh completed successfully (refresh started trigger=interval → values updated hasValues=true → refresh finished success=true at 15:51:12.645–15:51:13.039, then the log ends abruptly). Every launch since crashes seconds after ready provider mounted reads the cached values; survives OS reboot.

▎ Decoded the Crashpad DelayLoadInfo from my dump: szDll=node.exe, proc=napi_create_function, dwLastError=127, hmodCur = ChatGPT.exe base — whose export table contains only GetHandleVerifier and IsSandboxedProcess (zero napi_*). Faulting addon: ...@worklouder\device-kit-oai...@serialport\bindings-cpp\prebuilds\win32-arm64\node.napi.node, ptype=browser.

▎ This looks revertible server-side without shipping a new build — please consider rolling back the flag for win32-arm64 desktop clients.

Independent confirmation from another Windows 11 ARM64 system.

Environment

Windows build: 10.0.26200, ARM64
CPU: Qualcomm Snapdragon X Elite X1E80100 (12 cores)
GPU: Qualcomm Adreno X1-85, driver 31.0.133.1
Microsoft Store package: OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0
Desktop release in logs: 26.707.72221
Electron/Chrome runtime: 150.0.7871.115
Bundled app-server: 0.144.2

Reproduction and dump evidence

The main window reaches ready-to-show, the renderer mounts, and the app-server initialization handshake succeeds.
The entire desktop process exits roughly 7 seconds after launch.
Every launch creates a new Crashpad dump; the inspected dump was 44,427,264 bytes.
Decoding the exception stream and DelayLoadInfo produced:
- exception: 0xC06D007F
- delay-loaded DLL: node.exe
- missing procedure: napi_create_function
- dwLastError: 127 (ERROR_PROC_NOT_FOUND)
- hmodCur: base address of the packaged ChatGPT.exe
- importing module: @serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node
- dependency path: @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport
Repairing, uninstalling, and reinstalling the same Store build did not help; the fresh package reproduced immediately.
The bundled app-server and account/API requests initialize successfully before the native browser-process crash. The logged WSL-not-installed message is recoverable and does not own the exception.

This independently matches the OP's native ARM64/N-API failure. I can provide the Crashpad dump privately if an OpenAI maintainer supplies an appropriate upload channel; I am not attaching it publicly because it may contain process memory.

Independent reproduction with the same root cause.

Environment

ASUS Zenbook A14 UX3407QA
Windows 11 Home ARM64, build 10.0.26200
Microsoft Store package: OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0
ChatGPT.exe product/file version: 150.0.7871.115
Codex CLI 0.144.4 works normally on the same machine

Timeline

Windows AppX deployment history shows the previous Codex build 26.707.9564.0 was working earlier, then build 26.707.9981.0 was registered for this user at 2026-07-15 14:32:53 local time. The first new-build launch log began at 14:32:55 and ended at 14:32:59. Subsequent launches terminated the same way after roughly 4–7 seconds.

This provides an update-correlated reproduction rather than a settings, account, or hardware change.

Minidump confirmation

A 44,351,488-byte Crashpad minidump was produced. Parsing its exception stream and DelayLoadInfo confirms:

exception: 0xC06D007F
delay-loaded DLL: node.exe
missing procedure: napi_create_function
resolved module handle: ChatGPT.exe
importing native addon loaded from the bundled ARM64 @serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node under @worklouder/device-kit-oai

The desktop log ends abruptly immediately after normal initialization; unrelated WSL-not-installed and stale remote-connection warnings occur earlier but do not explain the native exception.

Controls

Microsoft Store reports no newer build.
The separately installed native ARM64 ChatGPT Classic app remains stable for more than two minutes with zero crash dumps/events.
Codex CLI remains functional.
Resetting Windows, GPU changes, or installing WSL should not be necessary for this failure class.

I have retained the minidump but am not attaching it publicly because it may contain process memory. It can be provided through a private OpenAI upload channel if needed.

Independent confirmation — and one data point the thread doesn't have yet: full local-state bisection proving the trigger is server-side.

Environment: Windows 11 Pro ARM64 build 26100, Parallels VM on Apple Silicon, Store package OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0 (installed Jul 14), desktop release 26.707.72221. Codex CLI 0.144.2 works fine on the same machine.

Same minidump signature as OP: 0xC06D007F from the delay-load helper, missing procedure napi_create_function, crashing stack walks through @serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node (via @worklouder/device-kit-oai). App boots the full UI, dies ~11–15 s after launch, every launch.

Bisection — crash persists through ALL of these (each verified individually):

Reset-AppxPackage (AppContainer verifiably deleted + recreated — AppModel events 41/39)
pristine %USERPROFILE%\.codex (renamed away entirely; not even logged in)
Chromium GPU/shader caches cleared, plugin marketplace cache/staging cleared
no Windows updates that day, no changed system DLLs, no Defender detection, no COM ports present, Node on PATH unchanged

Since a completely fresh container + fresh user profile still crash on unchanged signed binaries, the trigger cannot be local state — consistent with the Statsig rollout theory. Our onset: app ran ~18 h on this version, first crash Jul 15 16:20:21Z (leftover atomic-write temp file pins the second), matching the timeline in the comment above.

Happy to share minidumps privately.

After restarting my pc, the app is working again.

Confirming this issue with a completed structural minidump analysis from an affected machine (Windows 11 Home 25H2 build 26200.8875, app 26.707.12708.0 — also reproduced on 26.707.9981.0). Root cause fully measured; posting in case it saves the team triage time.

DelayLoadInfo extracted from two independent WER minidumps (custom parser, exception stream → ExceptionInformation[0]):

Field	Value
Exception	`0xc06d007f` at `KernelBase.dll+0xc1ada` (RaiseException)
`szDll`	`node.exe`
`szProcName`	`napi_module_register`
`hmodCur`	ChatGPT.exe image base (delay-load hook remapped `node.exe` → `GetModuleHandle(NULL)`)
`dwLastError`	127 (ERROR_PROC_NOT_FOUND)

Faulting module: app.asar.unpacked\node_modules\@worklouder\device-kit-oai\...\@serialport\bindings-cpp\build\Release\serialport.node (229,376 bytes). Its delay-import descriptor (RVA 0x346c4, read from the pristine on-disk PE) imports 57 symbols (56 napi_* + 4 uv_*) from node.exe.

Export-table diff on disk: ChatGPT.exe exports 2 symbols total — 0 of the 57 required. chrome.dll in the same app directory exports 3,174 names including all 57. So the Node-API surface ships in the app but lives in the wrong module for node-gyp's win_delay_load_hook.

Crash-thread stack: KernelBase!RaiseException ← serialport.node delay-load thunk ← setupapi.dll ← ntdll!LdrpCallInitRoutine ← chrome.dll — i.e., during serialport.node DllMain inside LoadLibrary, triggered when the [desktop-notifications] service loads the Work Louder device kit ([desktop-notifications][unhandled-rejection] Error: A dynamic link library (DLL) initialization routine failed. logged at dump time, to the second).

Notes that may help:

The exception is contained (loader converts to STATUS_DLL_INIT_FAILED; the main process survives and keeps logging 2s later) — the user-visible damage is one WER report + 10–24 MB minidump per occurrence: 537 events / peak 136 per hour on this machine on 2026-07-16, with onset at 12:35:12 KST (03:35 UTC) with zero local changes — consistent with the server-side flag trigger mentioned above. The storm stopped by itself at 19:57:59 KST the same day.
The load-failure lines exist in earlier sessions the same day on 26.707.9981 too — the ABI mismatch is version-independent; the flag only changes trigger frequency.
Both dumps are byte-identical in signature (same RVAs 0x28430/0x34b34/0x346c4) — one deterministic failure.

Possible fixes from the data: export napi forwarders from ChatGPT.exe; resolve the delay-load against chrome.dll for bundled native modules; guard the device-kit init on win32; or run device detection in the bundled real node.exe (runtimes\cua_node\...\bin\node.exe, v24.14.0, which exports napi).

Happy to share the two minidumps + full crash-timeline CSV (WER Report Id 2c083f55-34e9-4256-aabd-261892c1dd54).

I've just launched the ChatGPT/Codex desktop app normally. The currently installed version is OpenAI.Codex 26.707.12708.0 ARM64 (OpenAI.Codex_26.707.12708.0_arm64__2p2nqsd0c76g0). It has remained running and responsive for at least five minutes without crashing, with no NODE_OPTIONS workaround applied. The crash was previously consistently reproducible on 26.707.9981.0 ARM64.

It looks like the issue has been resolved, although I cannot confirm whether this was due to the app update or a server-side change.
Can anyone else confirm?

Confirming on x64 (26.707.12708.0, Windows 11 build 26200.8875) — and I can help disambiguate app-update vs server-side:

The crashes continued after updating to 26.707.12708.0 (WER events at 10:46:58Z, 10:52:58–53:11Z, 10:57:56–59Z, all on the new build, same 0xc06d007f signature).
They then stopped abruptly at 10:57:59Z with zero local changes on this machine. Zero WER events since (2.5+ hours).

So on x64 this looks server-side (flag change), not the app update. Which would mean the underlying packaging issue (host exe exporting 0/57 required napi symbols — details in my comment above) is likely still present and could re-trigger if the flag flips back.

Confirming the same failure on another Windows 11 ARM64 machine:

Device: Microsoft Surface Laptop 7, Snapdragon X Elite (X1E80100), 12 cores
OS: Windows 11 Home 25H2, build 10.0.26200
Store package: OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0
Desktop release in logs: 26.707.72221
Reproduction: window renders, then the full process exits after roughly 5 seconds on every launch
Crashpad dump: 44,565,376 bytes; SHA-256 c4fb2aba2d54e3428156b9a041794ef5ce25c2850c70cb575b40754ada062116

The minidump has the same decoded signature:

exception 0xC06D007F / ERROR_PROC_NOT_FOUND
delay-loaded target node.exe
missing procedure napi_create_function
@worklouder, @serialport, and node.napi.node are present in the dump

The desktop log reaches a visible renderer and browser_use_iab_backend_startup_ready, then stops abruptly. Uninstall/reinstall, app-state reset, deleting and cleanly re-provisioning the cua_node runtime, and restoring a clean Codex config did not change the crash.

I am not attaching the minidump publicly because it may contain process memory, but can provide it privately if a maintainer supplies a safe upload route.

Confirming this still reproduces on the latest build 26.707.12708.0 (ARM64) — updating from 9981 did not fix it, and an app Reset doesn't help either (the fault is in the signed program binaries, not user cache).

Decoded from my Crashpad minidump (Windows 11 ARM64, build 26200):

Exception 0xC06D007F (VC++ delay-load), dwLastError = 127 ERROR_PROC_NOT_FOUND
Failing import: napi_create_function delay-loaded from node.exe
The loader resolves node.exe → ChatGPT.exe (module base matches hmodCur in the DelayLoadInfo), whose export table contains only 2 exports and no N-API symbols
App fully initializes (account/model/thread lists succeed in the child node.exe process) then the main process dies ~5s in

So the regression is still shipping in 12708. 👍

Follow-up from the same Windows x64 machine: the fault storm now appears to have stopped

This is a follow-up to my earlier x64 dump report in this issue. The machine remained on the same stable package; no Beta package was installed, no reinstall was performed, and no local configuration or workaround was applied.

Additional local evidence

Total Windows Application Error Event ID 1000 records for ChatGPT.exe / 0xC06D007F reached 368.
138 new events occurred after my 14:02 local-time comment.
Two additional main-process sessions appeared at approximately 15:57 and 18:21, matching further user-visible interruptions.
The last matching event was recorded at 18:48:30 local time.
The installed executable is still from OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0 (file version 150.0.7871.115). OpenAI.CodexBeta is not installed.

Current state

The stable app was launched again at approximately 21:55. A fresh live sample from 22:04:44 to 22:05:44 showed:

Event count: 368 -> 368
Latest event: 18:48:30 -> 18:48:30
ChatGPT process set: unchanged

This aligns closely with the separate x64 report above where faults stopped abruptly at 10:57:59Z (18:57:59 local) without a local change. The roughly nine-minute difference is consistent with a gradual server-side feature-gate rollout/rollback.

Inference: the immediate crash storm appears mitigated by a server-side change, but the packaged native-addon incompatibility remains present in 26.707.9981.0 x64 and could recur if the Codex Micro gate is re-enabled. Please keep the affected gate disabled for Windows x64/ARM64 and ship a package-level fix or graceful optional-import failure handling.

No dumps or full logs are attached publicly. The two retained dumps remain available through an OpenAI-approved private channel.

Disclosure: this follow-up was prepared and posted through Codex at my explicit request.

I can confirm that it works now on an ARM64 machine too.

Can confirm that without doing anything, the app launched normally this morning (Version 26.707.72221).
Immediately had an internal "update" button, which updated it to vesion Version 26.707.91948 and remains working.

Follow-up to my earlier HP OmniBook 3 / Snapdragon X Elite ARM64 reproduction:

As of July 16, 2026, the app is working again on this same machine. It now launches normally and remains open instead of exiting within approximately two seconds. I did not need to apply the proposed preload workaround.

I have not independently confirmed a package-level fix or rechecked the installed package version, so this observation is consistent with the server-side mitigation / feature-gate rollback others are reporting rather than proof that the shipped ARM64 binary has been corrected.

Additional confirmation from Surface Pro 11 (Snapdragon X Elite, Windows 11 ARM64): the issue is still reproducible with Microsoft Store build 26.707.9981.0.

Current behavior:

Login/onboarding completes successfully.
The initial prompt can be submitted.
When the main chats window/list appears, the entire app exits.
Main ChatGPT.exe process exits with 0xC06D007F.
Renderer, GPU, utility, and crashpad child processes then exit with 0x00000000.

Current status on this machine:

App reset and reinstall did not help.
%USERPROFILE%\.codex was

Update:

My Surface Pro (Windows 11 ARM64) is now working again.

Current version:
OpenAI.Codex 26.707.12708.0 ARM64

I did not apply the preload workaround.
The app now launches normally and has remained stable during testing.

It is unclear whether this was resolved by the app update, a server-side change, or a combination of both.

The same problem has reappeared in the newly updated version 26.715.2305.0. The environment is Windows 11 x64.
在刚刚更新的版本26.715.2305.0中又出现了相同的问题，环境Windows11 x64

Really appreciate all the feedback. #33375 (comment) we have addressed the issue.

Navigation Menu

Repository navigation

Windows ARM64 app crash-loops on launch — ChatGPT.exe exports no napi_* symbols, serialport addon dies with delay-load 0xC06D007F #33381

Summary

Environment

Root cause (from minidump analysis)

Why it looks like a sudden regression

Repro

Possibly related

Environment

Reproduction and dump evidence

Environment

Timeline

Minidump confirmation

Controls

62 remaining items

Follow-up from the same Windows x64 machine: the fault storm now appears to have stopped

Additional local evidence

Current state

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows ARM64 app crash-loops on launch — ChatGPT.exe exports no napi_* symbols, serialport addon dies with delay-load 0xC06D007F #33381

Description

Summary

Environment

Root cause (from minidump analysis)

Why it looks like a sudden regression

Repro

Possibly related

Activity

github-actions commented on Jul 15, 2026

causer commented on Jul 15, 2026

TibbleForkDave commented on Jul 15, 2026

adamhep-ai commented on Jul 15, 2026

davidz91800 commented on Jul 15, 2026

ewrogers commented on Jul 15, 2026

blockpilgrim commented on Jul 15, 2026

Z2ZATL commented on Jul 15, 2026

FFFalexgo commented on Jul 15, 2026

Environment

Reproduction and dump evidence

nxt-ryan commented on Jul 15, 2026

Environment

Timeline

Minidump confirmation

Controls

NoSilver78 commented on Jul 15, 2026

62 remaining items

nxt-ryan commented on Jul 16, 2026

jin-ai95 commented on Jul 16, 2026

pincode-dev commented on Jul 16, 2026

jin-ai95 commented on Jul 16, 2026

nathanestone-alt commented on Jul 16, 2026

pjperez commented on Jul 16, 2026

431827701yx commented on Jul 16, 2026

Follow-up from the same Windows x64 machine: the fault storm now appears to have stopped

Additional local evidence

Current state

Alovchin91 commented on Jul 16, 2026

fleps commented on Jul 16, 2026

f7x57yqmvf-sketch commented on Jul 16, 2026

Fastkore commented on Jul 16, 2026

wadawada0211 commented on Jul 16, 2026

canenoneko commented on Jul 17, 2026

shijie-oai commented on Jul 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions