[Windows] App freezes: Work Louder/Codex Micro HID discovery blocks Electron main thread

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

• #33780

Powered by Codex Action

Adding an independent Windows ETW reproduction with timing and a native call stack.

Environment

• Codex 26.715.21425 (MS Store package 26.715.2305.0)
• Windows 11 Pro 25H2 26200.8875, x64
• No Codex Micro / Work Louder device present
• 38 present HID-class devices; all present PnP devices report healthy status

Measured behavior

• Seven foreground ChatGPT.exe message-pump stalls: 203–219 ms (mean 207.571 ms)
• Stall-start interval: 10.193–10.222 s (mean 10.208886 s)
• ETW stack captured during a stall:

ChatGPT.exe / chrome.dll
  HID.node
    CFGMGR32!CM_Get_Device_Interface_List_SizeW
      CFGMGR32!Local_CM_Get_Device_Interface_List_Size
        kernel32!DeviceIoControlImplementation
          Windows kernel PnP/device-enumeration path

The installed package independently correlates with the timing: the Codex Micro service defines its reconnect delay as 1e4 ms, calls findWLDevices([Project2077]), and schedules another reconnect when no device is found. Bundled @worklouder/wl-device-kit 0.1.18 implements findWLDevices() by immediately calling synchronous nodeHID.devices() (node-hid 3.3.0).

A second 36.9-second WPR capture after reboot/firmware updates and USB rerouting showed the host had 81.5% idle CPU capacity, with no System-log NVIDIA/display, USB/Thunderbolt, Kernel-PnP, or WHEA errors during the capture. HID.node was loaded in both concurrently running Codex main processes.

This supports the issue's diagnosis and quantifies the non-hanging case: normal app interaction freezes for about 0.2 seconds every 10 seconds. Moving discovery off the Electron main thread is the important fix; device-arrival notification or exponential backoff would also avoid polling absent optional hardware. A 269 MB raw ETL and the longer source trace are retained locally and can be supplied privately to an OpenAI maintainer if useful.

Follow-up: an unsupported temporary bypass worked and provides additional confirmation of the root cause.

The current installed package, OpenAI.Codex 26.715.3651.0, still contains the same 10-second discovery loop. I tested a copied runtime only; the registered installation was left unchanged.

Temporary diagnostic workaround:

1. Close every process using the copied runtime.
2. Keep a byte-for-byte backup of resources/app.asar.
3. In the copied archive, replace the single expression

``js
this.discovery.findWLDevices([a.Project2077])
``

with [], padded with ASCII spaces to exactly the original byte length. In context, [t] = [] makes discovery return no device without changing ASAR offsets or size.

1. Launch the copied executable with the original profile arguments.

The modified archive launched normally. Its expected limitation is that Codex Micro discovery is disabled for that runtime.

I then ran simultaneous 26-second window-message-loop probes against an original and patched instance (WM_NULL via SendMessageTimeout, independent probe threads, approximately 10 ms sampling):

| Instance | Samples | Delays >=50 ms | Delays >=180 ms | Maximum |
|---|---:|---:|---:|---:|
| Original | 1,630 | 3 | 3 | 499.79 ms |
| Patched | 1,704 | 0 | 0 | 4.70 ms |

The three long pauses in the original instance occurred during a window long enough for roughly three discovery cycles. The user also immediately reported that the patched instance felt substantially better while both instances were running.

This is not a suitable product fix and users should not need to modify application archives. It is useful as a controlled experiment: making only findWLDevices() return no device removes the severe periodic main-thread stalls. The proper fix remains moving HID enumeration off the Electron main thread and avoiding fixed-interval polling when optional hardware is absent.

Independent confirmation on Windows 10 x64 build 19045 with OpenAI.Codex 26.715.3651.0 (internal app release 26.715.21425, ChatGPT.exe 150.0.7871.124).

Before the controlled test, Windows had recorded 73 AppHangTransient reports and 9 Application Hang / Event 1002 entries for ChatGPT.exe that day. Moving the workspace's large .git, virtual environment, dist, and build out of the active root did not stop the freezes.

The installed resources/app.asar still contains the exact synchronous discovery call:

this.discovery.findWLDevices([a.Project2077])

