Skip to content

Windows startup crash: bundled @serialport/bindings-cpp delay-loads Node-API from ChatGPT.exe (0xc06d007f, ERROR_PROC_NOT_FOUND) #33525

Open
Open
Windows startup crash: bundled @serialport/bindings-cpp delay-loads Node-API from ChatGPT.exe (0xc06d007f, ERROR_PROC_NOT_FOUND)#33525
Labels
appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@ChungInKwon
ChungInKwon
opened on Jul 16, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.9981.0

What subscription do you have?

ChatGPT Crash error

What platform is your computer?

Windows 11

What issue are you seeing?

Checklist

  • I searched existing issues.
  • I can reproduce the issue consistently.
  • This issue occurs on the latest available desktop version.

Environment

  • OS: Windows 11 24H2 (Build 26200)
  • Application: ChatGPT Desktop / Codex
  • Version: 26.707.9981.0

Summary

The application crashes during startup with:

Exception code: 0xc06d007f

WinDbg indicates this is a delay-load failure caused by a bundled native
module.

Crash analysis

The failing module is:

app.asar.unpacked
 └── node_modules
     └── @worklouder
         └── wl-device-kit
             └── node_modules
                 └── @serialport
                     └── bindings-cpp
                         └── build
                             └── Release
                                 └── serialport.node

The loader attempts to resolve:

napi_module_register

from:

ChatGPT.exe

and fails with:

LastError = 127
ERROR_PROC_NOT_FOUND

leading to:

0xc06d007f

during module initialization.

Root cause

This appears to be a packaging/linking issue.

serialport.node looks like it was built for a standard Node.js runtime,
where Node-API symbols are expected to be exported by the host executable.

However, in the current desktop application:

  • ChatGPT.exe exports only a very small number of symbols
    (e.g. GetHandleVerifier, IsSandboxedProcess).

  • Node/N-API exports are instead provided by chrome.dll.

Other bundled native modules (for example better_sqlite3) load normally
and do not appear to rely on this delay-load mechanism.

serialport.node therefore attempts to resolve
napi_module_register from ChatGPT.exe, receives
ERROR_PROC_NOT_FOUND (127), and crashes before the application finishes
starting.

Things that do NOT appear related

  • Windows 11 Build 26200 is fully supported.
  • Samsung Knox DLLs (LSP4ShellLite64.dll, EpMng64.dll) are injected,
    but the crash stack indicates they are not involved.

Possible workaround

Disconnecting USB serial devices or Work Louder hardware may prevent
wl-device-kit from being loaded, although this depends on whether the
module is loaded lazily.

If the module is always loaded during startup, there is no practical
workaround.

Expected behavior

The desktop application should not crash because of an optional hardware
integration.

Possible fixes include:

  • rebuilding @serialport/bindings-cpp for the desktop runtime,
  • removing the incorrect delay-load dependency,
  • resolving N-API symbols from the correct runtime,
  • or loading the Work Louder integration lazily so startup cannot fail.

Additional information

The crash is reproducible on every launch.

If needed, I can provide:

  • WinDbg stack trace
  • full crash dump
  • PE export analysis of ChatGPT.exe
  • PE export analysis of chrome.dll
  • import table of serialport.node

What steps can reproduce the bug?

Environment

  • OS: Windows 11 24H2 (Build 26200)
  • App: ChatGPT/Codex Desktop
  • Version: 26.707.9981.0

Observed behavior
The application crashes during startup with exception:

0xc06d007f (delay-load failure)

WinDbg analysis shows:

LastError = 127 (ERROR_PROC_NOT_FOUND)

The failing module is:

app.asar.unpacked
@worklouder\wl-device-kit
@serialport\bindings-cpp\build\Release\serialport.node

Root cause

serialport.node appears to have been built expecting standard Node.js
behavior and delay-loads Node-API exports such as:

napi_module_register

However the desktop app hosts Node differently.

ChatGPT.exe exports only a minimal set of symbols, while the Node-API
exports reside in chrome.dll.

Other native modules (for example better_sqlite3) appear to be built
correctly for this architecture and load successfully.

serialport.node instead attempts to resolve Node-API symbols from
ChatGPT.exe, causing ERROR_PROC_NOT_FOUND (127) and resulting in
exception 0xc06d007f during module load.

