Skip to content

Windows x64: repeated background crash (0xC06D007F) in serialport.node causes UI freezes during normal use #33518

Closed
Closed
Windows x64: repeated background crash (0xC06D007F) in serialport.node causes UI freezes during normal use#33518
Assignees
shijie-oai
Labels
appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@iiijiashu
iiijiashu
opened on Jul 16, 2026

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

26.707.9981.0 x64

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Environment

  • Windows 11 x64 (build 26200)
  • Codex 26.707.9981.0 x64
  • NVIDIA RTX 4060 Laptop GPU
  • No third-party DLL injectors (no SecureLink, no antivirus hooks)
  • Stable for several weeks before July 15

Behaviour
ChatGPT.exe crashes silently in the background 6+ times per minute
during normal use. Each crash freezes the UI for 2–5 seconds. The app
stays open but becomes intermittently unresponsive — especially when
switching conversations, typing, or clicking UI elements.

Over 24 hours this generated 30+ crash dumps (~12 MB each).

Crash details

  • Exception: 0xC06D007F (delay-load procedure not found)
  • Faulting module: @serialport/bindings-cpp/prebuilds/win32-x64/node.napi.node
  • Load chain: CodexMicroService → @worklouder/device-kit-oai → serialport.node
  • Consistent fault offset across all dumps

What was tried (no improvement)

  • Clean .codex directory, archived 200+ conversations, disabled 9 of 14 plugins
  • Installed latest VC++ 2015–2022 Redistributable (14.44)
  • Disabled GPU acceleration, cleared all caches, reinstalled the app
  • Verified VCRUNTIME140_1.dll present and current

Note
This is related to Issue #33381 (ARM64) but differs in two ways:

  1. On x64 the app does not exit — it background-crashes in a loop
  2. x64 ChatGPT.exe does export napi_* symbols, suggesting a prebuilt
    binary dependency mismatch rather than missing NAPI exports

Could OpenAI either disable the CodexMicro feature flag for affected
x64 builds, or ship a corrected win32-x64 serialport prebuilt binary?

What steps can reproduce the bug?

  1. Open Codex desktop on Windows x64 (build 26.707.9981.0)
  2. Switch between 2-3 conversations, or type a message and wait for the response
  3. The UI will freeze for 2-5 seconds intermittently during normal use
  4. Each freeze corresponds to a silent ChatGPT.exe background crash

The crash occurs without any specific user action — no in-app browser,
no large file operations, no long conversations needed. Simply having
the app open and using it normally triggers the crash repeatedly
(6+ times per minute).

Crash confirmed via Windows CrashDumps at:
%LOCALAPPDATA%\CrashDumps\ChatGPT.exe.*.dmp
Exception: 0xC06D007F
Faulting module: @serialport/bindings-cpp/prebuilds/win32-x64/node.napi.node
Load chain: CodexMicroService → @worklouder/device-kit-oai → serialport.node

The crash occurs even with:

  • A clean .codex directory (no previous sessions or workspaces)
  • All plugins disabled
  • GPU acceleration off
  • VC++ 2015-2022 Redistributable 14.44 installed

What is the expected behavior?

The UI should remain responsive during normal use. Switching
conversations, typing, and clicking UI elements should not cause
multi-second freezes. The app should not silently crash in the
background.

Additional information

  • Started July 15, 2026 — was stable for several weeks before that
  • Over 30 identical crash dumps generated in ~24 hours before
    suppressing LocalDumps for ChatGPT.exe
  • Community posts #1387026 (ARM64) and #1387051 (x64, in-app browser)
    report the same exception code and load chain
  • Related GitHub Issue Windows ARM64 app crash-loops on launch — ChatGPT.exe exports no napi_* symbols, serialport addon dies with delay-load 0xC06D007F #33381 tracks the ARM64 variant
  • Not caused by SecureLink or other third-party DLL injectors
    (none installed)
  • The x64 ChatGPT.exe binary does export napi_* symbols (unlike the
    ARM64 build), so the root cause on x64 is likely a prebuilt binary
    dependency mismatch rather than missing NAPI exports

