[Windows App] Repeated serialport.node delay-load failures cause severe UI lag

I can independently reproduce this on Windows 10 x64, and I captured a first-chance full-memory dump plus WPR/ETW traces.

Feedback ID: 019f666d-87fd-7e32-8e36-46d0448437e0

Environment

• Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• OS: Microsoft Windows NT 10.0.19044.0 x64
• No Work Louder/Codex Micro device connected or enabled

Direct dump evidence

ProcDump was attached to the main ChatGPT.exe process with:

procdump64.exe -accepteula -ma -n 1 -e 1 -f c06d007f <PID> <dump-directory>

The captured exception's valid Visual C++ DelayLoadInfo resolves to:

ExceptionCode=0xC06D007F
ExceptionAddress=KernelBase.dll+0x25369
DllName=node.exe
ProcedureName=napi_module_register
CurrentProcedure=0x0000000000000000
LastError=127 (ERROR_PROC_NOT_FOUND)
ImageDelayDescriptor=serialport.node+0x346C4
IatSlot=serialport.node+0x36CE8

The descriptor and IAT slot are both inside the bundled @serialport/bindings-cpp/build/Release/serialport.node under the Work Louder device-kit dependency chain. The binary SHA256 is:

2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

This directly confirms the missing node.exe!napi_module_register delay-load target rather than relying only on the generic WER bad_module_info label.

Measured UI impact

During a roughly two-minute clean run after restarting Codex (PID 25996):

• 13 genuine main-window SendMessageTimeout(WM_NULL) failures occurred with Win32 error 1460, lasting approximately 150.6–163.0 ms.
• 9 separate Application Error events reported 0xC06D007F for the same process.
• 7 UI timeouts occurred within approximately 1.2 seconds of a native exception event.
• The process remained alive and recovered, which explains the repeated short freezes instead of a conventional long hang/crash.

IME control experiment

I fully disabled Sogou IME, enabled Microsoft Pinyin, verified no Sogou processes were running, restarted Codex, and repeated the capture. The same 9 native exceptions and 13 UI timeouts reproduced. ETL image-load analysis found no Sogou module in the clean trace windows. Sogou IME is therefore not required to trigger this defect.

Additional clue

The dump reported the host module path under package 26.707.9564.0 while the failing serialport.node path was under 26.707.9981.0. The live process later reported the current 9981 executable and only that package remained installed. This may be stale dump path metadata, an update-transition artifact, or cross-version resource loading; the updater/package activation path may be worth checking.

I can provide the approximately 1 GB full dump, WPR/ETW traces, UI probe samples, WER exports, and parser output through a private upload channel. I am not attaching dump/ETL files publicly because they may contain user data.

This is a P1 / High severity candidate for the Windows client because it affects the primary typing path repeatedly under a normal installation and has no reliable workaround. If internal telemetry shows the signature is widespread, P0 escalation would be reasonable.

Same issue.

Summary
The Codex Windows desktop app repeatedly crashes shortly after launch after updating from 26.707.3748.0 to 26.707.9981.0.

Crash dump analysis points to an incompatible native serialport.node dependency bundled under @worklouder/device-kit-oai.

Environment
OS: Windows 10 Education x64
Windows version: 10.0.19045
Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
Bundled Codex app-server: 0.144.2
Installation source: Microsoft Store
Previous working version: 26.707.3748.0
The package manifest requires Windows 10.0.19041.0, so the installed OS satisfies the stated minimum version.

Observed behavior
The app opens, runs for several seconds, and then closes. Windows Event Viewer records repeated crashes with:

Exception code: 0xc06d007f
Faulting application: bad_module_info
Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
The Codex desktop log also reports:

[desktop-notifications][unhandled-rejection] Error: error: 1114
...\node_modules@worklouder\device-kit-oai
node_modules@worklouder\wl-device-kit
node_modules\serialport
node_modules@serialport\bindings-cpp
build\Release\serialport.node

WinDbg reports:
Failure.Bucket:
APPLICATION_FAULT_c06d007f_serialport.node!Unknown

IMAGE_NAME:
serialport.node

STACK_TEXT:
KernelBase!RaiseException
serialport+0x26430

The bundled native module delay-imports node.exe and tries to resolve:
napi_module_register
That procedure cannot be resolved in the current application runtime, resulting in 0xc06d007f (ERROR_PROC_NOT_FOUND).
Module path:
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
Regression information
The previous installed version, 26.707.3748.0, did not produce this native-module crash. The crashes began after restarting into 26.707.9981.0.
This appears to be a packaging/runtime compatibility regression involving the bundled Work Louder device-kit serialport native addon.
Expected behavior
The desktop app should launch and remain running. Failure to initialize optional device/serial-port functionality should not terminate the entire application.
Reproduction
Install or update the Microsoft Store Codex app to 26.707.9981.0.
Launch the app on Windows 10 x64.
Wait approximately 5–10 seconds.
The application exits and Windows records exception 0xc06d007f.

I can reproduce this exact failure on Windows x64 with the same Store build.

Environment

• Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Embedded app build: openai-codex-electron 26.707.72221
• Chromium file version: 150.0.7871.115
• Separate npm Codex CLI: 0.144.4 (works normally and is not involved in these crashes)

Reproduction and update correlation

Windows AppX deployment logs show the user registration updating from 26.707.9564.0 to 26.707.9981.0 at 2026-07-15 07:49 local time.

The new build then generated seven Application Error / MoAppCrash reports between 10:16 and 10:46. A normal uninstall at 10:31 followed by a Store reinstall at 10:38 did not resolve it; the same failure occurred again immediately after reinstall.

All seven dumps have the same exception and delay-load payload:

Exception:       0xC06D007F
Importing module: serialport.node
Delay-loaded DLL: node.exe
Missing procedure: napi_module_register
GetLastError:     127 (ERROR_PROC_NOT_FOUND)
Resolved hmodCur: ChatGPT.exe
Exception module: KERNELBASE.dll

The importing binary is:

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

The renderer's Codex Micro bridge mounts when codexMicro is present and immediately invokes getState(). The main process registers that service and lazily loads codex-micro-service, which imports @worklouder/device-kit-oai. No Work Louder/Codex Micro device was intentionally enabled or connected.

Windows also recorded a RADAR_PRE_LEAK_64 event for ChatGPT.exe 150.0.7871.115 on the previous day. During diagnosis the desktop process tree remained around 1.2–1.4 GB working set and exhibited severe intermittent lag.

WER reports share bucket hash:

fe840c3ed30ba850ddeac7488b0e9f2e

This independently confirms the x64 build has the same native-addon/runtime mismatch described in the issue. Reinstalling the same Store version and changing the system Node.js installation cannot repair the bundled native module.

Seven local minidumps are available, but I am not attaching them publicly because they may contain process memory or session data. They can be provided privately to an OpenAI maintainer if needed.

Independent reproduction on Windows x64, with the same Store build and the same native delay-load failure.

Environment

• Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Windows: 25H2, build 26200.8875, AMD64
• Bundled Codex app-server: 0.144.2

Observed behavior

The main ChatGPT.exe process remained alive and generally reported as responding, but switching between tasks produced repeated severe pauses rather than a conventional terminal crash.

Windows recorded 50 Application Error event ID 1000 faults against the same live main-process PID between 10:57:14 and 11:18:50 local time. Thirty-seven occurred before diagnostic activity began. The faults arrived in interaction-correlated bursts and stopped while the UI was left untouched.

Windows retained ten rotating local dumps, each approximately 10.8–10.9 MB. Direct read-only parsing of all ten MINIDUMP exception streams and PE module data produced the same result each time:

Exception:          0xC06D007F
Delay-loaded DLL:   node.exe
Missing procedure:  napi_module_register
GetLastError:       127 (ERROR_PROC_NOT_FOUND)
Resolved function:  null
Importing module:   @serialport/bindings-cpp/build/Release/serialport.node
Dependency chain:   @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport

The addon was loaded at a new ASLR address, failed, unloaded, and was retried. That repeated fault/WER-dump cycle matches the short task-switch freezes.

The WER bucket hash was:

fe840c3ed30ba850ddeac7488b0e9f2e

Resource cross-check