Additional observations

  • Windows version is fully supported.
  • Samsung Knox DLLs are injected but do not appear to participate in
    the failure.
  • Disconnecting USB serial devices may avoid loading the Work Louder
    device kit, but this is only a possible workaround.

Expected behavior

Either:

  • rebuild serialport.node against the desktop runtime,
  • remove the delay-load dependency on node.exe exports,
  • or ensure the Work Louder device kit is loaded lazily and cannot crash
    application startup.

This appears to be a packaging/linking issue in the bundled native
module rather than an OS compatibility problem.

What is the expected behavior?

No response

Additional information

No response

Activity

  1. ChungInKwon
    added
    appIssues related to the Codex desktop app
    on Jul 16, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    on Jul 16, 2026

  3. github-actions commented on Jul 16, 2026

    @github-actions
    github-actionsbot
    on Jul 16, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. duanra-a16a commented on Jul 16, 2026

    @duanra-a16a
    duanra-a16a
    on Jul 16, 2026 – with ChatGPT Codex Connector

    Update after the Microsoft Store app update: the defect still reproduces in OpenAI.Codex 26.707.12708.0 x64 on Windows build 26200.

    Fresh controlled observation on 2026-07-16:

    1. Started the updated Codex app and initialized the bundled in-app Browser plugin (bundled plugin directory version 26.707.91948).
    2. Browser runtime connection and documentation retrieval completed.
    3. Creating the first controlled in-app Browser tab with iab.tabs.new() immediately terminated/interrupted the Codex session before navigation to https://example.com/ completed.
    4. Windows recorded a fresh Application Error, Event ID 1000 at 10:36:12 Europe/Amsterdam for the updated package:
      • Package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
      • Exception: 0xc06d007f
      • Fault offset: 0x00007ffd9c3a1ada
      • Report ID: cc8273a1-6222-4dbf-b6eb-75cd5a49977c

    The same updated build also produced repeated identical Event 1000 failures before this controlled test (including 10:29:09 and 10:29:21), so the failure is not limited to Browser use. The Browser tab creation is simply a reliable immediate trigger on this affected installation/account.

    The earlier dump analysis remains applicable: ERROR_PROC_NOT_FOUND (127) while loading the bundled Work Louder / SerialPort native addon and resolving node.exe!napi_module_register. Reinstalling the previous signed package was already ruled out by a matching ASAR integrity hash.

    Please keep this issue open for build 26.707.12708.0; the update has not fixed the Windows x64 native-addon failure.

  5. KaelCJ commented on Jul 16, 2026

    @KaelCJ
    KaelCJ
    on Jul 16, 2026 – with ChatGPT Codex Connector

    Additional confirmation from Windows 10, plus a repeatable in-app-browser trigger.

    Environment

    • Codex Desktop AppX: 26.707.9981.0 x64
    • Chromium reported by the app: 150.0.7871.115
    • OS: Windows 10 Pro 10.0.19045 x64
    • Time zone: Asia/Shanghai (UTC+8)

    Native-addon / WER evidence

    By approximately 18:00 local time on 2026-07-16, Windows Application Event Log contained 274 Event ID 1000 entries for this Codex package with:

    Exception code: 0xc06d007f
Application: bad_module_info
Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0

    The first Event ID 1000 appeared at 11:37:33. At 11:37:38, the Codex desktop log recorded:

    A dynamic link library (DLL) initialization routine failed.