I made a copied runtime only, preserved a byte-for-byte backup, and replaced only that expression with [] padded to the same length. The registered installation and its app.asar hash were verified unchanged. The copied runtime was then launched against the same normal user profile.

150-second result:

• 147/147 process samples reported Responding=True
• visible main window in 141 samples (startup accounts for the first samples)
• 0 new AppHangTransient / Event 1002
• Git process count reached 10 during the monitor
• later, 18 git.exe processes were present while the patched app still reported Responding=True
• the patched main process loaded the Work Louder serialport bindings.node, but did not load HID.node

There is no Codex Micro / Work Louder device attached—only ordinary keyboard, Logitech mouse, and HyperX headset HID interfaces, all reporting healthy PnP status.

This A/B result strongly supports synchronous Codex Micro HID discovery as the primary UI-hang trigger on this machine. The 60-second Git timeouts/process accumulation are real but appear to be a separate secondary issue, not the cause of the UI hang.

Independent confirmation from another Windows 11 x64 machine on Microsoft Store package OpenAI.Codex 26.715.3651.0.

Normal launch

• The main ChatGPT.exe window repeatedly became Responding=False; almost every mouse interaction produced a spinning cursor and temporary UI freeze.
• The bundled codex.exe backend remained responsive during the UI hang.
• The main process loaded both the Work Louder serialport native binding and node-hid's HID.node.
• logs_2.sqlite grew by 0 bytes during a 5-second sample, and there were no new Application Error/Hang events after this update. This did not look like TRACE write churn, a network stall, or a backend failure.
• Bundled versions observed: Electron 42.3.0, @worklouder/device-kit-oai 0.1.10, and @worklouder/wl-device-kit 0.1.18.

The installed service still constructs WLDeviceDiscovery, calls findWLDevices([DeviceType.Project2077]), and schedules another attempt after 10 seconds when no device is found. No Codex Micro / Work Louder hardware is in use on this machine.

Controlled A/B result

I tested a version-pinned temporary diagnostic launcher against the same signed package, account, profile, workspace, and network. It does not modify the MSIX package, user data, registry, proxy settings, or startup configuration. The only behavioral change is that loading @worklouder/device-kit-oai returns an API-compatible no-device implementation whose synchronous findWLDevices() returns [].

The launcher passed an isolated startup/self-test and left no diagnostic process or open debug port behind. After launching Codex this way, the user immediately reported that the desktop app was clearly no longer lagging and normal clicking/message interaction remained responsive.

This is strong additional causal evidence that the optional Work Louder/Codex Micro discovery path is the UI-hang trigger on this machine.

Requested product fix

Please avoid initializing this optional hardware service unless the user has enabled it or compatible hardware is present. Native HID/serial discovery should run outside Electron's main thread, have a hard timeout, and use device-arrival notifications or exponential backoff instead of fixed 10-second polling. A missing or unhealthy optional device must never block the Codex UI.

Independent Windows reproduction corroborating the Work Louder/Codex Micro HID-discovery diagnosis.

• Desktop package tested: OpenAI.Codex_26.715.4045.0_x64.
• A 143-second WPR GeneralProfile trace recorded recurring foreground UI input delays on the ChatGPT Electron main thread at roughly 10.7-second intervals. Representative input/message delays were 734 ms, 687 ms, and 703 ms.
• In each matching delay window, ETW stacks repeatedly showed the main UI thread in the bundled HID.node path:

@worklouder/device-kit-oai -> @worklouder/wl-device-kit -> node-hid -> hid.dll -> hidusb.sys -> HIDCLASS.SYS.
Three independently sampled delay windows contained 329, 317, and 296 HID.node stack samples respectively, spanning almost the whole delayed interval.

• The relevant native module is present in the installed package under @worklouder/device-kit-oai; no Work Louder / Codex Micro device is connected or required on this machine.
• HID completion activity in this trace involved ASUS AURA Sync's LightingService (RGB-lighting service). As a reversible A/B test, stopping only that service while leaving the app open made the periodic system/UI stutter disappear. This points to slow HID enumeration/interaction with a normal RGB/HID stack, not memory pressure, Git CPU, or a long DPC/ISR.

This supports moving optional device discovery off Electron's main thread and avoiding unconditional periodic nodeHID.devices() scans when no Codex Micro device has been explicitly enabled. No account, local-path, device-ID, or conversation data is included.