This was not general machine pressure: approximately 41 GB of 64 GB RAM remained available, disk queue was effectively zero, and Codex GPU utilization was low.

There was also substantial retained runtime state before diagnosis: the Codex process tree already had 47 descendants using about 5.1 GB working set and 15,500+ handles. One essentially idle retained Node kernel held about 1.36 GB. That appears to be a separate runtime-cleanup issue that materially amplifies switching cost, but the repeating serialport.node fault is the clearest immediate cause.

I am not attaching dumps publicly because they may contain process memory or session data. They can be provided through an official private upload channel if needed.

Independent corroboration

Environment

• Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Windows 10 Pro, build 19045, x64
• Previous local package: 26.707.8479.0; Windows Store updated it to 26.707.9981.0 on July 14

Observed behavior

With Codex open, normal task interaction is accompanied by severe system-wide pointer/UI stutter. The process remains running rather than terminating.

Event evidence

The main ChatGPT.exe process began emitting Application Error event ID 1000 entries with exception 0xc06d007f about 11 seconds after launch. I recorded 75 matching events over approximately 71 minutes; they occurred in bursts while the app was in use.

Event Viewer identifies the Codex package but reports bad_module_info / unknown, so this comment does not independently identify the importing DLL. It is an independent confirmation of the same package/version/error signature and the resulting UI impact; the dump analysis in earlier comments supplies the direct serialport.node attribution.

Same issue here

Independent confirmation with full crash dumps from the main Codex Desktop process.

Environment

• Windows 10 Pro x64, build 19045
• Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Process: main ChatGPT.exe process; command line had no renderer/utility --type= flag
• No Work Louder/Codex Micro hardware is required to trigger the failure

Dump evidence

I analysed ChatGPT.exe full dumps locally with CDB. The unhandled exception is:

ExceptionCode: 0xC06D007F
DLL: node.exe
Procedure: napi_module_register
Import: by name
LastError: 127 (ERROR_PROC_NOT_FOUND)
Faulting module: serialport.node

The failing binary is the bundled addon under:

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

The stack is the Windows loader entering serialport.node initialisation and then KernelBase!RaiseException. ChatGPT.exe exports no matching napi_* symbols, so the addon's delay-load resolution of node.exe!napi_module_register fails during module initialisation.

I have three dumps from the same PID. The unloaded-module information shows serialport.node being loaded and failing at three different base addresses, indicating repeated load attempts rather than a one-off corrupt load. In my case this defect produced a complete ChatGPT.exe process death, not only brief UI stalls.

WinDbg bucket:

APPLICATION_FAULT_c06d007f_serialport.node!Unknown

This is consistent with an app packaging/runtime compatibility regression in the optional Work Louder device integration. User configuration, Codex personality, MCP servers, hooks, workspace ACLs, and config.toml are not in this exception path.

I can provide the full dumps and the following redacted CDB outputs through a private OpenAI upload channel:

• !analyze -v, .exr, .ecxr, stack and module information
• decoded DelayLoadInfo
• module/export inspection

I am not uploading the raw dumps publicly because they may contain user data.

Independent confirmation from another Windows 11 x64 installation.

Environment

• Codex desktop package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Windows 11 Home 25H2, build 26200.8875, AMD64
• No Work Louder / Codex Micro device connected

User-visible behavior

The main ChatGPT.exe process usually remains alive and responsive, but sending a message or starting a turn repeatedly causes a short freeze/interruption and creates a new Windows Application Error event 1000 / WER dump. Enabling Windows Notifications and restarting the app did not change the failure, so the [desktop-notifications][unhandled-rejection] log prefix appears to be only the global error-handler label, not the cause.

Minidump evidence

Read-only parsing of the latest local minidump produced:

Exception:          0xC06D007F
Delay-loaded DLL:   node.exe
Missing procedure:  napi_module_register
GetLastError:       127 (ERROR_PROC_NOT_FOUND)
Resolved module:    ChatGPT.exe
Resolved function:  null
Importing module:   @serialport/bindings-cpp/build/Release/serialport.node
Dependency chain:   @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport

The bundled serialport.node SHA-256 is:

2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

This independently confirms the native-addon/runtime mismatch and the interaction-correlated retry behavior on Windows 11 x64. I am not attaching raw dumps because they may contain session data, but can provide them through a private OpenAI upload channel if requested.

ChatGPT/Codex Windows app 26.707.9981.0 crashes approximately
six seconds after every launch.

Environment:

• Windows 11 Enterprise 10.0.26200
• Windows ARM64 running under Parallels
• Package: OpenAI.Codex_26.707.9981.0_arm64

Crash dump analysis:

• Missing delay-loaded procedure: node.exe!napi_create_function
• Faulty native addon:

@worklouder/device-kit-oai/.../@serialport/bindings-cpp/
prebuilds/win32-arm64/node.napi.node

The main window and Codex backend initialize successfully, after which
the main process creates a Crashpad dump and terminates. Windows package
Repair completed successfully but did not change the behavior.

This appears to be the ARM64/crashing variant of openai/codex#33375.

Attach the C:/Users/jkuehner/AppData/Local/Packages/OpenAI.Codex_2p2nqsd0c76g0/LocalCache/Local/Codex/Logs/2026/07/15/
codex-desktop-170d6c9d-cbaf-422a-896c-ef5192d61f7b-7224-t0-i1-191621-0.log. Don’t publicly attach the full memory
dump; offer it privately to OpenAI Support if requested.

Separately, I added OpenAI’s official documentation connector to the global Codex configuration while verifying the
reporting route. It will become available after restarting the app/session.

Independent reproduction on Windows 11 x64 with the exact same Store build, exception, and bundled native-addon path.

Environment

• OS: Windows 11 Home, 10.0.26200, x64
• Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Install source/signature: Microsoft Store; package status Ok
• Microsoft Store reports no newer build available
• WSL_DISTRO_NAME is unset at process, user, and machine scope

User-visible behavior

Returning to Codex or switching/using tasks intermittently pauses the UI for several seconds. The main ChatGPT.exe process remains alive and Windows continues to report it as responding, matching the lag/retry variant rather than a terminal process exit.

Windows event evidence

Windows recorded 29 Application Error / Event ID 1000 entries between 10:13:02 and 12:38:32 local time on July 15, 2026:

• Exception: 0xC06D007F
• Faulting module: unknown
• Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0

A complete app quit/relaunch was performed at 11:59:51. Matching events recurred against the same still-live main-process PID at approximately:

• +9.9 seconds
• +112 seconds
• +2,320 seconds

This explains why the app appears temporarily non-responsive but recovers instead of fully terminating.

Local log confirmation

Codex desktop logs from both before and after the restart reference the same bundled native addon:

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 independently confirms the same Work Louder / serialport dependency chain reported above.

Isolation checks

• Full app restart did not resolve the failure.
• No current sandbox ACL failures were recorded.
• Local session history is about 0.44 GB total across 617 rollouts; the largest individual rollout is 44.5 MB, so this is not the >512 MB oversized-rollout crash case.
• Storage had approximately 175 GB free with a negligible disk queue during sampling.
• No raw dumps or full logs are attached because they may contain private session data.

This appears to be another independent reproduction of the Windows x64 serialport.node delay-load regression in 26.707.9981.0.

I can independently reproduce this exact issue with the same Codex App version and Windows platform:

• Codex App: 26.707.9981.0
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Event ID: 1000
• Exception: 0xC06D007F
• Same @worklouder/device-kit-oai → serialport.node path

Additional reproduction detail: creating a new thread or switching to another thread makes the entire computer severely sluggish for approximately 3–5 seconds, after which it recovers.

During controlled reproduction, the first native error occurred approximately 0.32–0.43 seconds after clicking a thread, followed by another error approximately 3.5–3.8 seconds later. Windows Repair did not resolve it.

The logs also alternate between:

• “A dynamic link library (DLL) initialization routine failed.”
• “Not enough memory resources are available to process this command.”

Approximately 36–38 GB of physical RAM was still free, so this is not actual system memory exhaustion.

The evidence shows:

• The updated build ran for about 11 hours.
• At 17:50:12, its background feature-configuration refresh completed.
• Immediately afterward, the process stopped.
• Every subsequent launch crashes after 5–9 seconds.
• Across all six failed launches: ThreadRead = 0, ThreadResume = 0, and route /.

So the app crashes before reading or reopening any saved conversation. The most likely sequence is that a server-side
feature flag enabled the Codex Micro/Work Louder device integration; that integration then loads the incompatible
serialport ARM64 module.

Also, chat content cannot itself cause node.exe!napi_create_function to be missing—that is a native binary linkage
error.

I would add this to GitHub issue #33375:

Additional ARM64 evidence: build 26.707.9981.0 initially ran for ~11 hours.
The running process terminated immediately after a Statsig background
configuration refresh completed at 2026-07-15 17:50:12 Europe/Berlin.

All six subsequent startup attempts show:

• route: /
• method=thread/read: 0
• thread resume attempts: 0
• crash after 5–9 seconds

Therefore the crash occurs before any previous conversation is loaded and
appears consistent with remote activation of the Codex Micro/device bridge.

Deleting the last chat or its local session file is therefore unlikely to help and risks losing useful data.

Independent reproduction on an older Windows x64 Store package, which may help scope the server-side rollout/mitigation.

Environment:

• Package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• Embedded desktop release reported by Sentry: 26.707.31428
• Bundled Codex CLI: 0.144.0-alpha.4
• Windows: 10.0.26200

Evidence:

• Windows Application Error event ID 1000 was recorded twice for the live ChatGPT.exe process with exception 0xC06D007F.
• The desktop Sentry scope identifies the same failing addon path:

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

• The issue became visible while invoking the built-in Browser and navigating to an ordinary public HTTPS page; the browser-control operation was interrupted and the app had to recover/restart.

This suggests the broken optional device-kit path can now be activated on 26.707.3748.0 as well, likely via server-side configuration. A short-term flag rollback/guard may need to cover older signed Windows desktop packages, not only 26.707.9981.0. No Work Louder/Codex Micro device was intentionally enabled or connected.

Verified active x64 mitigation

I tested a reversible local mitigation on Windows x64 with Store package OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0.

Before the controlled restart, Windows recorded 26 matching ChatGPT.exe / 0xc06d007f Application Error events during the preceding 30 minutes.

The mitigated launch used a process-scoped CommonJS preload that intercepts only @worklouder/device-kit-oai and returns a "no device detected" implementation before its serial/HID native dependencies load. The test did not modify the signed WindowsApps package, global environment variables, Codex configuration, authentication, or user data.

Verification after restart:

• The preload loaded and the targeted @worklouder/device-kit-oai require was intercepted.
• The Codex main process and all eight desktop processes remained alive and responsive.
• The existing task reconnected and handled active interaction/tool traffic.
• After 6.8 minutes, Windows had recorded zero new matching 0xc06d007f Application Error events.
• The new desktop log contained zero matching serialport.node, DLL-initialization, or related unhandled-rejection lines.

This is a temporary diagnostic mitigation, not a package fix. It disables Codex Micro / Work Louder hardware integration for the mitigated process and is guarded to refuse builds other than 26.707.9981.0. It corroborates the process-scoped ARM64 mitigation in #33381 and the gate-off x64 A/B result in #33409.

The appropriate vendor fix remains disabling/gating Codex Micro on affected Windows builds or rebuilding and packaging its native addons for the shipped Electron runtime.

Reproducible on Windows 11 25H2, Codex client version 26.707.72221

I can reproduce the same failure on Windows x64 with the current Microsoft Store build.

Environment:

• Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Installed version: 26.707.9981.0
• OS from dump: Windows 10 Version 26200 / Windows 11 x64, 24 logical cores
• Store/winget reports no newer package available for Store ID 9PLM9XGG6VKS

Observed behavior:

• ChatGPT.exe repeatedly crashes while using/starting Codex browser/IAB functionality.
• Recent crash times on the machine: 2026-07-15 22:06, 22:10, 22:11 local time.
• Windows Event Viewer repeatedly reports:
• Faulting app: ChatGPT.exe
• Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Exception code: 0xc06d007f
• Fault bucket: 2155754486034767662

Dump evidence from %LOCALAPPDATA%\CrashDumps\ChatGPT.exe(5).8760.dmp:

KernelBase!RaiseException+0x8a
serialport.node + 0x26430
serialport.node + 0x36df0

The preserved error text in memory is:

"napi_module_register" for DLL "Unknown" failed with status: 0xc0000139

Failing module path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0\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

Additional notes:

• The Codex desktop log previously recorded an unhandled rejection before the hard crash:

[desktop-notifications][unhandled-rejection]
Error: A dynamic link library (DLL) initialization routine failed.
...\@worklouder\device-kit-oai\...\serialport.node

• Fresh logs for the newest crash were zero bytes, suggesting the native crash occurs before useful app log flushing.
• Win32_SerialPort did not show active COM devices; attached devices appear to be normal USB/HID peripherals.
• The crash appears to be deterministic/repeatable in this build and is not explained by GPU, thermals, or a page-specific browser render crash.

Independent Windows x64 confirmation with an anonymized diagnostic summary.

Environment and symptom

• Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Embedded desktop release: codex@26.707.72221
• Windows 11 x64: 10.0.26200.8875
• 31.7 GB RAM, with roughly 19–20 GB available during checks
• The Codex UI intermittently becomes non-responsive, then recovers and works again. Repeated Windows Application Error events for ChatGPT.exe use exception 0xc06d007f.
• Windows app Repair completed successfully, but the same failures continued. Microsoft Store/winget showed no newer Codex package.

Memory pressure, disk capacity, temporary-file volume, GPU load, and the installed VC++ runtime were checked and do not explain the failures.

Native-module verification

The Codex/Sentry log resolves the failure to:

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

Additional checks:

• serialport.node is x64, 229,376 bytes, SHA-256 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006.
• That hash matches the signed package integrity/block-map data, so this is not local file corruption.
• A copied instance loads successfully in trusted standalone Node.js 24.14.0 x64 (N-API 10).
• Its PE delay-import table requests 57 Node-API/libuv symbols from node.exe.
• Standalone node.exe exports all 57 targets. The packaged ChatGPT.exe export table exposes only GetHandleVerifier and IsSandboxedProcess; all 57 requested targets are absent.

This independently matches 0xc06d007f / delay-load ERROR_PROC_NOT_FOUND and points to a packaged host/native-addon compatibility problem, not a damaged installation.

Trigger path

Static inspection of the packaged app shows Statsig gate 3207467860 mounting CodexMicroBridge. Its initial getState() path lazily imports codex-micro-service, which directly loads @worklouder/device-kit-oai and reaches the failing native addon. This explains why the problem can appear intermittently and then recover when an affected app process restarts.

Suggested mitigation remains: disable/narrow the Codex Micro gate for this Windows build immediately, avoid initializing the optional hardware integration until compatible hardware is present, and ship an Electron/host-compatible native addon (or correct delay-load redirection). No raw dumps are attached because they may contain user data.

Independent confirmation from a Windows 11 x64 ASUS laptop.

Environment and user-visible impact

• Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Installed version: 26.707.9981.0
• OS: Windows 11 Home 10.0.26200 x64
• No Codex Micro / Work Louder device is connected or intentionally enabled.
• The Codex window can remain visibly open while becoming unresponsive. During those incidents, remote access to the app is also unavailable. Force-closing and reopening sometimes helps, but sometimes the replacement process degrades again.

Independent dump confirmation

The preserved representative dump resolves to:

Failure bucket: APPLICATION_FAULT_c06d007f_serialport.node!Unknown
Delay-loaded DLL: node.exe
Missing procedure: napi_module_register
LastError: 127 (ERROR_PROC_NOT_FOUND)
Importing module: @serialport/bindings-cpp/build/Release/serialport.node

The dependency chain and versions are:

@worklouder/device-kit-oai 0.1.10
  -> @worklouder/wl-device-kit 0.1.18
    -> serialport 12.0.0
      -> @serialport/bindings-cpp 12.0.1

• serialport.node SHA-256: 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006
• Representative dump SHA-256: 0F1E1FF84732CAE2AFA2303F0D1C950C6B6263E1B22A553D22007E657D803F3C
• Store/winget reports no version newer than 26.707.9981.0.

Recovery observation

A controlled Codex restart changed the main process and reduced aggregate working set from roughly 3.0 GB to 1.39 GB while TCP CLOSE_WAIT entries fell from 27 to 0. The app recovered, but the same native exception remains present in the installed binary, so restart is only mitigation.

A local watchdog now confirms UI/network/resource degradation before restarting Codex, with a restart budget and circuit breaker to prevent loops. This improves remote recoverability but is not a package fix.

No raw dump, session transcript, app log, credentials, cookies, prompts, or local usernames are attached publicly. The preserved dump and sanitized debugger output can be provided through an OpenAI-designated private channel if needed.

Apologies for the slop post but, me too!

See below from 5.6 Sol

Independent x64 confirmation on Windows 11 Pro build 26200.8875, Codex package 26.707.9981.0.

A full WER LocalDump produced the same result:

• 0xC06D007F
• delay-loaded DLL: node.exe
• missing procedure: napi_module_register
• resolved module: ChatGPT.exe
• LastError = 127
• failing serialport.node SHA-256: 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006
• WER bucket: fe840c3ed30ba850ddeac7488b0e9f2e

A 226-second WPR trace captured four corresponding main-process faults and the resulting WerFault.exe dump activity during the
visible freezes. There were no concurrent System-log storage, display, or hardware errors.

The full dump, WinDbg output, and ETL are available through a private upload channel if useful.

https://github.com/openai/codex/issues/33381#issuecomment-4985779999

just in case anyone might find this mitigation useful. it was posted in another thread

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

Independent x64 reproduction: task switching, system-wide input stalls, and controlled gate-off A/B

I independently reproduced this issue on Windows 11 x64 and traced the severe task-switch stalls to the same bundled native addon.

Environment

• Codex Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Embedded desktop app build: 26.707.72221
• Windows 11 Home 25H2, build 26200.8875, x64
• Intel Core i9-13900KF, 64 GB RAM, NVIDIA RTX 4090
• No Work Louder / Codex Micro hardware connected

User-visible trigger and measured impact

Switching between existing Codex tasks reproducibly caused system-wide pointer/input stalls; at its worst, the mouse was almost impossible to move.

This did not correlate with general machine saturation:

• overall CPU remained below approximately 43%
• DPC activity remained at zero in the sampling window
• interrupt and disk queue counters were low before the fault
• ample RAM and GPU capacity remained available

During reproduction, Codex working set rose from approximately 1.77 GB to 3.16 GB. Immediately after a matching native exception and Windows Error Reporting activation, disk write throughput peaked at approximately 637,364,898 bytes/sec. This explains why a recoverable main-process fault appeared to the user as a whole-desktop mouse/input freeze rather than only a Codex window pause.

Windows recorded more than 95 same-signature application faults during the affected day.

First-chance dump evidence

A ProcDump first-chance capture analyzed with WinDbg produced:

Failure bucket:     APPLICATION_FAULT_c06d007f_serialport.node!Unknown
Exception:          0xC06D007F
Delay-loaded DLL:   node.exe
Missing procedure:  napi_module_register
LastError:          127 (ERROR_PROC_NOT_FOUND)
Current procedure:  null
Importing module:   @serialport/bindings-cpp/build/Release/serialport.node
Resolved hmodCur:   ChatGPT.exe image base

The dependency chain and versions are:

@worklouder/device-kit-oai 0.1.10
  -> @worklouder/wl-device-kit 0.1.18
    -> serialport 12.0.0
      -> @serialport/bindings-cpp 12.0.1

The dump contains no loaded node.exe module. The delay-load state resolves hmodCur to the packaged ChatGPT.exe image, which does not export the requested N-API entry point. This is consistent with a host/native-addon packaging mismatch rather than a DLL search-path issue.

IME control experiment

A third-party Chinese IME had initially injected its normal text-service DLLs. I temporarily removed that input method, restarted Codex, and verified that the new main process contained no DLL from that IME. The identical 0xC06D007F failure still reproduced.

After the native-addon workaround described below, the IME was restored as the default input method and the failure did not return. The IME is therefore not required for this defect.

Controlled feature-gate A/B

Static inspection showed the Codex Micro renderer path behind feature gate 3207467860. Task-state changes call codexMicro.getState() / lighting updates, which lazily load the Work Louder service even without connected hardware.

For isolation only, I created a private portable copy of the exact installed app build and changed only the two checks for gate 3207467860 to evaluate false. I did not distribute the modified application.

All other variables remained the same: Windows account, OpenAI account, Codex user data, task history, projects, input method, and app binaries.

With the gate disabled:

• serialport.node was never loaded
• no new 0xC06D007F event or WER report appeared
• 415 monitoring samples over 109 seconds recorded zero Responding=False observations
• working set peaked near 788 MB and returned to approximately 354 MB
• repeated task switching no longer caused the severe mouse freeze

Restoring the third-party IME and restarting the gate-disabled build still produced no native-addon fault. This provides a direct trigger-off / fault-off A/B result.

There is a separate, much smaller task-resume/cache stutter under rapid switching across many tasks, but it occurs without a crash or WER event and should not be conflated with this native-addon failure.

Suggested remediation

1. Disable or narrow Codex Micro gate 3207467860 for affected Windows builds as an immediate mitigation.
2. Do not load the optional hardware integration until compatible hardware is detected or the user explicitly enables it.
3. Rebuild/package the native dependency for the exact desktop host runtime, or load it in a compatible Node sidecar rather than the current host process.
4. Isolate optional hardware initialization failures from the primary UI process.

I have retained the first-chance dump and sanitized measurements but am not attaching raw dumps or Codex logs publicly because they may contain local paths, prompts, or process memory. I can provide sanitized debugger output or validate a candidate Windows build through a private OpenAI channel.

If OpenAI maintains a Windows desktop preview or structured regression-testing cohort, I would be glad to participate; this machine/account combination reproduced the issue consistently and can validate the official fix.

Independent confirmation from #33460 on Windows 11 25H2 build 26200.8875:

• Affected package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• The UI rendered and accepted input briefly, then stopped accepting clicks roughly 5–7 seconds after launch.
• Windows recorded Application Error 1000 with exception 0xC06D007F.
• Live CDB decoding identified delay-loaded DLL node.exe, missing procedure napi_module_register, LastError = 127, and the same @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport -> @serialport/bindings-cpp/build/Release/serialport.node chain.
• Store repair/reinstall, the official web installer, GPU-disable flags, and clearing disposable UI state did not help.
• As a temporary workaround, OpenAI's signed offline MSIX 26.707.3351.0 remained responsive beyond the failure window, accepted a real Windows navigation click, and produced no new matching Application Error event during the controlled test. Existing .codex sessions remained intact. This is a version-pin workaround, not a package fix.

Closing #33460 as a duplicate of this issue.

I can reproduce this on Codex Windows App 26.707.9981.0.

A visible symptom is that after sending a message, the message appears in the conversation but the original text remains in the composer briefly while the UI freezes.

Windows Event Viewer repeatedly records Application Error event ID 1000 for ChatGPT.exe with exception code 0xc06d007f. After restarting the app, 17 events were recorded within a few minutes. After using Windows Settings > Apps > ChatGPT > Repair and restarting again, 6 more events appeared within about two minutes.

System CPU and memory were not saturated. Restarting the app and Windows App Repair did not resolve the issue.

Independent confirmation on a second Windows x64 system/account.

Environment

• Codex Store package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Windows 25H2 build 26200.8655, x64
• No Codex Micro / Work Louder integration in use

Failure evidence

• The app retained 10 rotating minidumps (~106.7 MiB total); all 10 sampled dumps had the same CrBrowserMain / 0xC06D007F failure.
• The delay-load payload resolves to node.exe!napi_module_register, LastError=127 (ERROR_PROC_NOT_FOUND), from the bundled @serialport/bindings-cpp/build/Release/serialport.node dependency under the Work Louder device kit.
• Opening an existing task, typing/sending, and task-state changes repeatedly produced new dumps and multi-second system/IME stalls.
• Disabling unrelated MCP/plugin paths, temporarily stopping Nahimic, and a per-user WER exclusion did not stop the failures. The WER exclusion was reverted.

Controlled local-only A/B
I made a private portable copy of the exact installed build for diagnosis (not distributed), kept the same account/profile/task data, and changed only the two renderer checks for Codex Micro feature gate 3207467860 to evaluate false.

• Last dump from the unmodified Store build: 21:33:59 local
• Gate-off copy started: 21:34:30
• No dump was created after the gate-off start during repeated real typing/sending
• The user reports the severe lag is gone

This independently confirms trigger-off / fault-off behavior. An immediate remote mitigation would be to disable/narrow gate 3207467860 for affected Windows builds, followed by rebuilding the native addon for the exact Electron runtime and isolating optional hardware initialization from the primary UI process.

Raw dumps are not attached because they may contain private process data.

Independent confirmation from another Windows x64 installation.

Environment

• Windows 11 Pro 25H2, build 26200.8875, x64
• Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0

Observed behavior

• Codex becomes noticeably slow while opening, switching, and using local tasks.
• Windows repeatedly records Application Error event ID 1000 / MoAppCrash for ChatGPT.exe.
• Exception code: 0xC06D007F
• WER hashed bucket: fe840c3ed30ba850ddeac7488b0e9f2e
• The app can remain visibly open and responding despite the repeated events.

Local evidence

• 310 matching Application Error events were recorded on 2026-07-16 between 00:50:32 and 10:39:38 KST.
• A current system-wide snapshot while Codex was active showed 82 node.exe and 21 node_repl.exe processes. Full parentage was not resolved, so this is reported as contextual evidence rather than attributing every process to Codex.
• The main Codex process was using approximately 1.7 GB of private memory.
• The machine was not under general resource pressure:
• Approximately 15.6 GB of 31.6 GB RAM remained available.
• Disk utilization remained below approximately 4%.
• Processor queue length averaged 0.33.
• OpenAI network first-response time was approximately 0.25–0.41 seconds.
• OpenAI Status reported all systems operational.

I have not deleted .codex\sessions, reset the app, or manually modified the installed package. No logs or crash dumps are attached to this public comment.

This appears to match the issue's package version, exception signature, and user-visible lag. Please advise whether a fixed build or a safe temporary workaround that preserves local tasks, sessions, authentication, and configuration becomes available.

Same issue here on Windows. The Codex desktop app repeatedly freezes or becomes unresponsive, and a full system reboot did not help. This is blocking active work. Could an OpenAI maintainer please confirm whether this regression has been acknowledged, whether a server-side feature-flag rollback is being considered, and provide an ETA or an official workaround? Please also update the status page if this is affecting a broader group of users.

Independent Windows x64 confirmation

I independently reproduced the same issue on another Windows 11 x64 system.

Environment

• Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• The package reports status Ok
• System CPU, memory, and disk were not saturated during reproduction

Matching failure evidence

• Windows repeatedly records Application Error event ID 1000 for ChatGPT.exe
• Exception code: 0xC06D007F
• The desktop log reports: A dynamic link library (DLL) initialization routine failed.
• The logged dependency chain ends at:

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

• The bundled serialport.node SHA256 is:

2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

After a clean normal restart, the first matching event appeared about 10 seconds after launch. Four matching events were recorded within roughly 2.5 minutes while the app remained visibly open.

User-visible impact

• Opening the app can make the pointer show a busy state immediately.
• Sidebar scrolling or opening a task can pause for several seconds.
• After sending a message, the user bubble can appear in the conversation while the original text remains in the composer briefly and the UI freezes.
• The process often recovers instead of exiting, so this presents as repeated short hangs rather than one conventional crash.

Windows App Repair completed successfully, including package registration/ACL repair, but the same exception returned approximately 14 seconds after the repaired app was launched. This supports a packaged runtime/native-addon regression rather than damaged local registration.

One additional observation: a process-scoped NODE_OPTIONS --require preload attempt did not prevent the native addon from loading on this system. serialport.node was still mapped in the main process and the same events continued. This is only an environment-specific observation, but it suggests the community preload mitigation should not yet be treated as universally reliable.

No raw logs, dumps, session data, account information, hostnames, IP addresses, or local user paths are included here. Sanitized diagnostics can be provided privately if requested.

Independent x64 reproduction with additional startup-latency evidence.

Environment

• Codex Desktop package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• OS: Windows 11 25H2, build 26200.8875, x64
• First observed: 2026-07-16 (UTC+8)

Matching failure

The desktop log reports:

[desktop-notifications][unhandled-rejection] Error: A dynamic link library (DLL) initialization routine failed.
...\@worklouder\device-kit-oai\node_modules\@worklouder\wl-device-kit\node_modules\serialport\node_modules\@serialport\bindings-cpp\build\Release\serialport.node

Windows Application log recorded at least four Application Error / WER events within roughly two minutes:

Faulting application: ChatGPT.exe
Exception code: 0xc06d007f
Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
Faulting module: unknown

The app becomes severely laggy during startup and task operations.

Measured startup RPC latency

From one cold start:

| Method | Calls | Average | Maximum |
|---|---:|---:|---:|
| app/list | 3 | 4,391 ms | 11,974 ms |
| mcpServerStatus/list | 1 | 8,952 ms | 8,952 ms |
| plugin/list | 10 | 2,688 ms | 5,423 ms |
| thread/start | 2 | 4,716 ms | 5,129 ms |
| thread/list | 7 | 743 ms | 4,953 ms |

A possibly related contributing behavior is repeated bundled-plugin reconciliation in the same startup:

• browser is reported as missing, installed successfully, then shortly reported as outdated and installed again.
• chrome is reported as outdated, installed successfully, and then checked/reinstalled again.
• The Chrome native host is stopped during this cycle.

This does not explain the native exception by itself, but it appears to amplify the visible UI stall while the serialport failure is occurring.

Causes checked and ruled out locally

• About 14 GB physical memory remained available.
• Disk utilization and queue length were approximately zero during sampling.
• Codex app-server CPU was idle after startup.
• Workspace contained only 87 files; enumeration completed in about 38 ms.
• state_5.sqlite: ~4.1 MB, PRAGMA integrity_check = ok.
• logs_2.sqlite: ~101 MB, PRAGMA integrity_check = ok.
• No evidence that project size, Git, SQLite corruption, memory pressure, or disk pressure caused the lag.

Package files were installed/updated around July 13–14, while the matching serialport.node failure first appeared locally on July 16. Earlier local Codex logs did not contain this DLL error.

Raw logs and dumps are not attached publicly because they may contain task/session data, but sanitized excerpts can be provided if needed.

Independent reproduction with whole-desktop impact

I can independently reproduce the same failure signature on another Windows x64 installation.

Environment

• Windows 25H2, build 26200.8875, x64
• Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Chromium file version: 150.0.7871.115
• Microsoft Store packaged installation

User-visible impact

• Codex becomes increasingly slow during normal, longer-running work.
• Opening or switching tasks can become noticeably unresponsive.
• During severe episodes, the Windows taskbar also remains unresponsive for an extended period.
• Task Manager may become unusable or unable to recover the desktop, sometimes requiring a full system restart.
• Codex can remain visibly open despite Windows continuously recording application failures.

Repeated restart history and paid-plan impact

This is not an isolated occurrence. While trying to continue normal work, I have restarted the Codex application and rebooted Windows many times.

Some of these were forced system restarts because the Windows taskbar remained unresponsive and Task Manager could not restore normal operation. Restarting only provides temporary relief; the problem returns during subsequent normal use.

I am subscribed to ChatGPT Pro with the 20× Codex usage tier. However, the Windows client cannot remain reliably usable long enough for me to make normal, complete use of that paid capacity.

A large amount of my available Codex usage remains unused because work is repeatedly interrupted by lag, freezes, application failures, and system restarts. This is not caused by reaching a usage or rate limit—the client becomes unusable while substantial paid usage capacity is still available.

The instability therefore has a direct paid-plan impact: I have purchased the higher-capacity tier, but the Windows application prevents me from consistently using the service that the subscription provides.

Matching local evidence

Across multiple app runs, Windows recorded 19 matching Application Error event ID 1000 entries between 2026-07-15 23:52:58 and 2026-07-16 15:01:57 local time (UTC+8).

During one freshly observed run:

• ChatGPT.exe started at 2026-07-16 14:46:34.
• The first matching event appeared approximately 8 seconds after launch.
• Windows recorded 11 matching failures within about 15 minutes.
• All 11 events referenced the same still-running process: PID 16888 (0x41F8).
• Exception code: 0xC06D007F
• Faulting module: unknown
• WER hashed bucket: fe840c3ed30ba850ddeac7488b0e9f2e

The Codex desktop log independently contains:

[desktop-notifications][unhandled-rejection]
Error: A dynamic link library (DLL) initialization routine failed.

The logged native dependency path ends at:

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

This matches the package version, exception code, dependency chain, and repeated-failure behavior reported in this issue.

The additional concern in this reproduction is that the impact can extend beyond short Codex UI freezes to prolonged Windows shell/taskbar unresponsiveness, making the machine temporarily difficult or impossible to recover without restarting.

No raw application logs, task transcripts, account information, or local user paths are included in this public comment. Sanitized diagnostic excerpts can be provided privately if requested.

Please provide a fixed Microsoft Store build or an official temporary workaround that preserves local tasks, sessions, configuration, and authentication.

I can reproduce the same failure on a newer Windows x64 Codex Desktop package:

• Package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Symptom: immediately after launch and while switching between existing tasks, the UI becomes non-interactive / appears to drop mouse input. This can become severe enough that tasks cannot be switched.
• Windows Event Viewer: repeated ChatGPT.exe Application Error events with exception 0xc06d007f.
• App runtime log: repeated DLL initialization routine failed when loading the bundled @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport -> @serialport/bindings-cpp/build/Release/serialport.node.
• The task-list backend request returns HTTP 200 and UI-click telemetry is recorded shortly before the failure, so this is not explained by a failed task-list request or clicks never reaching the app.

Already ruled out locally, with no improvement:

1. Rebuilt the Codex local cache (old cache was about 1 GB; fresh cache was about 25 MB).
2. Re-registered/repaired the AppX package and restarted.
3. Updated from 26.707.9981.0 to 26.707.12708.0.
4. Verified the x64 Visual C++ runtime and real GPU 3D rendering.
5. Restarted Codex after removing observed Sogou/GamePP injected modules from the process; the same failure continued.

The mouse is configured for 2000 Hz polling. I have not yet A/B tested a lower polling rate, so this is only a possible load amplifier, not an asserted root cause. It does not explain the native-module initialization failure or the repeated 0xc06d007f application crashes.

Expected: switching tasks should remain responsive; an optional device integration should not repeatedly crash or destabilize the desktop app during ordinary task navigation.

Independent reproduction on Store build 26.707.12708.0

The newer Microsoft Store package does not eliminate the underlying exception stream on this Windows x64 installation.

Environment

• Windows 11 x64, build 26200
• Package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Updated successfully from 26.707.9981.0 through Microsoft Store

Observed after the update

During one run of the new package:

• Main ChatGPT.exe PID: 9088
• Process start: 2026-07-16 15:29:31 (UTC+8)
• 12 matching Application Error event ID 1000 entries were recorded between 15:29:42 and 15:39:13
• Every event referenced the same PID and exception 0xC06D007F
• At 15:40:34, that same main-window process was still alive and reported Responding=True

This distinction is important: Windows/WER classifies the events as MoAppCrash, but in this run the visible window did not exit. The process survives and recovers while the native exception repeats. On the previous package, the user also experienced visible exits; on 12708, no visible exit had occurred yet during this observation window.

The new package still contains the native addon at:

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

Its SHA256 is:

2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

The packaged app also contains a CodexMicroService that imports @worklouder/device-kit-oai. The current public Codex Micro documentation describes settings after device detection, but I could not find a documented user-facing switch to disable this optional hardware discovery service.

So build 26.707.12708.0 may improve visible stability in this run, but it still reproduces the same underlying serialport.node / missing-procedure failure. A fixed native addon or a supported way to keep Codex Micro discovery unloaded until explicitly enabled would still be needed.

No raw logs, task contents, account data, or user paths are included in this comment.

Independent confirmation after updating to 26.707.12708.0 (Windows x64)

The newer Microsoft Store package still reproduces the same bundled serialport.node delay-load failure on this installation.

Update and reproduction timeline (UTC+8)

• 15:20:36: AppX deployment began changing the preferred package from 26.707.9981.0 to 26.707.12708.0.
• 15:33:37: registration of OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0 completed successfully and the old package was moved to the AppX deleted area.
• 15:34:24: the new package's main ChatGPT.exe process started (PID 39712 / 0x9B20).
• 15:34:42.227: the new package log recorded:

[desktop-notifications][unhandled-rejection]
Error: A dynamic link library (DLL) initialization routine failed.

...\OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0\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

Between 15:34:36 and 15:50:35, Windows recorded 8 Application Error event ID 1000 entries for that same PID and new package. Every entry reported:

Application: ChatGPT.exe
Faulting module: unknown
Exception: 0xC06D007F
Package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0

At 15:56:19, the same process was still alive and Responding=True. Therefore WER classifies these as MoAppCrash faults, but in this run they manifested as repeated recoverable native exceptions rather than an immediate visible process exit.

Packaged native binary evidence

The serialport.node shipped in 26.707.12708.0 is:

Size:   229,376 bytes
Arch:   AMD64 / x64 (PE machine 0x8664)
SHA256: 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

That SHA256 matches the binary already reported in this issue for 26.707.9981.0, so the newer package appears to ship the same affected native addon.

Read-only PE inspection of the new package shows:

• serialport.node delay-imports 57 Node-API/libuv procedures from node.exe.
• The packaged ChatGPT.exe exports 0/57 of those procedures.
• The packaged chrome.dll exports 57/57.
• Other bundled native addons that load successfully, including better_sqlite3.node and windows-updater.node, import chrome.dll; the failed serialport.node is not present in the live process module list.

This independently confirms that build 26.707.12708.0 has not fixed the native-addon/runtime symbol-resolution mismatch. The immediate failure remains consistent with VcppException(ERROR_PROC_NOT_FOUND) / 0xC06D007F while initializing the optional Work Louder device integration.

No raw application logs, local paths, task contents, account data, or crash dumps are attached publicly. Sanitized diagnostics can be provided if a maintainer needs them.

Independent confirmation on 26.707.12708.0 (Windows x64)

The current Microsoft Store update still reproduces the same issue on another affected installation.

• Package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Main ChatGPT.exe process start: 2026-07-16 16:40:30 (UTC+8)
• Matching Application Error event ID 1000 entries during that process run: 11
• Latest matching event in the sample: 2026-07-16 16:43:40 (UTC+8)
• Exception: 0xc06d007f
• Visible impact: brief freezes when switching tasks and when submitting a message; the app can remain open after each event

The bundled native addon is still present at the Work Louder/Codex Micro dependency path:

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

Packaged binary details:

Size:   229,376 bytes
SHA256: 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

This hash matches the affected binary already reported in this issue, so build 26.707.12708.0 appears not to have replaced the failing native addon.

No raw logs, crash dumps, local user paths, task contents, account data, or credentials are included in this public comment.

Independent confirmation on Windows 11 x64 after update to 26.707.12708.0

This installation still reproduces the same recurring Windows error after updating Codex.

Environment

• OS: Windows 11 Pro x64, build 26200
• Package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Executable: ChatGPT.exe

Observed behavior

• Windows Application Error event ID 1000 for ChatGPT.exe
• Faulting module: unknown
• Exception: 0xc06d007f
• 362 matching event reports observed between 10:30:22 and 10:42:47 on 2026-07-16 (Europe/Paris). This is an event-report count, not necessarily 362 distinct visible exits.
• Representative event: RecordId 261293, report ID 7fd693c2-faf7-4330-b34f-c3c6c4f632c5

A WER queue report captured for the same package also contained:

• ReportId: d6276959-8009-486b-bc95-26fb0b484def
• IntegratorReportId: 63016f0a-99ef-4c57-9340-4481f38ded01
• Exception code: c06d007f

The update did not eliminate the issue on this machine. Please confirm whether this should be linked to the serialport.node / Work Louder native-addon regression and whether a fixed package or an official mitigation is available for Windows x64.

No raw logs, crash dumps, task contents, account data, credentials, or local user paths are attached.

Independent confirmation across 26.707.9981.0 and 26.707.12708.0 on Windows 11 x64

I can independently reproduce the same repeated 0xC06D007F failure and severe UI-lag behavior. Updating to the newer Microsoft Store package 26.707.12708.0 has not eliminated it.

Environment

• OS: Windows 11 Pro, 10.0.26200, x64
• Installation source: Microsoft Store
• Current package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Package status: Ok
• Previous affected package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• CPU: Intel Core i7-12650H
• RAM: 31.6 GB
• GPU: NVIDIA RTX 3070 Laptop GPU
• No Work Louder or Codex Micro device is in use. A Get-PnpDevice -PresentOnly check found no present device matching either name.

User-visible behavior

During normal task use, Codex becomes severely sluggish or temporarily non-interactive. The application can recover and remain visibly open, so this often presents as repeated freezes rather than one terminal crash.

Windows Event Viewer evidence

Windows recorded Application Error event ID 1000 repeatedly for ChatGPT.exe with exception 0xC06D007F.

For the previous 26.707.9981.0 package:

• 160 matching events
• First: 2026-07-15 18:49:16 UTC+3
• Last: 2026-07-16 11:18:41 UTC+3

For the current 26.707.12708.0 package:

• Main ChatGPT.exe process started at 2026-07-16 11:21:11 UTC+3
• First matching fault occurred approximately 14.5 seconds after launch
• 8 matching events occurred between 11:21:26 and 11:34:24
• At 11:36:32, the same main-window process was still alive and reported Responding=True

The current-package event fields include:

Provider:        Application Error
Event ID:        1000
Application:     ChatGPT.exe
Exception code:  c06d007f
Faulting module: unknown
Package:         OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0

This matches the recoverable native-exception/retry variant reported by others: Windows records crash-class events while the main process survives.

Codex desktop log confirmation

The current process log recorded this at 2026-07-16T08:21:34.425Z, approximately 23 seconds after launch:

[desktop-notifications][unhandled-rejection]
Error: A dynamic link library (DLL) initialization routine failed.

The logged native-addon path is:

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

Packaged native binary evidence

The serialport.node bundled in 26.707.12708.0 is:

Size:   229,376 bytes
SHA256: 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006

This SHA256 matches the affected binary already reported and dump-analyzed in this issue for both 26.707.9981.0 and 26.707.12708.0.

I have not independently performed WinDbg delay-load decoding, so my direct evidence is limited to the matching Windows events, the Codex desktop log, and the packaged binary hash. These independently corroborate the existing dump analysis identifying the node.exe!napi_module_register / ERROR_PROC_NOT_FOUND failure.

I can reproduce a startup-crash variant with the same package version and exception code.

Environment

• Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Installation source: Microsoft Store
• Executable: ChatGPT.exe
• Architecture: x64

Observed behavior

The tray icon appears, but the main window never opens. Several ChatGPT.exe processes may remain temporarily, and all observed processes report:

MainWindowTitle:
MainWindowHandle: 0

The application then crashes or becomes inaccessible without displaying a usable window.

Windows Event Viewer repeatedly records:

Application Error, Event ID 1000
Exception code: 0xc06d007f
Faulting module: unknown
Package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0

Windows Error Reporting also records MoAppCrash events with the same exception code.

The issue still occurs after:

• Windows App Repair
• Windows App Reset
• Renaming the local state_5.sqlite files
• Completely uninstalling the application
• Rebooting Windows
• Reinstalling it from the Microsoft Store

This appears to be a more severe startup-crash manifestation of the same underlying issue: the application is not usable at all rather than only becoming intermittently laggy.

Follow-up: validated local gate-off workaround on 26.707.12708.0

This is a follow-up to my earlier independent confirmation. The result below is an unsupported, local-only mitigation, not an official fix. No modified application binary is being distributed.

What was changed

I made a private portable copy of the exact installed app and left the Microsoft Store package untouched.

In build 26.707.12708.0, the renderer bundle inside app.asar contains exactly two checks of the Codex Micro feature gate in:

webview/assets/app-main-DJ6rrd0b.js

The build-specific expression is:

ba(`3207467860`)

I changed only those two expressions to evaluate false. I used an equal-length replacement so the ASAR size and file offsets remained unchanged:

!1/*no-micro*/  

The patcher was deliberately fail-closed: it refused to modify anything unless the exact expected expression occurred exactly twice. The copied executable and all other application files remained byte-identical to the Store package.

After fully exiting the Store build, I launched the private copy against the same existing Electron user-data profile. The original login, tasks, and configuration remained available. The Store build and portable copy were never allowed to use that profile concurrently.

Controlled A/B result

Unmodified Store build 26.707.12708.0 on the same system/profile:

• First matching 0xC06D007F event appeared about 12 seconds after launch.
• Four matching Application Error event ID 1000 entries appeared within approximately three minutes.
• The app log recorded DLL initialization routine failed at the bundled Work Louder / serialport.node path.
• The user experienced startup busy-pointer behavior, multi-second task-switch stalls, and delayed composer clearing.

Private gate-off copy:

• Initial isolated-profile smoke test: 20 seconds, main process alive/responding, zero matching events.
• Real existing-profile run: more than 11 minutes, main process still alive/responding.
• Matching 0xC06D007F events: 0.
• serialport.node / DLL-initialization failure hits in new app logs: 0.
• 60 SendMessageTimeout(WM_NULL) responsiveness samples: 0 timeouts, average approximately 0.6 ms, maximum approximately 8 ms.
• The user immediately reported that startup, task switching, and message submission felt dramatically smoother.

This is another strong trigger-off / fault-off result. Preventing the renderer from mounting the Codex Micro bridge avoids the codexMicro.getState() path that had been triggering the affected optional native integration.

Safety and limitations

• I do not recommend modifying the registered WindowsApps package in place.
• I do not recommend sharing pre-patched binaries.
• This workaround is strictly version-specific and should be retired as soon as the Store package changes.
• Codex Micro / Work Louder hardware support is unavailable in the gate-off copy.
• Because the copy no longer runs with the normal AppX package identity, package-identity-dependent features such as notifications or deep links may differ.
• Users attempting a similar diagnostic should make a full backup, fully exit the Store app first, and refuse to patch if the expected occurrence count or bundle name differs.

For an immediate official mitigation, remotely disabling or narrowing feature gate 3207467860 for affected Windows builds still appears likely to stop the crash loop while a correctly packaged native addon is prepared.

**Independent confirmation on 26.707.12708 + this is a module class, not just serialport — classic-level.node in the browser/chrome plugins has the same defect**

We independently reproduced your analysis on package 26.707.12708.0 (the build rolled out 2026-07-16, which reduces the event rate ~6x but does not fix it), and extended it to every native addon in the package. Read-only analysis: pefile over the installed package + a load test of copies under a node.exe host.

1. Your serialport diagnosis confirmed bit-for-bit

• @serialport/bindings-cpp/build/Release/serialport.node: delay-import table targets the literal module name node.exe, 57 N-API symbols.
• Host ChatGPT.exe exports 2 symbols total — 0/57 satisfied. chrome.dll exports 57/57. No Electron delay-load redirect hook present in the addon.
• Delay-load helper resolves node.exe → host executable → GetProcAddress fails → VcppException(ERROR_SEVERITY_ERROR, ERROR_PROC_NOT_FOUND) = 0xc06d007f, matching every Application Error event on our machines (~40/h on 26.707.9981.0 under active use).

2. Runtime discriminator: the module itself is intact
Copying the identical serialport.node out of the package and loading it via process.dlopen under the app's own bundled node.exe v24.14.0 (host name == delay target) → loads cleanly, all exports present (open, close, getBaudRate, …). So this is purely a host-name/delay-target mismatch that only detonates inside ChatGPT.exe.

3. New finding: scanning all 31 bundled .node files shows a class of affected addons