Activity

  1. iiijiashu
    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. mazhihao007 commented on Jul 16, 2026

    @mazhihao007
    mazhihao007
    on Jul 16, 2026

    同样的问题

  5. mazhihao007 commented on Jul 16, 2026

    @mazhihao007
    mazhihao007
    on Jul 16, 2026

    Subject: Codex 26.707.9981.0 repeatedly crashes in serialport.node

    The Codex Windows desktop app repeatedly becomes unresponsive and crashes every 20–60 seconds. The window may recover automatically because the failed process is restarted.

    Affected Codex build

    • Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
    • Codex version: 26.707.9981.0
    • ChatGPT.exe version: 150.0.7871.115

    Reproduction environments

    1. Windows 11 Insider Preview, build 26300
    2. Windows 11 Pro 25H2, build 26200.8875 (fresh virtual machine)

    The issue reproduces on both systems with the same Codex package.

    Observed behavior

    • Repeated Event ID 1000 and 1001 entries
    • Exception code: 0xc06d007f
    • The UI can recover after an auxiliary ChatGPT.exe process is replaced
    • Resetting and reinstalling Codex does not resolve the issue
    • Restarting Windows does not resolve the issue
    • Removing the VS Code Codex extension does not resolve the issue

    Native module comparison

    • Module: @serialport/bindings-cpp/build/Release/serialport.node
    • Dependency chain:
      @worklouder/device-kit-oai
      -> @worklouder/wl-device-kit
      -> serialport
      -> @serialport/bindings-cpp
    • Size: 229376 bytes
    • SHA-256: 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006
    • The SHA-256 is identical on both machines.

    WinDbg result

    • Failure bucket: APPLICATION_FAULT_c06d007f_serialport.node!Unknown
    • Faulting native module: serialport.node
    • The crash occurs during serialport.node initialization through LoadLibraryExW.

    The DelayLoadInfo structure identifies the exact failed import:

    • DLL: node.exe
    • Procedure: napi_module_register
    • LastError: ERROR_PROC_NOT_FOUND (0x7f)
    • Outer exception: 0xc06d007f

    PE export/import verification

    • serialport.node delay-imports napi_module_register from node.exe.
    • During the crash, the resolved module handle points to ChatGPT.exe.
    • ChatGPT.exe does not export napi_module_register.
    • The bundled chrome.dll does export napi_module_register.
    • chrome.dll contains all 57 Node-API/LibUV symbols required by serialport.node.

    Assessment
    This strongly indicates an Electron/Node delay-load redirection or native-module packaging regression in Codex 26.707.9981.0. It does not appear to be caused by a damaged installation, VS Code extension, VC++ Runtime, UCRT, or a single Windows Insider build because the same binary and failure reproduce on two Windows builds.

    Please investigate the bundled @worklouder device-kit / serialport.node integration and the mapping of node.exe delay imports to the Electron runtime.

    Failure hash from WinDbg:
    {4927e390-5f61-4b71-57ae-af5d5edb1937}

    A full memory dump exists locally, but it has not been attached because it may contain session or account data. A sanitized WinDbg excerpt can be provided if required.

  6. gengyubo commented on Jul 16, 2026

    @gengyubo
    gengyubo
    on Jul 16, 2026

    i have the same problem

  7. Jupiter363 commented on Jul 16, 2026

    @Jupiter363
    Jupiter363
    on Jul 16, 2026

    I have the same problem, it's almost unusable now and really needs to be fixed!!!!!!!!!!!!!!!!!!!!

  8. chenyinqingfeng commented on Jul 16, 2026

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

    I can independently reproduce and locally verify the same failure on another x64 machine.

    Environment:

    • Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
    • ChatGPT.exe product version: 150.0.7871.115
    • Windows 11 25H2, build 26200.8655, x64
    • VC++ runtime: 14.51.36247, x64

    Reproduction and impact:

    1. Send a message and wait for the response, or let a Codex task finish.
    2. Windows records repeated Application Error Event ID 1000 entries for the still-running ChatGPT.exe process.
    3. Every sampled failure has exception 0xc06d007f, faulting module unknown, and WER event type MoAppCrash.
    4. In one 30-minute window I recorded 27 Event ID 1000 crashes and 55 WER Event ID 1001 records.
    5. WER repeatedly creates memory.hdmp; Windows Error Reporting becomes the dominant disk writer and can drive the NVMe SSD to 100% active time.

    A complete uninstall, Windows restart, and clean reinstall did not help because the same 26.707.9981.0 build was installed again.

    I also verified the native-module chain in the installed package:

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

    Using Visual Studio dumpbin on the locally installed binaries:

    serialport.node delay-load target: node.exe