...\@worklouder\device-kit-oai\...\@serialport\bindings-cpp\build\Release\serialport.node

    The bundled serialport.node on this installation is 229,376 bytes with SHA-256:

    2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

    This independently supports the ERROR_PROC_NOT_FOUND (127) / native packaging diagnosis in the original report. The high WER count is repeated native exceptions, not 274 confirmed full UI restarts.

    Reliable in-app browser trigger

    Opening the same self-contained local HTML file from a Codex task reproduced a silent desktop restart twice:

    1. 13:35:13: IAB created a right-panel webview for a file:///... URL.
      • dom-ready at 13:35:15
      • a new Codex desktop process/session started at approximately 13:35:32
    2. 17:48:20: IAB created the same right-panel webview again.
      • dom-ready at 17:48:22
      • a new Codex desktop process/session started at approximately 17:48:45

    In both cases, the page reached dom-ready before the desktop session ended. The desktop log also emitted:

    mcp_app_sandbox.attach_unmatched guestWebContentsId=... url=undefined urlProtocol=invalid

    The WER/native-addon failures began before the first HTML attempt, so the HTML is a reliable immediate trigger, not the underlying cause.

    Control test

    The same 49,791-byte HTML file:

    • has no external scripts, images, iframes, fetches, or WebSockets;
    • has no startup timer or loop;
    • loaded successfully in system Microsoft Edge via Playwright;
    • returned status 200, rendered the expected title/content, completed a button interaction, and remained open for the test interval with no page or console errors.

    This isolates the visible exit to the Codex IAB/desktop path rather than the page itself.

    Expected behavior

    1. Optional Work Louder / SerialPort integration should be rebuilt for the desktop runtime or loaded lazily behind explicit opt-in.
    2. A native-addon load failure must be caught and must not repeatedly generate WER exceptions.
    3. An IAB guest failure must remain isolated to the browser guest and must not terminate/restart the full Codex desktop process.

    Possibly related to the IAB silent-exit reports such as #32798 and #33332. Raw desktop logs contain task/thread data, so I have not attached them publicly, but focused redacted excerpts can be provided if needed.

  6. boyadeqin commented on Jul 16, 2026

    @boyadeqin
    boyadeqin
    on Jul 16, 2026

    I can reproduce what appears to be the same crash on Windows.

    Environment:

    • Codex App version: 26.707.12708.0
    • Package: OpenAI.Codex
    • Reinstalling the app did not resolve the issue.

    Observed behavior:

    • Windows Event Viewer repeatedly reports ChatGPT.exe crashes with exception code 0xc06d007f.
    • The Codex desktop log reports:

    Error: A dynamic link library (DLL) initialization routine failed.

    The failing module path also points to:

    @worklouder/wl-device-kit/node_modules/serialport/node_modules/@serialport/bindings-cpp/build/Release/serialport.node

    In my case, the application may open successfully, but ChatGPT.exe child processes repeatedly crash or restart, causing intermittent desktop app crashes rather than failing on every launch.

    This appears to match the same serialport.node / Node-API delay-load problem described in this issue.

  7. Jupiter363 commented on Jul 16, 2026

    @Jupiter363
    Jupiter363
    on Jul 16, 2026

    我找到了一种可能的修复方案，我让codex给我安装了最新的cli版本的codex之后导入当前任务会话，原先codex桌面端的卡顿消失

  8. Nigmat-future commented on Jul 29, 2026

    @Nigmat-future
    Nigmat-future
    on Jul 29, 2026

    Independent Windows event-log confirmation

    I independently observed the same high-frequency 0xc06d007f desktop-app crash signature on a Windows x64 machine.

    Affected package and time window

    • Failing package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
    • Application: ChatGPT.exe (Codex MSIX desktop app)
    • Local time window: 2026-07-15 23:59:52 through 2026-07-16 05:06:46 (UTC+08:00)
    • Windows Application Error, Event ID 1000: 60 distinct crash events
    • Windows Error Reporting, Event ID 1001: 127 entries representing status updates for those crash reports

    Every sampled Event ID 1000 entry had the same values:

    Faulting application: ChatGPT.exe
Faulting package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
Faulting module: unknown
Exception code: 0xc06d007f
WER event type: MoAppCrash
WER P8: c06d007f
WER P9: PCH_84

    Windows created 60 corresponding AppCrash_OpenAI.Codex... report directories. The archived .wer files and dumps are protected by system ACLs on this machine, so I did not change permissions or upload any memory dump. The event-log evidence alone therefore confirms the crash loop but does not independently identify the native module.

    Post-update observation

    The currently installed package is OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0 and its package status is Ok. A fresh check found 0 matching Application Error/WER events for that version. This supports the earlier mitigation/fix, although the observation window is still short.

    There were two recoverable Chromium GPU-child events in the current app logs, but no matching main-process crash; I am treating those as a separate, unconfirmed visual-stability symptom rather than evidence that this issue regressed.

    Scope and routing

    This is an MSIX desktop-app failure, not a Codex CLI configuration issue. I also checked the current openai/codex source at d06c7ac: it contains the Windows desktop-app launcher integration, while the serialport / device-kit-oai packaging surface is not present in this checkout. This issue is the closest open tracker for the observed package-level failure.

    This issue or PR was generated by LazyCodex.
    Tag: lazycodex-generated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions