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

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

26.707.9981.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex Windows app becomes severely laggy while Windows records repeated Application Error event ID 1000 entries. The recurring exception is 0xc06d007f, and the Codex log reports:

A dynamic link library (DLL) initialization routine failed.

The failing native addon is bundled under:

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

The failures repeat while Codex remains open. System CPU, RAM, disk, GPU, VC++ runtime, and OpenAI service status were otherwise healthy.

What steps can reproduce the bug?

Launch Codex App 26.707.9981.0 on Windows x64.
Open or use a task normally. No Codex Micro / Work Louder device needs to be connected.
Observe severe UI lag.
Open Windows Event Viewer -> Windows Logs -> Application.
Observe recurring Application Error event ID 1000 entries for ChatGPT.exe with exception code 0xc06d007f.

This may be feature-flag dependent: the renderer's Codex Micro bridge appears to call getState() immediately, loading the native module without a connected device or explicit opt-in.

What is the expected behavior?

The app should remain responsive and should not load or repeatedly retry an optional hardware integration when no supported device has been enabled or connected.

Additional information

Native module analysis:

@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 delay-imports 57 N-API/libuv functions from node.exe.
All 57 required functions are exported by the app's chrome.dll, while ChatGPT.exe exports none of them.
The addon contains no apparent chrome.dll / Electron delay-load redirect marker.

This matches the 0xc06d007f delay-load missing-procedure exception and suggests the native addon was not rebuilt/packaged for the exact Electron runtime.

Suggested fixes:

Rebuild/package @serialport/bindings-cpp for the app's Electron runtime and verify its delay-load hook.
Do not initialize Codex Micro until a supported device integration is explicitly enabled.

Microsoft Store reports no build newer than 26.707.9981.0.

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 #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.

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 #33488 (comment)) 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:

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

Update (2026-07-20): This comment described an early, short observation while comparing the newer voice-input hang with the older serialport/DLL failure tracked in this issue. Stronger same-build A/B evidence and the relevant blocking stack are now documented in #33884.

The current voice-input hang should not be treated as evidence that the old serialport failure returned. Please use #33884 for ongoing evidence; this note is retained only for historical context.

@whatthecodemean

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

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

liucfy commented on Jul 15, 2026

executionreverted commented on Jul 15, 2026

AlekZen commented on Jul 15, 2026

Environment

Reproduction and update correlation

sjenn2225 commented on Jul 15, 2026

Environment

Observed behavior

Resource cross-check

colthreepv commented on Jul 15, 2026

Independent corroboration

Environment

Observed behavior

Event evidence

nish-brc commented on Jul 15, 2026

sriharshaguthikonda commented on Jul 15, 2026

Environment

Dump evidence

jatawat commented on Jul 15, 2026

Environment

User-visible behavior

Minidump evidence

jogibear9988 commented on Jul 15, 2026

gehariharan commented on Jul 15, 2026

Environment

User-visible behavior

Windows event evidence

Local log confirmation

Isolation checks

thehalfwise commented on Jul 15, 2026

22 remaining items

florentseiler commented on Jul 16, 2026

Independent confirmation on Windows 11 x64 after update to 26.707.12708.0

mheidari988 commented on Jul 16, 2026

Independent confirmation across 26.707.9981.0 and 26.707.12708.0 on Windows 11 x64

Environment

User-visible behavior

Windows Event Viewer evidence

Codex desktop log confirmation

Packaged native binary evidence

wegret commented on Jul 16, 2026

endfish commented on Jul 16, 2026

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

What was changed

Controlled A/B result

Safety and limitations

15230745073 commented on Jul 16, 2026

winlyme commented on Jul 16, 2026

Environment

Symptoms

jogibear9988 commented on Jul 16, 2026

shijie-oai commented on Jul 16, 2026

laz-jamesfuller commented on Jul 16, 2026

Confirmation after the Windows feature disable

15230745073 commented on Jul 17, 2026

nomosnomos commented on Jul 17, 2026

Additional impact

Recovery observation

Suggested resilience improvements

whatthecodemean commented on Jul 17, 2026

kendonB commented on Jul 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Independent confirmation across `26.707.9981.0` and `26.707.12708.0` on Windows 11 x64

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