failed/required procedure: napi_module_register

ChatGPT.exe exports napi_module_register: NO
chrome.dll exports napi_module_register: YES

    This independently confirms the same Electron/Node delay-load redirection or native-module packaging regression described above. It is not resolved by repairing or reinstalling the app, and it is not caused by missing VC++ runtime files.

    As a temporary mitigation only, I disabled Windows Error Reporting for the current user to stop the repeated full-memory dumps from saturating the SSD. The underlying serialport.node initialization failure remains and needs an app update (for example, a corrected serialport prebuild/mapping or disabling the affected CodexMicro device-kit path).

  9. sharkdingo commented on Jul 16, 2026

    @sharkdingo
    sharkdingo
    on Jul 16, 2026

    Independent reproduction on Windows x64, with a minidump captured during an actual UI hang.

    Environment

    • Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
    • ChatGPT/Chromium product version: 150.0.7871.115
    • Windows 11 25H2, build 26200.8875, x64
    • 15.78 GB RAM; about 4-5 GB remained available during reproduction

    Observed behavior

    • During ordinary task use, the visible app became Responding=False for about 10 seconds and then recovered.
    • Windows recorded Application Error event ID 1000 at the same time.
    • Exception code: 0xc06d007f
    • Faulting module shown by Event Viewer: unknown

    I temporarily enabled WER LocalDumps and captured the matching minidump. LLDB showed:

    KERNELBASE!RaiseException
serialport.node
chrome.dll!uv_dlopen

    The delay-load exception information identified the exact failed lookup:

    szDll       = node.exe
szProcName  = napi_module_register
dwLastError = 127 (ERROR_PROC_NOT_FOUND)

    The native addon is bundled under:

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

    PE import/export verification on the installed package:

    • serialport.node requires 57 Node/N-API/uv symbols.
    • ChatGPT.exe exports only 2 symbols and provides 0 of those 57.
    • Bundled chrome.dll provides all 57 required symbols.

    This supports an Electron win_delay_load_hook / native-addon packaging regression rather than an out-of-memory condition.

    Also ruled out locally:

    • CPU and disk were lightly loaded during the hang.
    • Nahimic processes/tasks were stopped, Windows was restarted, and the injected Nahimic DLLs were absent; the failure still reproduced.
    • Microsoft Store repair/restart did not resolve it.

    I am not attaching the raw dump or session logs because they may contain account/session data, but I can provide a sanitized debugger excerpt if maintainers need it.

  10. jaikensai888 commented on Jul 16, 2026

    @jaikensai888
    jaikensai888
    on Jul 16, 2026

    same problem

  11. likebeta commented on Jul 16, 2026

    @likebeta
    likebeta
    on Jul 16, 2026

    same problem

  12. lihongwei1024 commented on Jul 16, 2026

    @lihongwei1024
    lihongwei1024
    on Jul 16, 2026

    WinDows11 Microsoft Windows版本 25H2(OS 内部版本 26200.8875) 同样的问题

  13. Naetmul commented on Jul 16, 2026

    @Naetmul
    Naetmul
    on Jul 16, 2026

    Here is my case with workaround by Codex.

    Environment

    • Windows 11 25H2 x64, build 26200.8875
    • Executable: ChatGPT.exe (150.0.7871.115)
    • Affected packages:
      • OpenAI.Codex 26.707.9981.0 x64
      • OpenAI.Codex 26.707.12708.0 x64
    • Windows Application event: Event ID 1000
    • Exception code: 0xC06D007F

    Symptoms and frequency

    One or more child ChatGPT.exe processes can repeatedly crash while other processes remain alive, producing a large number of Windows Error Reporting events.

    Package versions were correlated with the package transition time:

    Package version Count First crash (UTC) Last crash (UTC) Active-period frequency
    26.707.9981.0 613 2026-07-15 15:51:27 2026-07-16 07:25:52 About once every 36.5 seconds
    26.707.12708.0 26 2026-07-16 07:26:18 2026-07-16 07:50:52 About once every 59 seconds

    Gaps longer than ten minutes were excluded from the active-period frequency. The first local crash at 2026-07-15 15:51:27 UTC closely matches the reported rollout onset. The newer package started producing the same exception immediately, so it does not appear to contain a fix.

    Root cause in plain language

    This does not look like a missing save directory or a damaged user profile. It looks like a binary compatibility mismatch between a native component bundled with the app and the executable loading it.

    The likely sequence is:

    1. A server-controlled rollout enables the optional Codex Micro/Work Louder device integration.
    2. The app tries to load serialport.node, the native component used for serial-port communication.
    3. That component expects 53 Node N-API functions, including napi_create_function and napi_module_register, to be available from its host.
    4. The packaged ChatGPT.exe does not export those functions. Its observable exports are only GetHandleVerifier and IsSandboxedProcess.
    5. The Windows loader cannot resolve the required functions. This produces ERROR_PROC_NOT_FOUND (127), surfaced as the VC++ delay-load exception 0xC06D007F.
    6. The app restarts the failed child process or retries the same initialization, creating the repeated crash loop.

    In simple terms, the bundled native component uses a plug that the host executable does not provide. The file exists, but Windows cannot connect the functions it requires.

    The binary mismatch is directly observable. Activation by the rollout is an inference supported by the matching onset time and by the result of suppressing only the affected optional integration. Developer symbols or a loader stack trace would be needed for final confirmation.

    Binary evidence

    The updated ChatGPT.exe still exports only:

    GetHandleVerifier
IsSandboxedProcess

    It has no napi_* or node_api_* exports. The bundled x64 module follows this dependency path:

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

    The bundled serialport.node imports 53 N-API functions from node.exe, including napi_create_function and napi_module_register.

    ChatGPT.exe SHA-256:
28C3E8B6C55FFF39ECB12A5EB27F493ABF997804247517AA7A46C277CA5D9E93

serialport.node SHA-256:
2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

    How another user can check whether it is the same problem

    Check the crash signature before applying the mitigation. It is a strong match when all of the following are present:

    • Repeated Event ID 1000 failures for ChatGPT.exe.
    • Exception code 0xC06D007F.
    • An affected x64 OpenAI.Codex package.
    • The app remains open while child processes keep crashing, often causing lag or short freezes.
    • ChatGPT.exe has no N-API exports.
    • The bundled serialport.node imports N-API functions from node.exe.

    If the exception, executable, or import/export mismatch differs, it should be investigated as a separate problem rather than applying this mitigation automatically.

    Workaround using Codex

    This is an unofficial, reversible mitigation. It disables only the optional Codex Micro/Work Louder hardware integration; it should not modify the signed WindowsApps package or user data.

    Give Codex this single prompt:

    Determine whether this is the same Windows x64 crash as GitHub issue #33518.
Use #33381 only as the technical reference for the N-API/serialport root cause.

Phase 1 — Verify without making changes

1. Read Windows Application Event ID 1000 entries for ChatGPT.exe.
2. Identify the Windows version and installed OpenAI.Codex package version.
3. Report in UTC:
   - exception code;
   - first and last crash times;
   - crash count;
   - active-period frequency, excluding gaps longer than ten minutes.
4. Confirm that ChatGPT.exe was running during the measured period.
5. Inspect the packaged x64 binaries and verify both conditions:
   - ChatGPT.exe has no napi_* or node_api_* exports;
   - serialport.node imports napi_create_function and napi_module_register
     from node.exe.

Proceed only if the repeated ChatGPT.exe crashes use 0xC06D007F and the
N-API import/export mismatch is confirmed. Otherwise, stop and report which
condition did not match. If it matches, summarize the evidence and ask me
before creating any files.

Phase 2 — Create the workaround after approval

1. Create the files in the current Codex workspace.
2. Create a CommonJS preload hook that intercepts only
   @worklouder/device-kit-oai and returns the minimal no-op API required by
   the app, preventing serialport.node from loading.
3. Create a PowerShell launcher that:
   - refuses to run while any ChatGPT.exe process exists;
   - discovers the installed OpenAI.Codex package and AUMID from its manifest;
   - temporarily prepends the hook through NODE_OPTIONS;
   - launches the AppX entry through shell:AppsFolder;
   - restores the previous user-scope and session-scope NODE_OPTIONS values
     in a finally block.
4. Do not modify WindowsApps, the package manifest, or application data.
5. Validate the JavaScript and PowerShell syntax and show the generated files
   before execution.

Phase 3 — Verify after I approve execution

1. Record the Event ID 1000 count immediately before launch.
2. Launch the app with the generated workaround.
3. Confirm that ChatGPT.exe remains running.
4. Compare the new crash count with the earlier active-period frequency.
5. Report the observation duration, expected crashes at the previous rate,
   actual crashes, and latest crash time in UTC.

    Before running the generated launcher, completely exit Codex and confirm that no ChatGPT.exe processes remain. Review the generated files before execution. The launcher must preserve any existing NODE_OPTIONS value and restore it even if startup fails.

    Rollback consists of closing Codex, restoring the recorded previous NODE_OPTIONS values if necessary, and deleting the generated hook and launcher. The workaround should be removed after an official fixed package is installed.

    Verification on this system

    • Mitigated process launch: 2026-07-16 07:52:09 UTC
    • Latest check: 2026-07-16 09:40:51 UTC
    • Continuous runtime at check: about 108.7 minutes
    • Running ChatGPT.exe processes: 9
    • Crashes after the mitigated launch: 0
    • Latest crash remained: 2026-07-16 07:50:52 UTC

    At the previous rate for 26.707.12708.0, approximately 110 crashes would have been expected during that runtime. None occurred. This shows that the crash loop stopped while the mitigation was active, but it does not show that the unchanged package itself was fixed.

    Limitation

    Codex Micro/Work Louder hardware integration is unavailable for that launch. A permanent fix requires the optional integration to be loaded safely or the native module and host exports to be packaged with compatible ABI expectations.

  14. molijeur-blip commented on Jul 16, 2026

    @molijeur-blip
    molijeur-blip
    on Jul 16, 2026 – with ChatGPT Codex Connector

    Independent x64 reproduction confirming this issue.

    Environment:

    • Windows 11 x64, 16 GB RAM (WER reports build family 26100/26200)
    • Microsoft Store package OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
    • The same app version was installed before and after the regression; the machine was reportedly responsive the previous day.

    Observed behavior:

    • Severe intermittent composer/UI freezes during ordinary Codex use.
    • Windows Application Error event 1000 repeatedly records ChatGPT.exe with exception 0xc06d007f.
    • WER classification: MoAppCrash, fault module StackHash_0000, P9 PCH_84, bucket fe840c3ed30ba850ddeac7488b0e9f2e.
    • The archived WER report identifies OriginalFilename=chrome.exe and IsFatal=1.
    • 95 matching crash events were recorded before Windows Repair. Repair did not help.
    • After a complete uninstall/reinstall, the newly started process generated 8 more identical crashes within approximately four minutes.
    • Current process memory usage was modest and no obvious third-party injected module was found in the readable module list.
    • Persistent HTTP/HTTPS/ALL_PROXY user environment variables were empty, so this crash loop is separate from network/proxy instability.

    The unchanged client version plus the sudden onset is consistent with the server-side/feature-flag explanation in this issue. Reinstalling the same Store build does not resolve it.

    Please consider disabling the CodexMicro/device integration flag for affected Windows x64 clients until a compatible serialport.node/Electron native dependency is shipped.

  15. ShawnLyu commented on Jul 16, 2026

    @ShawnLyu
    ShawnLyu
    on Jul 16, 2026

    “https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86”—this method solves the problem!

  16. dougm1966 commented on Jul 16, 2026

    @dougm1966
    dougm1966
    on Jul 16, 2026

    Additional x64 confirmation on 26.707.12708.0: exact node.exe!napi_module_register delay-load failure

    I am seeing the same severe Windows x64 UI-freeze/crash pattern on the newer Store build OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0.

    The important additional finding is that a minidump and an on-disk PE export-table check identify the exact unresolved import. On this x64 build, the signed ChatGPT.exe has only 2 named exports and does not export napi_module_register. This aligns with the host-export failure described for ARM64 in #33381, and differs from the assumption in this issue that x64 ChatGPT.exe has a normal N-API export surface.

    Environment

    • Windows 11 Pro for Workstations, x64, build 26200
    • Current app package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
    • Previous package 26.707.9981.0 produced the same 0xC06D007F signature before the Store update
    • Executable: app\ChatGPT.exe
    • No Work Louder or serial device connected; only a mouse is attached
    • The ChatGPT web app in Chrome remains stable

    User-visible behavior

    • The desktop app becomes unresponsive on essentially every click, including opening Settings.
    • The stall can make the rest of the Windows UI feel frozen or severely delayed.
    • Event Viewer records Application Hang/crash activity, including repeated ChatGPT.exe Event ID 1000/1001 reports.
    • Reinstalling the Store app and clearing the ordinary ChatGPT application-data/cache locations did not resolve it.

    Repeated Windows crash signature

    Across both 26.707.9981.0 and 26.707.12708.0:

    Exception code: 0xc06d007f
