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.CodexMSIX from Microsoft Store, version 26.707.9981.0, arm64 (OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0) - Crashing process: Electron main process (
ptype=browserin 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 redirectednode.exeto 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-oaiwhen the host exe lacks NAPI exports). - Proper fix: link the ARM64
ChatGPT.exewith 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
.dmpappears in%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports\with exception0xC06D007F.
Happy to share a minidump privately if useful.
Possibly related
- #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).
87 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
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:
0xC06D007Fnode.exenapi_create_function@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node@worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialportI also traced the packaged renderer/main-process code. The Codex Micro bridge is gated by the numeric Statsig gate
3207467860. When enabled, the bridge callscodexMicro.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:
Additional isolation:
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
3207467860forwin32/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:
0xC06D007Fraised fromKERNELBASE.dll(delay-load helper)DelayLoadInfo:szDll=node.exe,szProcName=napi_create_function,dwLastError= 127 (ERROR_PROC_NOT_FOUND)hmodCur= base ofChatGPT.exe(so the node.exe→host-exe redirect worked; the export is simply missing)app.asar.unpacked\node_modules\@worklouder\device-kit-oai\...\@serialport\bindings-cpp\prebuilds\win32-arm64\node.napi.nodentdllloader frames +KERNELBASE+node.napi.node, i.e. death during N-API module registrationAdditional data points:
rendererWindowVisible=truein 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.primary_runtime_update_poll_failed ... 404 Not Foundnoise 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:
10.0.26200, ARM64, 12 logical processorsOpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g026.707.722210.144.2Reproduction:
ChatGPT.exeprocess tree disappears at ~7 seconds.44,594,842bytes).I independently decoded the minidump's exception stream and
DelayLoadInfoand got the same result:0xC06D007FKERNELBASE.dll+0x1233c4@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node@worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialportnode.exenapi_create_functiondwLastError:127hmodCur: base address of packagedChatGPT.exeThe 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:
Observed behavior:
ready-to-show.I also see the primary-runtime manifest 404 and the absence of a
windows-aarch64entry 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.
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 = falseandapps = falseinconfig.tomldoes 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:
0xC06D007Fnode.exenapi_create_function127@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node@worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialportThe 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 listandcodex 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/arm64remains 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
10.0.26200, ARM64X1E80100(12 cores)31.0.133.1OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g026.707.72221150.0.7871.1150.144.2Reproduction and dump evidence
ready-to-show, the renderer mounts, and the app-server initialization handshake succeeds.44,427,264bytes.DelayLoadInfoproduced:0xC06D007Fnode.exenapi_create_functiondwLastError:127(ERROR_PROC_NOT_FOUND)hmodCur: base address of the packagedChatGPT.exe@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node@worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialportThis 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
UX3407QA10.0.26200OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0ChatGPT.exeproduct/file version:150.0.7871.1150.144.4works normally on the same machineTimeline
Windows AppX deployment history shows the previous Codex build
26.707.9564.0was working earlier, then build26.707.9981.0was 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
DelayLoadInfoconfirms:0xC06D007Fnode.exenapi_create_functionChatGPT.exe@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.nodeunder@worklouder/device-kit-oaiThe 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
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 release26.707.72221. Codex CLI 0.144.2 works fine on the same machine.Same minidump signature as OP:
0xC06D007Ffrom the delay-load helper, missing procedurenapi_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)%USERPROFILE%\.codex(renamed away entirely; not even logged in)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.
Independent confirmation from another Snapdragon X Elite ARM64 machine, plus a verified non-destructive local
mitigation.
### Environment
### Timeline and reproduction
The app had worked normally for months and then exited suddenly while it was already running. After that, every launch
showed the workspace briefly and the complete ChatGPT.exe process tree disappeared approximately seven seconds after
process start.
Important timeline clarification: I uninstalled and reinstalled 26.707.9981.0 after the initial crash, in an attempt
to repair it. The reinstall did not cause the first failure and did not fix it.
The following did not help:
Every isolated profile produced its own Crashpad dump, ruling out profile corruption. I did not reset the real profile
because its projects and sessions were important.
A Windows cumulative update had been installed earlier, which initially made the OS update look suspicious. However,
no Windows update rollback was needed: the mitigation below works on the same 26200.8875 build. The native exception
also points entirely inside the packaged Codex dependency chain.
### Minidump confirmation
Both the original-profile dump and a clean-profile dump produced the same result:
Additional PE comparison:
This suggests both Work Louder native addons were packaged as regular Node ARM64 prebuilts rather than Electron-
rebuilt ARM64 binaries. Skipping only serialport may therefore expose the same failure later in HID.node.
The packaged renderer code also confirms that Statsig gate 3207467860 mounts the Codex Micro bridge. The bridge
immediately calls codexMicro.getState(), and the main-process Codex Micro service performs a top-level require of
@worklouder/device-kit-oai before checking whether hardware exists. This explains why unplugging the receiver does not
help.
### Verified local mitigation
This is not an official fix, but it is useful for confirming the diagnosis and restoring access without resetting the
user profile or modifying the signed WindowsApps package.
I used a process-scoped CJS preload which intercepts only @worklouder/device-kit-oai and returns a “no device found”
implementation.
disable-codex-micro.cjs:
'use strict';
const Module = require('node:module');
const originalLoad = Module._load;
const originalRequire = Module.prototype.require;
const target = '@worklouder/device-kit-oai';
const noop = () => {};
class DisabledDeviceDiscovery {
findWLDevices() {
return [];
}
}
class DisabledDeviceComm {
onConnectionEvent() {
return noop;
}
async connect() {}
async disconnect() {}
}
class DisabledDeviceApi {
onHidReceived() {
return noop;
}
onJoystickMove() {
return noop;
}
async sendLightingConfig() {
return false;
}
async sendThreadsLighting() {
return false;
}
async getDeviceStatus() {
return { batteryPercentage: null, isCharging: null };
}
}
const disabledDeviceKit = Object.freeze({
ConnectionEventType: Object.freeze({
CONNECTED: 'connected',
DISCONNECTED: 'disconnected',
ERROR: 'error',
}),
DeviceType: Object.freeze({
Project2077: 'Project2077',
}),
OAILightingEffect: Object.freeze({
off: 0,
breath: 1,
solid: 2,
snake: 3,
}),
RPCApiOAI: DisabledDeviceApi,
WLDeviceCommImpl: DisabledDeviceComm,
WLDeviceDiscovery: DisabledDeviceDiscovery,
});
Module._load = function (request, parent, isMain) {
if (request === target) return disabledDeviceKit;
return Reflect.apply(originalLoad, this, [request, parent, isMain]);
};
Module.prototype.require = function (request) {
if (request === target) return disabledDeviceKit;
return Reflect.apply(originalRequire, this, [request]);
};
I launch only the affected version with a process-local NODE_OPTIONS. I do not use setx or modify the global
environment:
$pkg = Get-AppxPackage -Name OpenAI.Codex
if ($pkg.Version.ToString() -ne '26.707.9981.0') {
throw "This workaround was verified only on 26.707.9981.0."
}
$hook = Join-Path $env:LOCALAPPDATA `
'OpenAI-Codex-Workarounds\disable-codex-micro.cjs'
$exe = Join-Path $pkg.InstallLocation 'app\ChatGPT.exe'
$oldNodeOptions = $env:NODE_OPTIONS
try {
$safeOption = "--require=$hook"
$env:NODE_OPTIONS = if (
[string]::IsNullOrWhiteSpace($oldNodeOptions)
) {
$safeOption
} else {
"$safeOption $oldNodeOptions"
}
Start-Process -FilePath $exe
}
finally {
if ($null -eq $oldNodeOptions) {
Remove-Item Env:NODE_OPTIONS -ErrorAction SilentlyContinue
} else {
$env:NODE_OPTIONS = $oldNodeOptions
}
}
### Verification
With that preload:
The limitation is that Codex Micro / Work Louder hardware integration is disabled. Other tested desktop functionality
remains available.
The safest immediate vendor mitigation is still to disable gate 3207467860 for win32/arm64. The proper package fix
appears to be rebuilding both Work Louder native addons for Electron ARM64, or guarding/lazily loading the entire
device integration so a native-addon failure cannot terminate the main process.
Independent confirmation — Surface Laptop 7 / Snapdragon X1-85
I am independently experiencing this exact crash on Windows ARM64.
Environment
OpenAI.Codex 26.707.9981.0Behavior
Codex was running normally through a long overnight session. When I returned the next morning, the application was closed.
Since then, every cold launch behaves the same way:
Windows AppModel-Runtime shows the Codex AppX container being created successfully and then destroyed approximately 6 seconds later. There is no corresponding normal Application Error event.
Troubleshooting already completed
The crash persists after all of the following:
.codexfolder and launching with completely fresh local stateThe crash reproduced identically in every case.
This appears to match the ARM64
0xC06D007F/ missingnapi_create_functionfailure described in this issue.I can provide additional logs or diagnostics privately if an OpenAI maintainer requests them.
Independent confirmation on Windows ARM64 here
I can independently reproduce this exact issue on another Windows-on-ARM device.
Environment
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g026.707.9981.0Reproduction
Evidence collected
Codex CLI initializedand the Electron window reachesready-to-show.%USERPROFILE%\.codexdirectory, and disablingconfig.tomldo not change the behavior.44,466,784bytes2026-07-16 02:41:45%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports\primary_runtime_update_poll_failed ... 404 Not Found, matching the report above.The symptoms and package build match this issue exactly. I can provide the Crashpad
.dmpprivately to OpenAI engineering if needed.Independent confirmation from a Microsoft Surface Pro on Windows 11 ARM64 / Snapdragon.
Environment
26200OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g026.707.722210.144.2Reproduction
ready-to-show.ChatGPT.exeprocess tree exits by second 8 without a Windows Application Error event.Isolation completed
apps=false, fresh user state, and repair/reinstall did not resolve it.The package, timing, and dump behavior match the ARM64 N-API /
@serialportfailure documented in this issue. I have retained the minidump and can provide it privately through an OpenAI-approved upload channel; I will not attach it publicly because it may contain process memory.Independent confirmation from another Windows 11 ARM64 device.
Environment
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g026.707.9981.0Behavior
ChatGPT.exeprocess exits approximately 6 seconds later.WinDbg confirmation
0xC06D007Fnode.exenapi_create_function127 / ERROR_PROC_NOT_FOUND@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node@worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialportChatGPT.exe.Troubleshooting completed
The crash reproduced identically after all of the above. This matches the ARM64 native-addon/runtime incompatibility described in this issue. I have retained the minidump and can provide it privately through an OpenAI-approved upload channel.
Confirmed this on a Asus A16 UX3607OA, Snapdragon(R) X2 Elite Extreme - X2E94100 - Qualcomm Oryon(TM) CPU (4.45 GHz)
Windows Information
Completely removed the app multiple times, reinstalled from Store / Direct link from OpenAI, apps runs the first wizard, the second it goes to show the Chat interface, it crashes and continue to crash.
It was working fine yesterday.
Not sure if related but today there were 2 Windows Updates installed on my machine:
Crashing Windows 11 Arm64 in a Parallels Virtual Machine for me.
Independent confirmation on a Windows 11 ARM64 system with the same Microsoft Store build.
Environment
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0app/ChatGPT.exe0.144.40.144.2Updating the global CLI did not affect the crash because the desktop app launches its own bundled
resources/codex.exe. The bundled CLI starts successfully and completes its app-server handshake before the desktop process exits.Observed failure
In controlled launches, the Electron main process lived for about 5.7 to 7.0 seconds and exited with:
The renderer reached its mounted/window-ready state and model loading completed; the log then ended abruptly without a JavaScript fatal error.
A high-frequency loaded-module trace showed the following final native loads:
The process terminated approximately 226 ms after the ARM64 serialport prebuild and
SETUPAPI.dllloaded. No non-system or non-package injected DLLs were present.Static inspection of the packaged renderer also confirms that Statsig gate
3207467860mountsCodexMicroBridge; the bridge calls the Codex Micro service state path, and that service imports@worklouder/device-kit-oai, which loads the nested serialport native addon.This independently corroborates the report's root-cause area: the optional Codex Micro integration activates on ARM64 and its packaged serialport native module terminates the Electron main process. Repair/reset/reinstall or updating the standalone CLI should not address this package-level failure.
Suggested short-term mitigation remains disabling gate
3207467860for Windows ARM64 until the native addon/runtime packaging is corrected.Same crash here, confirming on another ARM64 machine.
Environment
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0, app release 26.707.72221App window appears for ~2.5 s, then the process exits. Reinstalling from the Store does not fix it.
Crash details (from local Crashpad minidump)
0xC06D007F(VC++ delay-load: procedure not found),dwLastError = 127(ERROR_PROC_NOT_FOUND), raised viaKERNELBASE.dllDelayLoadInfo: szDll =node.exe, missing procedure =napi_create_function;hmodCurresolves to the base ofChatGPT.exe@worklouder/device-kit-oai/.../@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.nodebetter_sqlite3.node,windows-updater.node,windows-account.nodeapp\ChatGPT.exe: 2 exports total, zeronapi_*— so the serialport addon's delay-load ofnapi_create_functioncan never resolve and takes down the main processpermissionProfile/list; Crashpad dump written the same secondMatches the analysis in this thread and the sibling reports.
Additional confirmation from a third Windows 11 Home ARM64 machine (not a Surface) on Codex Desktop 26.707.9981.0 arm64 — corroborates @causer's serialport/napi delay-load analysis.
Same symptom pattern: the app ran normally for hours, then began crash-looping, with every subsequent launch exiting ~10–15 seconds after the window appears (no error dialog). A Crashpad minidump was generated at the moment of crash.
On this machine the crash-loop onset also coincided with the MSIX auto-update from 26.707.8479.0 → 26.707.9981.0 (AppX deployment log: update completed 14:56:36 local; first crashing session started 14:56:58). Build 8479.0 had been stable for weeks. Consistent with a Statsig gate flip landing around the same window as the update.
No Codex Micro / Work Louder device connected or knowingly enabled. Happy to share the minidump if useful.
I am experiencing the same crash on a current Windows ARM64 device.
Environment:
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0
The app worked normally for several days. Then, without any intentional changes to my computer, it suddenly started closing a few seconds after launch.
The Codex interface loads and becomes visible, but after approximately 8–15 seconds the entire app exits without displaying an error message. A new Crashpad dump is created after each crash.
I have already tried:
None of these steps helped.
The issue also occurs with another OpenAI account and in a fresh Windows user profile. This strongly suggests that it is not caused by my account, my previous conversations, or a corrupted Windows user profile.
The application logs show that the Codex CLI and the main interface initialize successfully before the process exits.
The logs also contain:
“Failed to download primary runtime manifest (404 Not Found).”
However, based on the technical findings in this issue, that message may be unrelated to the actual crash.
My symptoms, device architecture, app version, and Crashpad behavior appear to match the reported Windows ARM64 crash involving the serialport native module.
Could the engineering team please check whether the ARM64 package contains or loads an incompatible @serialport/bindings-cpp module, or whether the required Node-API exports are missing from the ARM64 ChatGPT.exe build?
For affected users, please consider one of the following temporary or permanent solutions:
At the moment, the Microsoft Store automatically installs the ARM64 package and does not allow ARM64 users to select the x64 version manually.
For paying and non-technical users, switching to the CLI or manually configuring an IDE extension is not an adequate replacement for the desktop application.
I have preserved the application logs and Crashpad dump and can provide them privately through an official secure support channel if required. I will not upload the memory dump publicly because it may contain sensitive information.
Thank you for investigating this issue.
Confirming the same issue on a Windows ARM64 Surface.
Device:
Microsoft Surface running Windows 11 ARM64
Codex package:
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0
Behavior:
The Codex desktop app opens normally, remains visible for approximately 8 seconds, and then closes without displaying an error.
What I have already tried:
"local":"auto"value from.codex-global-state.jsonNone of these steps resolved the problem.
Windows logs show that the application launches successfully:
app\ChatGPT.exeis startedThere is no conventional Application Error, exception code, Reliability Monitor failure, or failed activation event.
ChatGPT Classic continues to work normally on the same device and account.
This is preventing me from accessing and continuing work on an existing local development project. Based on the identical ARM64 package version and startup behavior reported here, this appears to be the same issue.
I can reproduce this issue.
Device: Microsoft Surface Pro 11
Processor/platform: Snapdragon, Windows 11 ARM64
Codex/ChatGPT app package: OpenAI.Codex
Version: 26.707.9981.0 ARM64
Behaviour:
Troubleshooting already attempted:
I have not reset or deleted the app’s local data.
Independent confirmation from another Windows 11 ARM64 system using Store package OpenAI.Codex_26.707.9981.0_arm64.
ProcDump initially reported the same unhandled 0xC06D007F delay-load failure. A subsequent full exception dump captured an additional downstream failure:
exception: 0xC0000005 execute access violation
attempted execute address / PC: 0x0
faulting module: node.napi.node
stack: node_napi+0x8694 → napi_register_module_v1 → Electron/Node module registration
bucket: SOFTWARE_NX_FAULT_NULL_INVALID_POINTER_EXECUTE_c0000005_node.napi.node
This appears consistent with the missing N-API export ultimately resulting in a null function-pointer call, rather than representing a different root cause.
Repair, reset, cache clearing, uninstall/reinstall and reboot did not resolve it. I can provide the full dump privately, but will not attach it publicly because it contains process memory.
Confirm the same, my Hermes Agent provided me the same root-cause. Appreciate a fast fix!
one viable mitigation is to disconnect Internet (e.g., turn off Wi-Fi) before launching the Codex app. then only wait until the app is stably running, turn Wi-Fi back on
i suppose the worklouder stuff is gated by StatSig so launching without Internet access should help opting out from the feature. adding
ab.chatgpt.com 127.0.0.1to yourhostsfile to disable the connection can achieve the similar effect.I can’t confirm that. The app runs without an internet connection, but when you turn Wi-Fi back on, it crashes after a few seconds.
Also, adding ab.chatgpt.com 127.0.0.1 to hosts file didn't have any effect.
Confirming @aonbrowser's preload mitigation works on a Surface Pro X / Snapdragon, Windows 11 ARM64 build 26220, Store package
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0— but with one gotcha that will bite anyone who copies the instructions verbatim.The hook must live OUTSIDE
%LOCALAPPDATA%The instructions place
disable-codex-micro.cjsunder$env:LOCALAPPDATA\OpenAI-Codex-Workarounds\. On this machine that failed, and it fails silently from the user's point of view — the app dies in ~2s with no Crashpad dump, which looks like a different bug rather than a broken workaround.stderr shows what's really happening:
NODE_OPTIONS=--require=...is honored (noteinternal/preloadin the stack — the preload ran). The module just isn't resolvable, because the MSIX Desktop AppX container redirectsAppData\Localinto...\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\. A hook stored under the real%LOCALAPPDATA%is invisible to the containerized process.Fix: put the
.cjsanywhere outside AppData. I usedC:\Users\<u>\CodexWorkaround\. Same file, same launcher, only the path changed:Two useful notes: launching
app\ChatGPT.exedirectly still gets full package identity (AppModel-Runtime logs201 Created process ... for application OpenAI.Codex_2p2nqsd0c76g0!App [FinishPackageActivation]+211 Added process ... to Desktop AppX container), so you don't lose anything by bypassing the Start Menu tile. And if you're debugging this,-RedirectStandardErroris essential — the bootstrap failure appears only on stderr, with no dump and no Application Error event.Result
| | before | with hook (correct path) |
|---|---|---|
| t+10s | 8 procs | 7 procs |
| t+25s | 0 — dead | 7 procs |
| t+45s | 0 | 7 procs |
| t+75s | 0 | 7 procs |
| new Crashpad dumps | 1 per launch | 0 |
Window responsive, title
ChatGPT, signed package untouched,~/.codex(auth/sessions/memories) untouched, no admin required. Codex Micro is the only thing lost.Also confirming the two other findings in this thread on my hardware: the crash is not fixable by uninstall/reinstall (the Store serves the identical 9981.0 — FE3 exposes exactly one revision, and the separate "ChatGPT (Beta)" listing
OpenAI.CodexBeta 26.707.3351.0ships the same unrebuilt@worklouderaddons), and it is not fixable by editing the package — Windows refuses to rename the addon even for an elevated Administrator who has taken ownership and granted themselves FullControl, with no DENY ACEs and Controlled Folder Access off.Filed separately as #33415 before finding this thread; happy to close that as a duplicate of this one. The gate rollback for
3207467860remains the right immediate vendor mitigation.maybe you haven't waited long enough for it to give up connecting to chatgpt.com... that said, i can confirm simply disabling connection to ab.chatgpt.com won't work, and we don't want to disable backend access to chatgpt.com altogether.
i guess this is the one-liner that i'll keep using to launch the app, until OpenAI patches the issue:
<code>$h="$env:TEMP\codex-disable-worklouder.cjs"; 'const M=require("node:module"),l=M._load;M._load=function(i,...a){return i==="@worklouder/device-kit-oai"?{ConnectionEventType:{CONNECTED:0,DISCONNECTED:1,ERROR:2},DeviceType: {Project2077:0},OAILightingEffect: {off:0,solid:1,breath:2,snake:3},RPCApiOAI:class{},WLDeviceCommImpl:class{},WLDeviceDiscovery:class{findWLDevices() {return[]}}}:l.call(this,i,...a)};' | Set-Content $h -Encoding ascii -NoNewline; $env:NODE_OPTIONS="--require=$h"; Start-Process (Join-Path (Get-AppxPackage OpenAI.Codex).InstallLocation 'app\ChatGPT.exe'); Remove-Item Env:NODE_OPTIONS
</code>
it basically launches the Codex desktop app while temporarily injecting a Node.js module shim that pretends the Work Louder device package exists
it's quite disappointing how openai didn't test things before releasing this broken keyboard driver, yet they've been marketing this $200 keypad for a month
ironically, i did buy one, before my Codex app died
Running into this issue also :( + 1
Just wanted to add some data here because the thread is currently heavily focused on ARM64, but this reproduces identically on standard Intel x64. I'm running an Intel i9 on Windows 11 25H2 with the x64 package (OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0) and getting the exact same 0xc06d007f crash loops and typing stalls described above.
A first-chance process dump shows the breakdown: The bundled native serialport.node addon delay-imports node.exe!napi_module_register. The Electron loader resolves node.exe to the running ChatGPT.exe binary, which doesn't export that symbol. Interestingly, chrome.dll in the same package layout does export napi_module_register, but the linkage isn't reaching it, causing a fatal ERROR_PROC_NOT_FOUND (127). This also explains why @junhaoliao's module-starvation shim works so well. Every window spins up a codexMicro service that dynamically evaluates codex-micro-service-CR6sUcZG.js. Because of CommonJS module evaluation order, the top-level createRequire for @worklouder/device-kit-oai fires immediately at module scope. This forces serialport.node to load and crash before the app even runs findWLDevices() to see if the hardware is actually there.
I spent a few hours trying to manually flip the Statsig gate (3207467860) to false in the local LevelDB cache, but the SDK aggressively overwrites it from the server on boot anyway, so don't bother trying to patch the local DB. Until OpenAI fixes the import sequence (lazy-loading the hardware package only after a device is verified) or fixes the delay-load hook redirection to target chrome.dll, using the preload script outside AppData is the only durable fix. Huge thanks to @junhaoliao for the workaround—saved me a massive headache.
p.s. I came here after my RCA with my tail between my legs, upset i found the issue but couldnt find a workaround but to share my findings. Only to see in the time i was working on it, @junhaoliao had not only found the same issue, but actually come up with a JS slight of hand workaround thats brillient and made me even more sad i didnt think of it. Fair play and bravo @junhaoliao
Independent confirmation from another Windows 11 ARM64 system.
Environment
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0PowerShell verification:
Reproduction
ChatGPT on the web and ChatGPT Classic continue to work normally on the same computer and account. The problem appeared with the current desktop-app rollout/update.
Correlation with this issue
The platform, package version, architecture, and launch-crash behavior match the reports in this thread involving:
0xC06D007F/ERROR_PROC_NOT_FOUNDnapi_create_function@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node@worklouder/device-kit-oaiI have not independently parsed this machine's Crashpad dump, so the low-level exception details above are a correlation with the established reports—not a separate dump-level root-cause claim. This report independently confirms that the affected Store package and user-visible crash reproduce on an HP Snapdragon X Elite ARM64 system.
I have not reset or reinstalled after confirming that fresh installations of the same Store package reproduce the issue. No dump, logs, or screenshots are attached because they may contain sensitive local process or session data.
같은 증상이네요. 멀쩡히 사용하고 있다가 꺼져서 지금까지 안되네, 몇번을 다시 깐건지;;;;
Environment: Windows 11 ARM64 using the Microsoft Store Codex package, build 26.707.9981.0 ARM64.
Codex launched but exited after roughly 10–15 seconds. Direct execution from the protected WindowsApps path failed with Access is denied, so the registered AppX application entry had to be used.
A temporary CommonJS preload hook was created that intercepts only @worklouder/device-kit-oai and returns inert stub classes and constants. NODE_OPTIONS=--require=<hook path> was temporarily set at user scope so the packaged AppX process inherited it. Codex was then launched using shell:AppsFolder\<PackageFamilyName>!App, and the prior user-level NODE_OPTIONS value was restored immediately after the process started.
Result: Codex launched successfully and remained stable beyond the previous crash window. No installed package files were modified. Session-scoped NODE_OPTIONS was not sufficient because AppX activation did not inherit it; temporary user-level scope was required.
The hook contains no network calls or credential access and only overrides the exact Work Louder module name. This should be treated as a temporary mitigation pending an official ARM64 fix or feature-flag rollback.
Operational notes
Run the script from a standard PowerShell window, not an elevated administrator window. The user-level NODE_OPTIONS value is restored immediately after the Codex process starts. The temporary .cjs file remains in %TEMP%, but it has no effect unless referenced through NODE_OPTIONS.
After an official fix is installed, remove the hook:
Remove-Item "$env:TEMP\codex-disable-worklouder.cjs" `
-ErrorAction SilentlyContinue
The workaround should then be retired rather than retained as a permanent launcher.
<#
Temporary workaround for openai/codex#33381 on Windows ARM64.
What it does:
@worklouder/device-kit-oai.
Run from a normal, non-administrator PowerShell session.
#>
$ErrorActionPreference = "Stop"
No workstation-specific change is normally required.
$hook = Join-Path $env:TEMP "codex-disable-worklouder.cjs"
@'
const Module = require("node:module");
const originalLoad = Module._load;
Module._load = function (request, ...args) {
if (request === "@worklouder/device-kit-oai") {
return {
ConnectionEventType: {
CONNECTED: 0,
DISCONNECTED: 1,
ERROR: 2
},
DeviceType: {
Project2077: 0
},
OAILightingEffect: {
off: 0,
solid: 1,
breath: 2,
snake: 3
},
RPCApiOAI: class {},
WLDeviceCommImpl: class {},
WLDeviceDiscovery: class {
findWLDevices() {
return [];
}
}
};
}
return originalLoad.call(this, request, ...args);
};
'@ | Set-Content -Path $hook -Encoding ASCII -NoNewline
Preserve any existing user-level NODE_OPTIONS value.
$previousUserNodeOptions = [Environment]::GetEnvironmentVariable(
"NODE_OPTIONS",
"User"
)
try {
# Discover the installed Codex package.
$pkg = Get-AppxPackage OpenAI.Codex
if (-not $pkg) {
throw "The OpenAI.Codex Microsoft Store package was not found."
}
# Read the registered AppX launch entry.
$manifest = Get-AppxPackageManifest $pkg
$application = $manifest.Package.Applications.Application |
Where-Object { $_.Executable -eq "app/ChatGPT.exe" } |
Select-Object -First 1
# Fallback in case the executable name changes in a future package.
if (-not $application) {
$application = $manifest.Package.Applications.Application |
Select-Object -First 1
}
if (-not $application) {
throw "No launchable application was found in the Codex package manifest."
}
$aumid = "$($pkg.PackageFamilyName)!$($application.Id)"
# AppX activation did not inherit a PowerShell-session-only variable.
# User scope is therefore set temporarily.
[Environment]::SetEnvironmentVariable(
"NODE_OPTIONS",
"--require=$hook",
"User"
)
# Also set it in the current session for child-process compatibility.
$env:NODE_OPTIONS = "--require=$hook"
# Launch through the registered AppX application entry.
Start-Process explorer.exe -ArgumentList "shell:AppsFolder\$aumid"
# Wait for the Codex Chromium host process.
$startupTimeoutSeconds = 30
$deadline = (Get-Date).AddSeconds($startupTimeoutSeconds)
$process = $null
do {
Start-Sleep -Seconds 1
$process = Get-Process ChatGPT -ErrorAction SilentlyContinue |
Select-Object -First 1
} until ($process -or (Get-Date) -ge $deadline)
if (-not $process) {
throw "Codex did not start within $startupTimeoutSeconds seconds."
}
Write-Host "Codex launched successfully."
Write-Host "Process ID: $($process.Id)"
Write-Host "AppX ID: $aumid"
Write-Host "Temporary hook: $hook"
}
finally {
# Restore the prior user environment, even if launch fails.
[Environment]::SetEnvironmentVariable(
"NODE_OPTIONS",
$previousUserNodeOptions,
"User"
)
Remove-Item Env:NODE_OPTIONS -ErrorAction SilentlyContinue
}
Independent reproduction confirmed on Windows 11 ARM64.
Package:
OpenAI.Codex_26.707.9981.0_arm64
Behavior:
The full Electron/Codex process tree starts, the window appears, and the
main process exits consistently after approximately 7–10 seconds.
Loader failure:
0xC06D007F
dwLastError = 127 / ERROR_PROC_NOT_FOUND
DLL = node.exe
procedure = napi_create_function
Faulting module:
@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node
Dependency chain:
@worklouder/device-kit-oai
-> @worklouder/wl-device-kit
-> serialport
-> @serialport/bindings-cpp
The delay-load resolves node.exe to ChatGPT.exe, but the packaged ARM64
host does not export napi_create_function.
A byte-identical Microsoft Store uninstall/reinstall did not resolve it.
Fresh profile, all plugins disabled, cache isolation, re-registration,
and package-identity --disable-gpu testing also failed.
Repositories and .codex state are unrelated and remain intact.
Crash dump retained locally and available privately if requested.
Independent confirmation from another Windows 11 ARM64 system using the Microsoft Store build
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0.Observed behavior:
Local diagnosis on this machine also matched the reported failure signature: exception
0xC06D007F, consistent with the@serialport/bindings-cpp/ missingnapi_create_functionfailure described in this issue.This further suggests the problem is not caused by corrupted local app data, cached state, or an incomplete installation. Codex CLI remains available as a temporary workaround.
I can confirm this issue on another Windows ARM64 device and would like to provide additional diagnostic information.
Environment
Symptoms
Diagnostics
PowerShell
Windows Event Viewer
I found crash records for previous ARM64 releases (26.623.8305.0 and 26.707.8479.0).
For version 26.707.9981.0, however, Windows Event Viewer does not generate a new Application Error entry on my machine.
Crashpad
Crashpad is generating minidumps.
Recent dump files include:
Historical observations
Earlier ARM64 releases occasionally crashed on my machine:
However, 26.707.9981.0 now crashes every single launch, approximately 5–6 seconds after startup.
Current workaround
Available diagnostics
If it would help the investigation, I can provide:
Thank you for investigating this issue.
If needed, I can also privately provide the Crashpad minidump files themselves for analysis.
<img width="2194" height="1416" alt="Image" src="https://github.com/user-attachments/assets/a04637af-0360-4366-83a0-c6157afed90d" />
<img width="2194" height="1453" alt="Image" src="https://github.com/user-attachments/assets/c57d375b-1d71-421a-a5db-f00b4bb22792" />
<img width="1725" height="918" alt="Image" src="https://github.com/user-attachments/assets/23aa2d21-0868-45d8-9fd0-36c798a34016" />
I can reproduce this consistently: the ARM64 build crash-loops, while the same version works normally on x64
My issue appears to match this report very closely.
Affected machine
OpenAI.ChatGPT-Desktop 1.2026.190.0 ARM64OpenAI.Codex 26.707.9981.0 ARM64Status: OKinGet-AppxPackageActual behavior
The application was working normally earlier on the same day. No significant local configuration changes were made, but it then suddenly began crash-looping.
On every launch:
The AppModel Runtime log shows that the
OpenAI.Codexprocess is created successfully and that its AppX container is subsequently destroyed.I do not see a standard Codex
Application Error 1000event that clearly explains the termination.Troubleshooting already attempted
I have already tried:
```powershell
DISM.exe /Online /Cleanup-Image /RestoreHealth
Confirming the preload-hook mitigation works on my machine too (Surface, Windows 11 ARM64,
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0).Used the same approach @junhaoliao / @TerraSYNCBIIZ / @sentinel-deployment described: a small
.cjspreload hook (stored outside%LOCALAPPDATA%per @TerraSYNCBIIZ's note about the AppX container redirect) that interceptsrequire("@worklouder/device-kit-oai")and returns inert stubs, launched viaNODE_OPTIONS=--require=<hook>scoped to a singleStart-Process app\ChatGPT.execall so nothing persists in the environment.Result: process count stayed stable well past the previous ~10-15s crash window (tested to 30s+), no new Crashpad dump was written, and the app is usable. Only Codex Micro / hardware-device support is disabled — everything else works normally.
Thanks to everyone who dug into this — hope OpenAI ships an official fix (flag rollback or export-table fix) soon so this workaround can be retired.
Confirming on my machine — same exception code, same modules.
Environment
OpenAI.Codex26.707.9981.0 arm64 (OpenAI.Codex_2p2nqsd0c76g0), MSIX from StoreVerified locally
0xC06D007Fdevice-kit-oai,bindings-cpp,node.napi.node,ChatGPT.exeNote for anyone else trying to capture a dump: Crashpad uploads and purges
...\Crashpad\reports\*.dmpwithin a few minutes — the file is often gone by thetime you try to open it. Polling the directory during launch gets you a copy:
$src = "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports"
$dst = "$env:USERPROFILE\codex-dumps"
New-Item -ItemType Directory -Force -Path $dst | Out-Null
1..450 | % { gci $src -Filter *.dmp -EA 0 | % { Copy-Item $_.FullName $dst -Force -EA 0 }; sleep -Milliseconds 200 }
Reading the exception code without WinDbg: parse the minidump stream directory,
find stream type 6 (ExceptionStream), read the UInt32 at
Rva + 8.I am experiencing the same reproducible crash loop on another Windows 11 ARM64 device, and I was able to analyze the Crashpad minidump with WinDbg.
Environment
Architecture: ARM64
OS: Windows 11
Windows build: 26200.8875
Codex app version: 26.707.9981.0
Package architecture: Arm64
Process: ChatGPT.exe
Location: Mexico
First observed: July 15, 2026
Package information reported by PowerShell:
Name: OpenAI.Codex
Version: 26.707.9981.0
Architecture: Arm64
Symptoms
Codex opens normally at first. The login flow completes successfully. The main interface and existing projects briefly become visible. Approximately eight seconds after process startup, the entire application exits silently. No error dialog is displayed. The issue occurs on every launch. Windows Reliability Monitor does not show a useful crash entry. Crashpad generates a new .dmp file after the crash.
Troubleshooting already attempted
Windows app Repair, Windows app Reset, restarting Windows, starting Codex with a completely fresh .codex directory, renaming the project or repository that Codex might have been restoring, and disabling the internal updater using CODEX_SPARKLE_ENABLED=false.
None of these steps resolved the crash.
The application also crashed with a new and empty .codex directory, so the issue does not appear to be caused by existing conversations, projects, plugins, configuration, or local session state.
WinDbg minidump analysis
ExceptionCode: c06d007f
PROCESS_NAME: ChatGPT.exe
Failure.Bucket: APPLICATION_FAULT_c06d007f_node.napi.node!Unknown
MODULE_NAME: node_napi
IMAGE_NAME: node.napi.node
SYMBOL_NAME: node_napi+2798c
OSPLATFORM_TYPE: arm64
Relevant stack:
KERNELBASE!RaiseException+0x74
node_napi+0x2798c
WinDbg also reports an attempt to load the native ARM64 module located under:
@worklouder\device-kit-oai\node_modules@worklouder\wl-device-kit\node_modules\serialport\node_modules@serialport\bindings-cpp\prebuilds\win32-arm64\node.napi.node
WinDbg reports:
Unable to load image …\win32-arm64\node.napi.node, Win32 error 2
The process uptime at the time of the crash was approximately eight seconds:
Timeline.Process.Start.DeltaSec: 8
This appears consistent with the 0xC06D007F ARM64 Node-API / napi_create_function failure described in this issue.
I also verified the exact installed path referenced by WinDbg using PowerShell, and Test-Path returned False.
Could OpenAI temporarily disable the device-kit / serialport feature remotely for Windows ARM64 users, so affected installations can launch and receive the next update?
I can provide the Crashpad minidump privately if an OpenAI maintainer provides an approved secure upload method. I would prefer not to upload the dump publicly because it may contain local paths or portions of process memory.
New data point to report:
After restoring the package to its normal state, the original crash was reproducible again. Recreating the preload hook and temporarily setting NODE_OPTIONS at user scope allowed Codex to launch successfully again. This confirms the workaround is repeatable and that the underlying AppX package does not require repair or reinstallation.
Independent confirmation: controlled host A/B, mixed-architecture packaging, and Snapdragon X Elite performance
I reproduced the same failure on a Windows 11 ARM64 system with a Snapdragon X Elite using Codex Desktop
26.707.9981.0(ARM64). I am intentionally omitting machine/account identifiers, local paths, dump hashes, and other workstation-specific data.Controlled host A/B test
The crash signature matches this issue:
0xC06D007F/ERROR_PROC_NOT_FOUND(127)node.exenapi_create_function@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.node@worklouder/device-kit-oaiI then tested the exact ARM64 serial-port addon copied from the signed package in controlled hosts:
24.14.0.42.1.0ARM64 and exits cleanly.42.1.0ARM64'selectron.exehas 3,454 exports and includesnapi_create_function.ChatGPT.exehas only two exports and does not includenapi_create_function.This rules out a corrupt addon or an inherently invalid ARM64 binary. The deterministic failure is at the boundary between the addon and the packaged desktop host.
Cross-architecture scope
The analysis in #33375 indicates that x64 has the same underlying delay-load/linkage defect, but it commonly presents as repeated faults and severe UI stalls rather than the ARM64 startup crash loop. The two packages select different serial-port artifacts, while both packaged host executables expose only two exports. The durable fix should therefore cover both Windows architectures; disabling the optional integration for ARM64 remains the fastest way to stop the current hard crash loop.
I also found a separate architecture-closure issue in the signed ARM64 package: the Computer Use runtime is ARM64 except for its bundled
codex-computer-use.exe, which is x64. That helper must run through Windows-on-ARM emulation. This is not the cause of the serial-port startup crash, but it is a plausible contributor to Computer Use latency and should be rebuilt as ARM64.Performance observation (qualitative, not a benchmark)
On the same Snapdragon X Elite machine, the native ARM64 package felt materially less responsive than the x64 package running under Windows-on-ARM emulation. The most noticeable symptoms were slower project/task switching and loading, plus UI/cursor responsiveness and occasional system-visible lag. This is a user-experience comparison, not a controlled ARM64-vs-x64 benchmark, so it should be profiled independently from the deterministic crash. The mixed x64 helper in the ARM64 package is one concrete packaging issue, but I am not claiming it alone explains the broader lag.
Suggested fixes and regression coverage
codex-computer-use.exein the ARM64 package and add an architecture-closure check for every executable, DLL, and.nodeaddon.Resilience/diagnostics proposal
This incident would be much easier to recover from if the open-source Codex CLI/app-server exposed a desktop recovery mode such as
codex doctor desktop, independent of the Electron process. It could:This should not self-modify signed binaries. The useful boundary is diagnosis plus supported policy/gate/runtime-cache recovery, with explicit consent and rollback.
I retained the crash dump locally but will not attach it publicly because dumps can contain process memory and private data. It can be shared only through an OpenAI-approved private channel if requested.
Additional affected-user report, shared with explicit permission:
26.707.9981.00xC06D007F/ missingnapi_create_functionsignature documented in this issueNo crash dump, account information, or private file paths are being posted publicly.
Also happening on Windows 11 x64 (build 26200), same exception
0xC06D007F and same load chain (device-kit-oai → CodexMicroService →
serialport.node). Codex 26.707.9981.0 x64, stable since install,
started July 15.
Unlike ARM64 the app doesn't close — the UI freezes for 2–5 seconds
in a loop, each freeze lining up with a silent ChatGPT.exe crash.
Generated 30+ dumps in 24 hours before I suppressed them. x64
ChatGPT.exe does export napi_* symbols, so the root cause on x64
may be a prebuilt binary dependency mismatch rather than missing
NAPI exports — but the crash chain is identical.
Independent VMware Fusion ARM64 reproduction
I can independently reproduce this exact crash in a Windows ARM64 virtual machine hosted by VMware Fusion.
Environment
26100.4349OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g026.707.9981.0Behavior
This exact installed version completed multiple successful launches before the failure began. It then exited abruptly during a long-running session. Since that point, every launch renders the main UI and then terminates the entire AppX container after roughly 8–12 seconds, producing a new Crashpad dump.
A fresh reproduction on July 16 lasted about 10.2 seconds from AppX launch to container destruction.
Matching crash signature
0xC06D007Fnode.exe!napi_create_functionChatGPT.exelastError=127(ERROR_PROC_NOT_FOUND)@worklouder/device-kit-oai/.../@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.nodeBoth the host executable and addon are ARM64, so this is not an x64/ARM64 binary mismatch.
PE export inspection matches the analysis in this issue:
ChatGPT.exeexports onlyGetHandleVerifierandIsSandboxedProcess, with nonapi_*ornode_api_*exports.chrome.dlldoes exportnapi_create_functionand the wider N-API surface.There was no AppX deployment or Store update near the onset. The same-day deployment record was the earlier interactive install/registration and was explicitly logged as
IsUpdate=false. The Store currently offers no newer package to this machine/account/release ring.A successful Statsig interval refresh completed approximately two seconds before the first abrupt exit. This is correlation only: twenty earlier refreshes completed normally, and the logs do not expose a changed Work Louder/Codex Micro gate value.
The latest minidump is retained and can be provided through a private OpenAI-approved upload channel. I am not attaching it publicly because it may contain process memory and local identifiers.
This adds a VMware Fusion reproduction alongside the Parallels ARM VM and physical Snapdragon reports already present in the thread. The CLI remains usable, but the desktop GUI and Computer Use service are unavailable.
_Disclosure: this comment was prepared and posted via Codex CLI at my explicit request after the Codex desktop GUI crashed._
Independent reproduction on a Samsung Galaxy Book 6 Edge running Windows 11 ARM64 (Snapdragon), with a ChatGPT Pro account.
Affected app package
OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0Exact behavior
The exit looks clean from the user side: there is no visible error dialog, no forced-close message, and no matching failure in Reliability Monitor or Windows Application Error logs.
Troubleshooting already performed
%USERPROFILE%\.codexNone of these changed the behavior. Other Windows applications work normally. The failure is specific to the ChatGPT/Codex desktop app and occurs precisely when the authenticated main UI is mounted.
This matches the reported ARM64
0xC06D007F/ missingnapi_create_function/serialportnative-addon failure. Unfortunately, the Crashpad data was not preserved because the application data was cleared before the root cause was identified.@tibo-openai is someone taking a look at this?
Independent confirmation from another affected system, based on a newly captured and independently analyzed Crashpad minidump.
Environment
10.0.26200OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0ChatGPT.exe150.0.7871.115Behavior
The app opens for a few seconds and then exits silently. The analyzed process uptime was approximately 10 seconds. No corresponding Application log event or Reliability Monitor record was produced, but Crashpad generated a 44 MB minidump.
Matching crash signature
The minidump matches this issue exactly:
0xC06D007Fnode.exenapi_create_functiondwLastError = 127(ERROR_PROC_NOT_FOUND)@worklouder/device-kit-oai/.../@serialport/bindings-cpp/prebuilds/win32-arm64/node.napi.nodeKERNELBASE.dll,node.napi.node, andchrome.dll.Changing the user configuration, including disabling
remote_connections, did not affect the crash, which is consistent with this being a packaged ARM64 native-module/host-export problem rather than profile corruption or a Remote Control setting.The minidump has been retained and can be provided privately through an OpenAI-approved upload channel if requested. It is intentionally not attached publicly because it may contain process-memory data.
_Disclosure: this comment was translated, prepared, and posted through ChatGPT/Codex at my explicit request._
Independent Windows x64 confirmation
This is an independent reproduction on Windows 11 x64, with two minidumps and a package-level rollback comparison.
Environment
10.0.22631OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0codex@26.707.7222124.14.0Behavior and event evidence
ChatGPT.exewith exception0xC06D007F.Matching minidump evidence
Two independently captured dumps contain the same DelayLoadInfo:
The delay-import descriptor and IAT resolve to the x64 addon:
The app's own Sentry logs independently report DLL initialization failure for the same
serialport.nodepath.Trigger and rollback isolation
The packaged renderer checks Statsig gate
3207467860, then lazy-loadsCodexMicroBridgeand callscodexMicro.getState(). The main process lazy-loadscodex-micro-service-CR6sUcZG.js, whose top-level initialization requires@worklouder/device-kit-oai.AppX deployment history shows an update from
26.707.9564.0to26.707.9981.0at 09:10, followed by the first fault at 23:54. I downloaded and verified the previous Microsoft-signed package. These files are byte-identical between 9564 and 9981:| File | SHA-256 |
| --- | --- |
|
ChatGPT.exe|28C3E8B6C55FFF39ECB12A5EB27F493ABF997804247517AA7A46C277CA5D9E93||
serialport.node|2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006||
app-main-CAsXyywb.js|01E0DD22E00BBA96E036E2EFEA88983C76984A6868CBD88B2125FE2E573C9166||
codex-micro-service-CR6sUcZG.js|0BB261E3EED89FF69384754AB67DF49C9F10DBD2FA567104C5859F43D026C911|This means reinstalling the current package or rolling back only one version cannot remove the packaged defect on this x64 machine. The timing and gate-controlled import path strongly support a server-side rollout exposing a latent native-addon/runtime incompatibility.
Suggested immediate mitigation: disable gate
3207467860for Windows x64 as well as ARM64, or catch the optional service import failure so Codex Micro remains disabled instead of generating a main-process exception storm.I retained both dumps locally but am not attaching them publicly because they may contain process memory or local identifiers. They can be provided through an OpenAI-approved private channel.
_Disclosure: this comment was prepared and posted through Codex at my explicit request._
Same issue here. Insta close on ARM 64 surface laptop!?!?!? HAve anyone found a solution?
I found a workaround that works on my ARM64 machine.
The stable package (
OpenAI.Codex 26.707.9981.0 arm64) still crashes a few seconds after launch, but the Microsoft Store Beta (OpenAI.CodexBeta 26.707.3351.0 arm64) launches and works normally on the same machine.The Beta can be installed alongside the stable version:
https://apps.microsoft.com/detail/9N8CJ4W95TBZ
This does not fix the stable build, but it may help others who are currently blocked.
Great to know.
I have submitted a ticket to Support linking to this GH issue and they have acknowledged the bug and forwarded to the appropriate team.
thanks,i will try!
Independent confirmation from my Snapdragon Windows 11 ARM64 machine.
Please disable the Codex Micro gate for Windows ARM64, or catch the optional device-kit import failure so the main process cannot crash. The workaround is useful, but the shipped ARM64 build still needs a fix.
you can try this mitigation
https://github.com/openai/codex/issues/33381#issuecomment-4985779999
The mitigation can't seem to work, launching the packaged Codex app with
Start-Processis pretty much impossible:if i didn't misread the error message, maybe this can be resolved by simply changing the working directory? e.g.,
cd C:\first. or somewhere else you have read access. also you might wanna double check if you have copied the one-liner completelyI've updated the message; tried with many different options; the profile directory, the System32 directory (MSIX packages use it by default), the
appdirectory inside the package.Does double-clicking
ChatGPT.exefrom the Explorer work for you? Because I get the same:<img width="1116" height="268" alt="Image" src="https://github.com/user-attachments/assets/ce861a91-6f35-47a5-b0e3-079d7ca30806" />
I'm pretty sure Windows protects executables in the MSIX packages.
@junhaoliao Have you installed Codex from Microsoft Store or a loose MSIX installer? (Does it exist?) Have you had Dev Mode enabled on Windows when you installed it?
the mitigation has worked on 2 of my computers. (i once hacked the installation on one computer but the other one is clean.) if double clicking
ChatGPT.exefrom the Explorer doesn't work for you, i suspect your chatgpt app installation is already broken. if anything, consider uninstalling and reinstalling from the microsoft app store? fwiw, your chatgpt sessions / preferences shouldn't be lost from reinstallation cuz they are stored in ~/.codex@Alovchin91
i did it on one of my computers months ago. though after a few auto-upgrades, i'm pretty sure now all installations have been migrated to be managed by the microsoft app store these days
this is interesting... i don't remember enabling Dev mode on both computers
The same issue still persists after updating to 26.707.12708.0 from 26.707.9981.0
That indeed worked, although I don't think it meant that the installation was broken since this happened independently on 2 of my machines 🤔 I wonder now at what point does Windows decide to protect these files? I'll try to investigate, for the posterity.
BTW the workaround works now @junhaoliao , thank you so much!
The same issue is present in ChatGPT Desktop build 26.707.12708.0 as well.
Here's an auto-patcher I wrote to automatically patch Windows store installed ChatGPT (the MSIX/AppContainer sandbox blocks NODE_OPTIONS) while getting around some via a Windows Store Electron packaging "loophole" to patch the problem @junhaoliao identified previously. GitHub https://github.com/jackluo923/chat-gpt-patcher
It is provided for educational purposes only and is not affiliated with or endorsed by OpenAI or Microsoft. Feel free to improve it. You'll need to enable Windows developer mode first, then launch an elevated power shell terminal for execution. I've tested it with multiple Store ChatGPT version on my Asus Zenbook A16 with Qualcomm Snapdragon X2 Elite Extreme so it should fix the crashing problem.
Independent reproduction from Windows 11 Pro ARM64 running in Parallels Desktop on Apple silicon.
OpenAI.Codex_26.707.12708.0_arm64__2p2nqsd0c76g0.@openai/codexCLI and deleted the prior.codexstate. At the time of this crash the CLI was unauthenticated and had no MCP servers configured, so no Revit, pyRevit, or MCP configuration was present.0xC06D007F, but the environment, fresh-install result, and timing match this issue exactly.Happy to provide the minidump privately if it would help diagnosis.
I also have another question: If the GPT team officially fixes this issue but we can’t update the version directly by opening the GUI, how should we go about resolving it? As I understand it, would we use the CLI or another agent?
Also reproduces on a newer build: 26.707.12708.0 (arm64, Store),
Windows 11 build 26200, Snapdragon.
Identical DelayLoadInfo: node.exe / napi_create_function /
GetLastError 127, hmod == ChatGPT.exe load base.
In my case the crash is gated on sign-in: the app is stable indefinitely
on the login screen and dies ~2-3s after sign-in completes — consistent
with the addon load being triggered by a post-login feature flag fetch.
DOWNGRADE NOW. EVERYTHING IS PEACEFUL.
It has been resolved after a temporary downgrade.
(ref: https://github.com/Wangnov/codex-app-mirror/releases/tag/codex-app-26.707.71524)
FYI, 26.707.91948 version has been released since 26.707.72221 and later, but still unresolved.
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 |
0xc06d007fatKernelBase.dll+0xc1ada(RaiseException) ||
szDll|node.exe||
szProcName|napi_module_register||
hmodCur| ChatGPT.exe image base (delay-load hook remappednode.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 (56napi_*+ 4uv_*) fromnode.exe.Export-table diff on disk:
ChatGPT.exeexports 2 symbols total — 0 of the 57 required.chrome.dllin 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'swin_delay_load_hook.Crash-thread stack:
KernelBase!RaiseException ← serialport.node delay-load thunk ← setupapi.dll ← ntdll!LdrpCallInitRoutine ← chrome.dll— i.e., duringserialport.nodeDllMain 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:
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:
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:
10.0.26200OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g026.707.72221c4fb2aba2d54e3428156b9a041794ef5ce25c2850c70cb575b40754ada062116The minidump has the same decoded signature:
0xC06D007F/ERROR_PROC_NOT_FOUNDnode.exenapi_create_function@worklouder,@serialport, andnode.napi.nodeare present in the dumpThe 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 thecua_noderuntime, 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 from9981did 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):
0xC06D007F(VC++ delay-load),dwLastError = 127 ERROR_PROC_NOT_FOUNDnapi_create_functiondelay-loaded fromnode.exenode.exe→ChatGPT.exe(module base matcheshmodCurin theDelayLoadInfo), whose export table contains only 2 exports and no N-API symbolsnode.exeprocess) then the main process dies ~5s inSo 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
ChatGPT.exe / 0xC06D007Freached 368.OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0(file version150.0.7871.115).OpenAI.CodexBetais 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:
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 x64and 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:
ChatGPT.exeprocess exits with0xC06D007F.0x00000000.Current status on this machine:
%USERPROFILE%\.codexwasUpdate:
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. https://github.com/openai/codex/issues/33375#issuecomment-4991172145 we have addressed the issue.