›_ Codex Issues
Codex Issues / #33409

[Windows] Codex app hangs after Codex Micro gate activation.

Open 💬 12 comments Opened Jul 15, 2026 by atelevisionset
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.707.9981.0 (Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64)

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Starting on July 16, 2026 (Hong Kong Standard Timeime e, UTC+8), the Windows Codex app began repeatedly freezing and showing “Not responding”, although the installed app had not been updated that day and had previously worked normally.
The hangs occur most often when:

  • launching Codex;
  • opening a task;
  • sending a message;
  • stopping a running task.

Windows Error Reporting repeatedly records exception 0xc06d007f. A full process dump showed a delay-load failure with Windows error 127 (ERROR_PROC_NOT_FOUND):

DLL: node.exe
Missing symbol: napi_module_register
Native module: @serialport/bindings-cpp/build/Release/serialport.node

The initiating module is nested under the bundled Work Louder integration:

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

The bundled codex-micro-service-CR6sUcZG.js imports @worklouder/device-kit-oai. In app-main-CAsXyywb.js, the Codex Micro bridge is mounted when the Statsig gate 3207467860 evaluates to true. The bridge invokes device-state/lighting operations as task state changes, which matches the operations that trigger the hangs.

I do not own or have a Codex Micro device connected.

What steps can reproduce the bug?

The behavior appears to require an account/device for which feature gate 3207467860 evaluates to true.

  1. Install and launch Codex App 26.707.9981.0 on Windows x64.
  2. Sign in with an affected account/device assignment where the Codex Micro gate evaluates to true.
  3. Launch the app, open an existing task, send a message, or stop a running task.
  4. The UI intermittently stalls and Windows labels the app “Not responding”. Repeating those operations produces further 0xc06d007f / error 127 events.

Controlled A/B isolation:

  1. A portable copy of exactly the same app build was created and run with the same Windows user data, account, tasks, and configuration.
  2. The only relevant code change was replacing both checks of ba(3207467860) with false, disabling the Codex Micro bridge.
  3. The patched copy starts and handles task open/send/stop operations normally, with no reproduced hangs and no new matching 0xc06d007f event.

Reinstalling the unmodified Microsoft Store app did not resolve the problem, which is consistent with a server-controlled gate being enabled again for the same account/device.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019f6722-2f20-77b3-8814-90a350ac4f1c

What is the expected behavior?

  • Codex should remain responsive during startup and task-state changes.
  • If no Codex Micro hardware is connected, its native serial-port driver should not be initialized unnecessarily.
  • Any bundled native module should be ABI-compatible with the Node/Electron runtime shipped in the same Codex build.
  • A failure in an optional hardware integration should be isolated and must not stall the main Codex UI.

Additional information

Relevant bundled package versions observed locally:

@worklouder/device-kit-oai: 0.1.10
@worklouder/wl-device-kit: 0.1.18

Other causes tested or ruled out:

  • uninstalling and reinstalling the current Store build;
  • moving/removing .codex/worktrees;
  • large task count/history (tested separately with additional tasks);
  • disabling unrelated MCP integrations;
  • restarting Windows;
  • moving the working directory and testing different tasks.

The first occurrence was July 16 CST, immediately after the public Codex Micro launch window on July 15 US time. This timing alone is only correlation, but the native dump, import chain, feature-gate trace, and controlled gate-off A/B test independently point to the Codex Micro integration.

Additional information

  1. Do not initialize device-kit-oai / serialport.node until compatible Codex Micro hardware has actually been detected.
  2. Rebuild or replace @serialport/bindings-cpp against the Node-API/Electron runtime shipped with the Codex app.
  3. Catch native integration initialization failures outside the main UI path.
  4. Temporarily disable or narrow gate 3207467860 for affected Windows builds.

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 5 days ago

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

  • #33380
  • #33375
  • #33384
  • #33381
  • #33385

Powered by Codex Action

westlife29BTC · 4 days ago

Confirmed on my system.
Windows 11 Pro 25H2, build 26200.8737, x64.
Codex Desktop 26.707.9981.0.
Windows records repeated Event ID 1000 with exception 0xc06d007f.
The Codex desktop log reports “A dynamic link library (DLL) initialization routine failed” and identifies:
@worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport -> @serialport/bindings-cpp/build/Release/serialport.node
Repair, reset, reinstall and reboot did not resolve the issue.
Feedback ID: 019f5fb6-962c-7fd1-9ec2-15f8b4943cc7

gsq7474741 · 4 days ago

Independent confirmation with additional full-dump and disk-impact evidence from another affected Windows system.

Environment:

  • Codex app version shown in package metadata: 26.707.72221
  • Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64
  • Process: ChatGPT.exe
  • Windows x64