Fault offset:   0x00007ffa428b1ada
WER event:      MoAppCrash
WER P8:         c06d007f

    Ten local minidumps were captured in approximately three minutes:

    Dump count: 10
Total size: 109.58 MB
Oldest: 2026-07-16 01:30:53
Newest: 2026-07-16 01:33:48

    Minidump DelayLoadInfo result

    A read-only parser decoded exception parameter 0 from a real ChatGPT.exe minidump:

    EXCEPTION_CODE=0xC06D007F
LAST_ERROR=0x0000007F (127 / ERROR_PROC_NOT_FOUND)
IMPORT_BY_NAME=1
CURRENT_HMODULE=ChatGPT.exe
CURRENT_PROCEDURE=0x0

    Both the delay-import descriptor and the unresolved function-pointer slot belong to:

    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\
build\Release\serialport.node

    This establishes the importing module as the packaged serialport.node native addon.

    Exact DLL and missing procedure recovered from the packaged PE image

    Using the dump-recorded virtual addresses and the exact installed serialport.node, a read-only PE parser recovered:

    TARGET_DLL_NAME=node.exe
REQUESTED_PROCEDURE=napi_module_register

    The same parser inspected the exact installed ChatGPT.exe export table:

    CHATGPT_EXPORT_COUNT=2
REQUESTED_EXPORT_PRESENT_EXACT_CASE=False
REQUESTED_EXPORT_PRESENT_CASE_INSENSITIVE=False
SIMILAR_CHATGPT_EXPORTS=<none>

    Binary identifiers:

    serialport.node
  Size:   229376 bytes
  SHA256: 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