| addon | location (package-relative) | delay target | satisfied by ChatGPT.exe |
|---|---|---|---|
| serialport.node | app.asar.unpacked\...\@serialport\bindings-cpp | node.exe × 57 | 0/57 |
| HID.node | app.asar.unpacked\...\@worklouder\...\node-hid | node.exe × 61 | 0/61 |
| sharp-win32-x64.node | resources\cua_node\bin\node_modules\@img\sharp-win32-x64 | node.exe × 52 | 0/52 |
| classic-level.node (win32-x64 & ia32) | resources\plugins\openai-bundled\plugins\browser\scripts\... and ...\plugins\chrome\scripts\... | node.exe × 48 | 0/48 |

All four load fine under a real node.exe host (verified for serialport, HID, classic-level). By contrast, the first-party addons (windows-account.node, windows-updater.node, computer-use-app-icons.node, better_sqlite3.node, pty.node, skia.win32-x64-msvc.node) have no node.exe delay dependency — packaged correctly.

4. Why this matters beyond Codex Micro
classic-level.node sits in the browser and chrome plugin script trees. On our two affected machines (details in https://github.com/openai/codex/issues/33488#issuecomment-4989919531) the 0xc06d007f events correlated with browser-sidebar/IAB activity and turn streaming, and the desktop log's [desktop-notifications][unhandled-rejection] Error: A dynamic link library (DLL) initialization routine failed. appears to be just where the rejection bubbles up — the source is the addon load on those code paths. So fixing/gating @serialport/bindings-cpp alone likely won't clear the storm; the delay-load hook (or an Electron-targeted rebuild) is needed for all third-party prebuilt addons in the package, or the loads need to be gated behind explicit feature opt-in as you suggested.

(Trigger context, also in the #33488 comment: on both our machines the first 0xc06d007f landed within seconds of a statsig-refresh "values updated" — consistent with a staged server-side flag enabling these load paths, which would explain why the addons shipped broken for a while without symptoms and why Repair/Reset/reinstall don't help.)

I can confirm that this issue still reproduces on a newer Codex Windows App build.

Environment

• Codex App: 26.707.12708.0
• Windows 11 26H2 Experimental Insider, build 26300.8772, x64
• Native Windows workspace; no Codex Micro / Work Louder device is connected

Symptoms

• Clicking a task in the left sidebar causes a noticeable pause.
• The content area may remain blank for several seconds before the task history renders.
• Windows App Repair and restarting Codex did not resolve the issue.

Windows Application Error repeatedly reports ChatGPT.exe failures with exception code 0xc06d007f.

The local Codex Sentry state contains the same native-module failure:

A dynamic link library (DLL) initialization routine failed.

The failing module is the bundled:

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

This suggests the issue remains present in 26.707.12708.0, with delayed/blank task switching as the most visible symptom.

Will this be fixed in the near future?

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.

Confirmation after the Windows feature disable

Preliminary positive result from a previously affected Windows x64 installation:

• Current Store package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Restarted normally at 09:13 EDT after the Windows feature-disable announcement
• The previously used process-scoped preload workaround was not used for this process
• After 27.9 minutes of active task use, the main process and all eight desktop processes remained alive and responsive
• Matching ChatGPT.exe / 0xc06d007f Application Error events since restart: 0
• Matching serialport.node, DLL-initialization, or related unhandled-rejection lines in the new desktop log: 0

The package still contains the previously affected serialport.node binary (SHA256 2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006), so this clean result is consistent with the server-side Windows feature disable taking effect rather than a packaged binary fix.

I will report back if the failure returns.

Update + correction after 26.715.2236 (fixed on my machines) — and I over-reached on classic-level/sharp

The build 26.715.2236.0 (internal 26.715.21316) that rolled out this morning stops the crash storm on my machine: 0 Application Error events since launch, IAB/browser backend started cleanly twice, no DLL initialization routine failed. What changed in the package:

• serialport.node: removed entirely (the whole @serialport/bindings-cpp tree is gone from app.asar.unpacked).
• HID.node: rebuilt — it now does a normal import of chrome.dll (61 funcs) instead of delay-importing node.exe. So it resolves against the Electron host correctly.

Both of these are the @worklouder device-kit (Codex Micro) addons — the ones loaded by the renderer inside ChatGPT.exe. Fixing exactly these two matched the crashes stopping.

Correction to my earlier comment: I listed sharp-win32-x64.node and classic-level.node as part of the same "affected class." That was over-reach. In 26.715.2236 they are unchanged (still delay-target node.exe, ChatGPT.exe satisfies 0/52 and 0/48 respectively) — yet the crashes are gone. The reason: those two are not loaded in the ChatGPT.exe host. On this machine:

• sharp lives under resources\cua_node\bin\node_modules → loaded by the bundled node.exe subprocess.
• classic-level lives under the browser/chrome plugin scripts, which run under the bundled node.exe (nodePath=...\cua_node\...\node.exe in browser_use_runtime_paths_selected).

In a node.exe host the delay-load target node.exe resolves to the host itself, so the missing-export pattern is harmless there. The defect only detonates when the addon is dlopen'd by a host that isn't named node.exe — i.e., the Electron ChatGPT.exe process. So the correct culprit set was just {serialport, HID}, not the broader static sweep I posted. Apologies for the noise — the lesson for anyone triaging: a node.exe-target delay import is only a bug relative to the host process that loads it, so pair the PE scan with "which process actually dlopens this addon."

Net: on my two machines this is effectively fixed by 26.715.2236. sharp/classic-level still carry the fragile packaging pattern and would break if they were ever loaded directly in the Electron host, so hardening them (delay-load hook or chrome.dll target, as done for HID) is still worthwhile defensively — but they were not the cause of this storm.

Additional corroboration from an affected Windows x64 installation (all identifying details removed).

Additional impact

This failure mode also degraded the app-server/Remote Connect path, not only UI responsiveness:

• Windows Error Reporting recorded 210 distinct MoAppCrash reports within one affected app session. All used the same signature: 0xC06D007F, PCH_84, and StackHash_0000.
• The desktop shell remained partially alive while the native failure retried.
• The process tree accumulated 29 ChatGPT.exe renderer/utility processes plus multiple orphaned node_repl and code-mode helper processes.
• The bundled codex.exe app-server accumulated 46 TCP connections in CLOSE_WAIT on port 443, with only one established connection remaining.
• Remote Connect still had an enabled enrollment locally, but the host appeared offline and stopped maintaining a usable connection.

Recovery observation

Force-closing the exact Codex desktop process tree and activating the AppX package again started build 26.707.12708.0 instead of 26.707.9981.0. After that clean launch:

• remoteControl/enable completed without an error.
• The enrollment timestamp refreshed.
• The app-server established healthy TLS connections.
• CLOSE_WAIT count returned to zero.
• No additional 0xC06D007F crash events appeared during the post-restart observation window.

Suggested resilience improvements

In addition to fixing or gating the optional native hardware module:

1. Back off or permanently disable the integration after the first native initialization failure instead of retrying indefinitely.
2. Reap renderer, Node, computer-use, and code-mode child processes after a failed initialization.
3. Detect sustained CLOSE_WAIT accumulation and restart only the affected app-server transport.
4. Surface a degraded-health warning when Remote Connect enrollment is enabled but its heartbeat/transport is no longer healthy.
5. Confirm whether 26.707.12708.0 contains the packaging fix for this failure.

Adding one more data point from Windows 11 x64. I'm using the Microsoft Store build 26.715.2305.0. The app is usable, but when voice input is left active, the Codex UI periodically freezes for a few seconds and the mouse becomes choppy. Task Manager still shows low overall CPU use and no obvious memory spike.

This machine had previously shown the 0xc06d007f / WorkLouder serialport errors on the 26.707 builds. The current 26.715.2305 package no longer contains serialport.node, and I do not see the old DLL error in the new log. However, as a local test I started the same build with only the optional WorkLouder device module disabled. I do not own or use WorkLouder/Codex Micro hardware. Voice input still worked, and during a short 42-second mic-on test I could not reproduce the freeze. Windows recorded no new Application Error or Hang events during that run.

This is only a short A/B test, so it may be a coincidence and I would not call it a confirmed root cause. I am posting it because the behavior returned on a newer build and disabling that optional path changed the result. I can provide sanitized event metadata if it would help.

@whatthecodemean #20214 is collecting these stories looks like. #33375 is closed