ARM64 Windows: desktop app crashes ~16s after every launch - Codex Micro serialport addon delay-load failure (0xC06D007F)

ARM64 Windows: ChatGPT desktop crashes ~16s after every launch — Codex Micro serialport addon delay-load failure (0xC06D007F)

Summary

On ARM64 Windows, the ChatGPT desktop app's main (browser) process dies ~16 seconds after every launch. The window appears, then vanishes. It is 100% reproducible.

The cause is the bundled Work Louder / Codex Micro serialport native addon. It delay-imports napi_create_function from node.exe, which node-gyp's delay-load hook resolves to the host executable (ChatGPT.exe). ChatGPT.exe exports no N-API symbols — they live in chrome.dll. The lookup fails, the Visual C++ delay-loader raises 0xC06D007F, and because it's an SEH exception at dlopen time, the app's JS try/catch cannot catch it. The process dies.

Impact

Any ARM64 Windows user with Codex Micro enabled cannot open the app at all. First crash on this machine: 2026-07-15 ~11:52 ET, with no local change — consistent with a server-side rollout of the Codex Micro feature. The app was working normally before that.

Environment

| | |
|---|---|
| App | ChatGPT desktop (OpenAI.Codex) 26.707.9981.0, arm64, MSIX |
| ChatGPT.exe | 150.0.7871.115, built 2026-07-07 |
| Client version (logs) | 26.707.72221 |
| OS | Windows 11 build 26220, ARM64 (Surface Pro X / Snapdragon, 8 cores) |
| Serial devices | 6 COM ports present (4x Surface UART, 2x Bluetooth SPP) |

Root cause

Decoded DelayLoadInfo from the Crashpad minidump:

exception code : 0xC06D007F     = VcppException(ERROR_SEVERITY_ERROR, ERROR_PROC_NOT_FOUND)
szDll          : "node.exe"
szProcName     : "napi_create_function"
fImportByName  : 1
hmodCur        : 0x7FF658A80000  -> ...\OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0\app\ChatGPT.exe
pfnCur         : 0x0
dwLastError    : 127             (ERROR_PROC_NOT_FOUND)
ptype          : browser         (main process -> whole app dies)

The szDll / szProcName strings live in the .rdata of:

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

Export tables confirm the mismatch:

| Binary | Total exports | N-API exports | napi_create_function? |
|---|---|---|---|
| ChatGPT.exe | 2 | 0 | NO |
| chrome.dll | 3174 | 158 | YES |
| chrome_elf.dll | 27 | 0 | NO |

node-gyp's stock win_delay_load_hook.cc intercepts the node.exe load and returns GetModuleHandle(NULL) — the host exe. In standard Electron that exe exports the N-API symbols. In this Chromium-shell architecture they're in chrome.dll, so the hook resolves to a module that cannot satisfy the import.

The first-party addons are built correctly and load fine — better_sqlite3.node, windows-account.node, windows-updater.node are all loaded in the same process at crash time. Only the vendored third-party prebuild is wrong. win32-arm64 is the only prebuild shipped, so there is no fallback.

Trigger path

renderer -> IPC -> CodexMicroHostService.getState()
  -> eS.getService()
     -> require('./codex-micro-service-CR6sUcZG.js')
        -> top-level: createRequire(__filename)('@worklouder/device-kit-oai')
           -> @worklouder/wl-device-kit -> serialport -> @serialport/bindings-cpp
              -> LoadLibrary(prebuilds/win32-arm64/node.napi.node)
                 -> delay-load napi_create_function from ChatGPT.exe -> NULL -> 0xC06D007F -> fatal

The try/catch around discovery.findWLDevices([DeviceType.Project2077]) cannot help — the crash happens earlier, during require, and is a native SEH exception.

Reproduction

1. ARM64 Windows 11, ChatGPT desktop 26.707.9981.0, Codex Micro enabled.
2. Launch the app.
3. ~16s later the main process dies; a Crashpad dump lands in

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports.

Observed 3/3 launches, identical signature each time (dumps at 15:21:44, 15:36:45, 16:00:05).

Suggested fix

1. Rebuild/relink the @serialport/bindings-cpp win32-arm64 prebuild against the host that actually exports the N-API symbols (chrome.dll), matching how the first-party addons are built — e.g. a custom delay-load hook returning GetModuleHandle("chrome.dll") instead of GetModuleHandle(NULL).
2. node-hid's HID.node sits in the same @worklouder tree and is very likely to hit the identical failure once serialport is fixed — please check it too.
3. Defensive: wrap the codex-micro-service require so a failure degrades the feature instead of killing the main process. (Note: an SEH delay-load failure is not catchable from JS — the real fix must be #1.)
4. Short term: consider gating the Codex Micro rollout off for ARM64 Windows until the addon is rebuilt. This unblocks affected users immediately.

Note

There is no user-side workaround. The broken file is inside the signed MSIX package, and Windows blocks modification even for an elevated Administrator that has taken ownership.