ChatGPT.exe
  Size:   4070400 bytes
  SHA256: 28C3E8B6C55FFF39ECB12A5EB27F493ABF997804247517AA7A46C277CA5D9E93

    Resulting failure path

    serialport.node
  -> delay-loads node.exe!napi_module_register
  -> node.exe is redirected to the Electron host ChatGPT.exe
  -> ChatGPT.exe does not export napi_module_register
  -> GetProcAddress returns ERROR_PROC_NOT_FOUND (127)
  -> VC++ delay-load helper raises 0xC06D007F

    Evidence against the earlier WebView2/GPU hypotheses

    • The package contains bundled Chromium/Electron artifacts (app.asar, chrome_elf.dll, resources.pak, V8 snapshots).
    • Every observed msedgewebview2.exe process identified its host as Windows Widgets or SearchHost, not ChatGPT.
    • The same diagnostic window contained no matching Display, WHEA, DxgKrnl, GPU-timeout, or Kernel-Power event.
    • The error occurs without a serial device connected and before serial-device I/O would be relevant.

    Requested maintainer action

    Could the team please verify the x64 26.707.12708.0 package against the hashes above and determine why its ChatGPT.exe export directory contains only two named exports?

    Potential mitigations/fixes:

    1. Disable or gate the @worklouder/device-kit-oai / serialport integration on affected Windows builds.
    2. Do not load the optional device integration when the host lacks the required N-API exports.
    3. Ship ChatGPT.exe with the required Node-API export list, or rebuild/package serialport.node for the exact Electron host/runtime.
    4. Catch the native-addon load failure so an optional integration cannot repeatedly stall the entire desktop UI.

    I will not upload the raw process dump publicly because it can contain private process memory. Sanitized parser output and the read-only PowerShell parsers can be provided, and a dump can be shared privately with maintainers if there is a secure channel.

  17. dougm1966 commented on Jul 16, 2026

    @dougm1966
    dougm1966
    on Jul 16, 2026

    “[https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86”—this](https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86%E2%80%9D%E2%80%94 this) method solves the problem!

    Is a 404

    This is correct:
    https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86

  18. dougm1966 commented on Jul 16, 2026

    @dougm1966
    dougm1966
    on Jul 16, 2026

    “[https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86”—this](https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86%E2%80%9D%E2%80%94 this) method solves the problem!

    Is a 404

    This is correct: https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86

    My preliminary findings from GPT 5.6 Pro reasoning:

    Is this a legit fix? That you didn't find?
    triesmon/bdc20a18ec34108e2608c1294c451f86
    Worked for 1m 44s

    Yes. It is a technically legitimate, targeted workaround—and I should have found and evaluated it earlier.

    It directly matches what your dump proved. The launcher pauses ChatGPT/Codex before its JavaScript starts, intercepts only:

    @worklouder/device-kit-oai

    and substitutes a no-device stub. That prevents the dependency chain from reaching the incompatible serialport.node that requests node.exe!napi_module_register. It then resumes the app and closes the local debugger connection. It does not modify the signed WindowsApps package, registry, conversations, or application data.

    It is more accurately described as a workaround, not a permanent fix. It avoids loading the broken component; it does not rebuild serialport.node or correct the missing export in ChatGPT.exe. A separate user reports that after using it, the freezes stopped and no new 0xC06D007F or MoAppCrash events appeared.

    There are important # of cautions: The reason for sharing this

    The author tested it on 26.707.9981.0; your installed version is 26.707.12708.0.
    It relies on undocumented application internals.
    It briefly enables a Node inspector on a random 127.0.0.1 port. That is local-only and short-lived, but still creates a temporary code-injection interface.
    GitHub flags the files as containing hidden or bidirectional Unicode characters.
    The current script does not appear to pin itself to a specific Codex version, despite the accompanying recommendation to do so.
    On injection failure, the current JavaScript records an error, but it does not clearly terminate the newly launched process in every failure path.

    The rendered source shows no obvious credential theft, external upload, registry modification, or destructive file operations. Its network activity is directed at the local inspector. Nevertheless, because of the hidden-character warning and mutable Gist, I would not run the original files blindly.

    Verdict
    Matches your diagnosed defect: Yes.
    Credible workaround: Yes.
    Official or permanent fix: No.
    Safe enough to run unchanged: Not quite.
    Did I miss it earlier: Yes.

    The correct implementation for your machine is a hardened copy pinned to OpenAI.Codex_26.707.12708.0_x64, with exact file hashes, rejection of hidden bidirectional controls, localhost-only inspector validation, and fail-closed process termination. The underlying vendor fix still needs to come from OpenAI.

  19. fromiron commented on Jul 16, 2026

    @fromiron
    fromiron
    on Jul 16, 2026

    I have the exact same issue with a similar setup

  20. shijie-oai commented on Jul 16, 2026

    @shijie-oai
    shijie-oai
    on Jul 16, 2026
    Contributor

    Hi all - thanks a lot for the reports and we have disabled the feature for windows at the moment. The config itself might take some time to propagate and would definitely recommend a restart before it takes effect. Please let us know if you are still seeing the issue persistently after restarting in the next couple hours. We are also preparing a proper fix and it is currently in the pipeline.

  21. iiijiashu commented on Jul 16, 2026

    @iiijiashu
    iiijiashu
    on Jul 16, 2026
    Author

    “https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86”—this method solves the problem!

    It works！Thank you

  22. shijie-oai
    self-assigned this
    on Jul 16, 2026

  23. Lesterffx commented on Jul 16, 2026

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

    Additional data point from Windows x64 after updating to 26.707.12708.0

    I can confirm the same 0xc06d007f / MoAppCrash signature on this Windows x64 machine before the Store update, and I am now monitoring the newer build after restarting Windows and the ChatGPT/Codex desktop app.

    Environment

    • OS: Microsoft Windows NT 10.0.26200.0, x64
    • Current Codex package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
    • Current Codex version: 26.707.12708.0
    • Previous failing package observed in Event Viewer: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
    • PowerShell present on the machine: 7.6.3

    Confirmed local crash evidence before the update

    Windows Event Viewer recorded repeated Application Error / Windows Error Reporting entries for ChatGPT.exe on 2026-07-16.

    Representative local evidence:

    Application Error / Event ID 1000