Follow-up with the sustained result: the Codex Micro discovery bypass fully eliminated the HID-related freezes on this machine.

Tested package: OpenAI.Codex 26.715.3651.0.

Unsupported, version-specific procedure:

1. Fully close Codex.
2. Work on a writable copy of the application directory and keep a byte-for-byte backup of resources/app.asar; leave the registered Store package untouched.
3. Replace the single expression:

``js
this.discovery.findWLDevices([a.Project2077])
``

with [], padded with ASCII spaces to exactly the original byte length. This makes discovery report no Codex Micro without changing ASAR size or offsets.

1. Launch that copied runtime normally.

Controlled A/B result using independent window-message-loop probes:

| Runtime | Samples | Delays >=50 ms | Delays >=180 ms | Maximum |
|---|---:|---:|---:|---:|
| Original | 1,630 | 3 | 3 | 499.79 ms |
| Patched | 1,704 | 0 | 0 | 4.70 ms |

The original produced three long pauses during a 26-second window; the patched runtime produced none. With this bypass included in the final workaround configuration, the machine then completed almost 24 hours of real, heavy Codex use without the periodic HID stalls or hangs.

The intentional limitation is that Codex Micro / Work Louder discovery is disabled. This is not a suitable product fix, but the A/B result is conclusive for this failure path: preventing findWLDevices() from entering synchronous node-hid enumeration removed the symptom. The product fix should move HID discovery off the Electron main thread, add bounded per-device timeouts, and avoid fixed-interval polling when optional hardware is absent.

Independent confirmation on Windows with interface-count A/B measurements and direct window-message-loop timing.

Environment

• Codex package: OpenAI.Codex_26.715.4045.0_x64
• ChatGPT.exe: 150.0.7871.124
• Windows 11 Pro 25H2, build 26200.8875, x64
• No Codex Micro / Work Louder hardware connected
• HID.node confirmed loaded in the active ChatGPT main process

The visible symptom is a recurring cursor/UI hitch while Codex is open, including while the app is idle.

HID interface-count A/B

I measured present HID interfaces and timed Windows HID enumeration plus attribute/manufacturer/product/serial descriptor reads.

• A: Razer secondary keyboard and Logitech Lightspeed receiver connected
• B: Razer secondary keyboard removed
• C: Razer keyboard and Lightspeed receiver removed; mouse connected by cable

| State | HID interfaces | Enumeration time |
|---|---:|---:|
| A | 33 | 232.21–237.35 ms |
| B | 26 | approximately 165 ms |
| C | 18 | 115.80–120.53 ms |

Removing the Razer keyboard eliminated exactly seven interfaces and reduced the scan by approximately 69 ms. Removing the Lightspeed receiver eliminated another eight interfaces and reduced it by approximately another 47 ms.

The average fell from approximately 234.6 ms to 118.0 ms—a 49.7% reduction. No individual HID interface was pathologically stuck; the slowest endpoint was approximately 11 ms. The delay accumulated across otherwise functional composite HID collections.

Direct ChatGPT window measurement

With the receiver removed and the mouse wired, I probed the visible ChatGPT window using SendMessageTimeout(WM_NULL) every 20 ms for three minutes:

• Duration: 180.01 seconds
• Samples: 5,677
• Delays over 100 ms: 18
• Mean delay: 111.652 ms
• Maximum delay: 123.352 ms
• Mean interval between delays: 10.128 seconds
• Hard timeouts: 0

All 18 long delays occurred at an extremely regular approximately 10.13-second cadence. Their 101–123 ms duration closely matched the independently measured 116–121 ms HID enumeration time in the same connected-device state.

This provides direct evidence that the recurring HID work corresponds to actual ChatGPT main-window stalls. It also shows that a completely wedged HID device is not required: ordinary composite devices can cumulatively create a visible periodic pause.

The durable fix remains moving optional Codex Micro discovery off Electron’s main thread, avoiding fixed-interval global HID polling, and exposing a supported way to disable discovery when no Codex Micro is used.

I can reproduce a related Windows hang with the current Microsoft Store build:

• Codex app version: 26.715.4045.0
• ChatGPT.exe version reported by WER: 150.0.7871.124
• Windows event: AppHangTransient
• GPU disabled: still hangs
• Reset-AppxPackage: no improvement
• codex logout / codex login: no improvement

The app becomes completely unresponsive to mouse and keyboard, briefly recovers every few minutes, then hangs again.

I isolated the trigger to one specific USB device: an external USB DVD drive connected through a USB hub. With the DVD drive connected, Codex repeatedly hangs after startup. Unplugging only the DVD drive immediately resolves the issue. The webcam and card reader on the same hub do not cause the problem.

Reproduction steps:

1. Connect the external USB DVD drive.
2. Restart Windows.
3. Launch Codex.
4. Codex enters repeated Not Responding / AppHangTransient cycles.
5. Close Codex and unplug the DVD drive.
6. Launch Codex again.
7. Codex works normally.

The drive is usually empty when this occurs. My guess is that the drive or its USB-to-ATAPI bridge responds slowly or unusually during hardware enumeration, and Codex may be probing connected USB/HID devices synchronously on the Electron main thread.

There is no crash involving serialport.node or 0xC06D007F in my case—only repeated hangs.

Temporary workaround: leave the external DVD drive unplugged.

It may be worth ensuring that optional hardware discovery does not enumerate unrelated USB devices on the UI thread, and that device enumeration has a strict timeout or runs asynchronously.

+1

https://www.reddit.com/r/codex/comments/1v1b27o/comment/oym4bjd/?screen_view_count=2

Windows Codex desktop app 26.715.4045.0 causes system-wide keyboard and mouse stalls. WPR UIDelay traces show repeated approximately 1.8-second input delays every approximately 11.8 seconds. The issue persists with --disable-gpu and disappears immediately when Codex is closed. The installed app contains @worklouder/device-kit-oai, wl-device-kit, and node-hid. Wi-Fi, USBXHCI, and NVIDIA DPC traces show no multi-second stalls. Please investigate the Work Louder/Codex Micro HID discovery path and advise whether a build or workaround disables synchronous HID enumeration.

Same issue here.

Follow-up confirmation: the unsupported copied-runtime workaround that bypasses Codex Micro discovery resolved the recurring hanging/stutter on this machine.

Tested package: OpenAI.Codex 26.715.4045.0 (ChatGPT.exe 150.0.7871.124). I left the registered Store package untouched, copied the runtime to a writable location, and replaced the single this.discovery.findWLDevices([a.Project2077]) expression with an equal-length [] expression padded with ASCII spaces. The copied app.asar retained the exact original byte length and a byte-for-byte backup.

After launching the patched copy with no Codex Micro / Work Louder hardware present, the periodic hangs stopped. This independently confirms that preventing the synchronous node-hid enumeration path removes the symptom. The only intentional limitation is that Codex Micro discovery is disabled in that copied runtime.

Cross-platform check from the current macOS build (not a hang reproduction)

I checked the same optional Codex Micro integration on a Mac that has no Codex Micro / Work Louder hardware connected.

Environment

• Codex desktop: 26.715.52143 (build 5591)
• macOS: 26.5.2, arm64
• No matching Work Louder device was present in IORegistry (VID 0x303A / PID 0x8360)

Findings

• The Codex main process still maps the Work Louder serial native binding and hid-topology-watcher.node, even though no compatible device is present.
• The packaged macOS service uses a filtered native findCodexMicroInterfaces() call and registers watchHidTopology(...).
• When the topology watcher initializes successfully, the macOS implementation is event-driven rather than using the Windows fixed 10-second synchronous nodeHID.devices() loop described in this issue.
• A 30-second fallback reconciliation timer is scheduled only if the native topology watcher fails to initialize. The 60-second status refresh is used only after a device is connected.
• There were no Failed to watch HID topology or Codex Micro discovery failed events in the previous 24 hours. The main process was sleeping and used about 0.3% CPU at inspection time, with no periodic hang observed.

This confirms that the optional hardware integration is initialized and its native modules are loaded cross-platform even when the user has no Codex Micro. It also shows a concrete non-polling implementation already shipped on macOS that may be applicable to Windows: a filtered native device-arrival/topology watcher.

Please consider:

1. Lazy-loading or explicitly opting in to the Codex Micro service when no device has ever been configured.
2. Replacing Windows fixed-interval synchronous HID enumeration with a filtered, off-main-thread device-arrival watcher.
3. Providing a supported setting to disable Codex Micro discovery.