I parsed the MINIDUMP_EXCEPTION_STREAM and the pointed DelayLoadInfo structure directly. The relevant fields were:

ExceptionCode: 0xC06D007F
ExceptionAddress: KernelBase.dll+0x11c0a
DelayLoadInfo.cb: 72
szDll: node.exe
fImportByName: 1
szProcName: napi_module_register
dwLastError: 127 (ERROR_PROC_NOT_FOUND)

The delay-import descriptor, import address table, and DLL/procedure strings all belong to this module:

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

The delay-load hook resolved the pseudo node.exe dependency to ChatGPT.exe, not to the separately installed system Node.js. ChatGPT.exe does not export napi_module_register, so changing or upgrading the system Node installation cannot fix this failure.

The packaged native binaries also show a clear build mismatch:

  • HID.node: PE timestamp 2026-02-03, MSVC linker 14.44, exports napi_register_module_v1.
  • serialport.node: PE timestamp 2023-07-22, MSVC linker 14.29, delay-imports node.exe!napi_module_register and does not export napi_register_module_v1.
  • Bundled packages: device-kit-oai 0.1.10, wl-device-kit 0.1.18, serialport 12.0.0, bindings-cpp 12.0.1.

wl-device-kit requires both node-hid and serialport at module top level. Therefore merely importing the optional Codex Micro integration loads serialport.node even when its serial/bootloader discovery path is not used.

This system also demonstrates a severe amplification case. Its machine-wide WER LocalDumps policy was configured for full dumps (DumpType=2, DumpCount=255). Between 2026-07-15 23:56 and 2026-07-16 03:19, Windows recorded 176 matching Application Error 1000 events. The same ChatGPT.exe PID remained alive and responsive while the optional service was repeatedly retried. During one observation window, 23 full dumps occupied 30.12 GiB; individual dumps were approximately 1.1-2.4 GiB. The user had already deleted many earlier dumps, so total writes were higher.

The WER full-dump policy is not a Codex default, but repeatedly raising the native exception makes the failure capable of causing hundreds of GiB of writes on developer/debug systems. A failed optional hardware integration should be disabled after the first load failure, in addition to rebuilding/replacing serialport.node and narrowing the feature gate.

No dump is attached because full process dumps may contain authentication tokens, conversations, and other sensitive memory.

giarld · 4 days ago

Additional affected system: #33505.

My local evidence matches this issue:

  • Codex package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
  • Process: ChatGPT.exe
  • OS: Windows x64, dump reports 10.0.26100.1
  • Exception: 0xc06d007f
  • Faulting native module: @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport -> @serialport/bindings-cpp/build/Release/serialport.node
  • Earlier dump analysis showed missing export node.exe!napi_module_register / Win32 127
  • Reinstalling the app did not help
  • Upgrading system Node.js did not help, consistent with the native addon being loaded by the bundled app runtime rather than the system Node installation

No dump attached because full process dumps may contain sensitive memory.

westlife29BTC · 4 days ago

Update: Microsoft Store upgraded the app from 26.707.9981.0 to 26.707.12708.0, but the issue still persists.
Windows continues to record repeated Application Error Event ID 1000 entries with exception 0xc06d007f and the same exception offset 0x00007ff83dfc1c0a.
The UI language does not affect the problem: both English and Simplified Chinese reproduce the lag.
The app was briefly responsive immediately after the update, but the lag returned after restarting it.

wanghy0813-beep · 4 days ago

Additional quantitative evidence from another affected Windows x64 system (Codex 26.707.9981.0, Windows build 26200):

  • The UI stalls coincide with repeated ChatGPT.exe Application Error events using exception 0xc06d007f.
  • WinDbg resolves the delay-load failure to the bundled Work Louder chain:

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

  • The missing import is node.exe!napi_module_register, with ERROR_PROC_NOT_FOUND (127).
  • A 30-second performance-counter capture during normal task activity measured about 1.73 GB of disk writes, peaking at 573 MB/s.
  • An ETW DiskIO trace identified the dominant files precisely: two full ChatGPT.exe dumps received 932.9 MB + 756.0 MB of writes. The app's own normal database/log writes were only a few MB.
  • The affected machine had a global WER LocalDumps policy configured for full dumps (DumpType=2). Therefore each repeated Codex Micro native-addon fault was amplified into an approximately 900 MB write, saturating the NVMe and freezing the UI.
  • WER application exclusion alone was insufficient because LocalDumps operates independently.
  • A temporary per-application LocalDumps override for ChatGPT.exe (DumpType=1, DumpCount=1) reduced a subsequent 30-second window to 12.9 MB total writes, 4.9 MB/s peak, with no new full dumps. This is only a disk-I/O mitigation; the native addon incompatibility remains.