Faulting application: ChatGPT.exe
Faulting package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
Exception code: 0xc06d007f
Faulting module: unknown
WER event type: MoAppCrash

    The same signature appeared repeatedly between approximately 13:45 and 14:25 local time. Local CrashDumps were also created for ChatGPT.exe, for example:

    ChatGPT.exe.23960.dmp       2026-07-16 14:08:07   ~23.8 MB
ChatGPT.exe(1).23960.dmp    2026-07-16 14:24:57   ~24.0 MB
ChatGPT.exe(2).23960.dmp    2026-07-16 14:24:59   ~24.1 MB
ChatGPT.exe(3).23960.dmp    2026-07-16 14:25:29   ~24.1 MB

    Post-update state

    After Windows installed OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0 at about 20:26 local time, I restarted Windows and restarted the ChatGPT/Codex app multiple times. Running as administrator did not appear to be a useful mitigation.

    As of a local baseline check at 2026-07-16 22:10:39 +08:00:

    • Current installed version is 26.707.12708.0.
    • ChatGPT.exe processes are running from the 26.707.12708.0 package path.
    • No new matching Application Error / WER 0xc06d007f entries were found after the 20:26 update baseline.
    • No new matching local ChatGPT.exe CrashDumps were found after that baseline.

    The user-visible issue I am still trying to capture is a whole desktop-app exit during normal Codex use after the update/restarts. If it reproduces again, I will collect whether the newer 26.707.12708.0 build produces a fresh WER event, CrashDump, or Crashpad report.

    Notes

    • This does not look related to PowerShell 7. The confirmed crashes are ChatGPT.exe desktop-app crashes, not pwsh.exe crashes.
    • I am not attaching .dmp files publicly because they may contain account/session/process-memory data. I can provide sanitized event details or share dumps privately if OpenAI maintainers have a secure channel.

  24. tanxiao1990 commented on Jul 16, 2026

    @tanxiao1990
    tanxiao1990
    on Jul 16, 2026

    the same problem‌

  25. shijie-oai
    closed this as completedon Jul 17, 2026

  26. shijie-oai commented on Jul 17, 2026

    @shijie-oai
    shijie-oai
    on Jul 17, 2026
    Contributor

    Thanks for all the feedback - we have address the issue #33375 (comment).

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

Metadata

Metadata

Assignees

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