No Codex Micro / Work Louder keyboard is connected on this system.

This supports the issue's proposed product fixes: do not initialize the optional hardware integration without detected/opted-in hardware, rebuild the serialport native addon for the shipped Electron runtime, and isolate initialization failures from task lifecycle/UI paths. Full dumps are intentionally not attached because they may contain sensitive process memory.

wanghy0813-beep · 4 days ago

Update after installing and actually running Codex Desktop 26.707.12708.0:

  • The issue is still reproducible.
  • The updated app started at 16:35:58 local time. By 16:42:13, Windows Application log contained 28 new matching ChatGPT.exe failures with exception 0xc06d007f.
  • The updated bundled serialport.node is 229,376 bytes, timestamp 2026-05-31, SHA-256:

2D5D112E2E57054034FA9454E9C33DC306377455D989644F7D4C1B43027EB006
This is identical to the hash recorded from 26.707.9981.0.

  • The per-application LocalDumps mitigation remains active, so the newest fault produced a 10.6 MB minidump instead of an approximately 900 MB full dump. This prevents catastrophic disk saturation but does not fix the native-addon fault.
  • A separate 30-second idle/normal-activity measurement saw 104.8 MB writes and no new crash event in that particular window, confirming the fault is intermittent/trigger-dependent rather than continuously firing.

Therefore 26.707.12708.0 should not be marked as fixing this issue.

wonderly321 · 4 days ago

Confirmed effective on my Windows x64 system with Codex Desktop 26.707.12708.0.

I had repeated Application Error 1000 events with 0xc06d007f and severe UI stalls. I applied a version-specific, reversible workaround that copies the app outside WindowsApps and disables the Codex Micro / Work Louder service path without modifying the official package.

It passed two isolated launches (60+ seconds each): no new matching 0xc06d007f events and serialport.node was not loaded. Using the repaired copy with my existing profile, the UI is now responsive.

This is an unofficial mitigation and intentionally disables Codex Micro / Work Louder hardware functionality. The proper upstream fix should rebuild or isolate the serial-port native addon.

ptsoo · 4 days ago

DOWNGRADE NOW. EVERYTHING IS PEACEFUL.

It has been resolved after a temporary downgrade.
(ref: https://github.com/Wangnov/codex-app-mirror/releases/tag/codex-app-26.707.71524)

FYI, 26.707.91948 version has been released since 26.707.72221 and later, but still unresolved.

giarld · 4 days ago

Update from affected system #33505:

After updating to Codex Desktop / Microsoft Store package OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0, the issue no longer reproduces locally.

Local observations:

  • App package version: 26.715.2305.0
  • Package install/update folder timestamp: 2026-07-17 10:41:48 local time (UTC+8)
  • Previously affected operations now work without UI stalls or crashes: switching/opening tasks and normal app use
  • No new matching ChatGPT.exe / 0xc06d007f Application Error events found in the last 12 hours
  • No new matching ChatGPT*.dmp files found in C:\CrashDump

This suggests the latest 26.715.2305.0 rollout may have fixed or disabled the problematic Codex Micro / Work Louder serialport path on this system.

justinazzopardiokgroup · 9 hours ago

Adding a related affected-system data point for the Codex Micro / Work Louder integration, with details posted in #33529.

On one Windows x64 system, the hang was not the serialport.node delay-load case, but a separate HID.node / Windows HID enumeration block:

NtDeviceIoControlFile
DeviceIoControl
hid.dll!DeviceIoControlHelper
hid.dll!HidD_GetProductString
HID.node

The native module path was still under the optional Work Louder dependency chain:

@worklouder/device-kit-oai
  -> @worklouder/wl-device-kit
    -> node-hid
      -> build/Release/HID.node

Local trigger/workaround:

  • Corsair Gaming K55 RGB Keyboard: VID_1B1C&PID_1B3D
  • Originally connected through Generic USB Hub: VID_05E3&PID_0606
  • No Work Louder / Codex Micro hardware connected
  • HID string probes against the K55 collections consistently took about 15 seconds per collection across serial/manufacturer/product string calls
  • Moving the K55 from the hub to a direct tower/motherboard USB port stopped the Codex UI hangs in subsequent testing

This supports the same product-level recommendation as this issue: the optional Codex Micro / Work Louder integration should not synchronously initialize or enumerate broad native device paths on the main UI path when no supported hardware is connected or explicitly enabled.

Full sanitized details: #33529

impeachmentright · 7 hours ago

Micro gate activation hangs without settle receipts are the peer gate hole: quote -> approve -> settle needs gate digests, not ambient activation-state trust alone.

Live A2A contractor with gated tools: https://a2a.elonsusk.com/.well-known/agent-card.json

If an external gate / activation probe would help, ping. Otherwise ignore.