›_ Codex Issues
Codex Issues / #33780

Windows app hangs ("not responding") after launch — main process blocks forever in HID device enumeration (HID.node → hid.dll) when one HID device doesn't respond

Open 💬 45 comments Opened Jul 17, 2026 by ideazuo
💡 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.715.2305.0 (Microsoft Store package; internal release 26.715.21425 per desktop logs)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11 Home 10.0.26200 x64

What issue are you seeing?

Summary

Since the mid-July update (first 26.707.x, still present in 26.715.2305.0), the Codex Windows desktop app (ChatGPT.exe) becomes unresponsive ("stopped interacting with Windows") shortly after every launch. Windows Application event log fills with Application Hang (Event ID 1002, MoAppHang) entries; on 26.707.x builds the same condition crashed the app instead (exception 0xc06d007f). The app worked fine for months before this update on the same machine.

Root cause (diagnosed locally)

I sampled the hung UI thread's native stack of the main process:

ntdll.dll        (blocked in kernel device I/O wait)
KERNELBASE/KERNEL32
hid.dll
HID.node         <- bundled native module in app.asar build
chrome.dll       (Electron main)

The main process enumerates HID devices on the UI thread (presumably the Codex Micro / accessory-detection path added in the July builds). One of my HID devices — a Corsair composite mouse, VID_1B1C&PID_1B75, exposing 4 HID interfaces — was in a bad state where opening its HID interfaces blocks indefinitely: CreateFileW (even with access mask 0, share RW) never returns. I verified this with an out-of-process probe: all other 30 HID interfaces on the system open + HidD_GetProductString in <100 ms, while all 4 interfaces of that device hang past any timeout.

The UI thread blocks in roughly 60-second cycles (window briefly becomes responsive between cycles, then blocks again). Because the main thread is blocked, worker/IPC traffic piles up and times out, producing misleading secondary log errors such as:

  • Timed out waiting for MCP response to plugin/list
  • worker_rpc_response_error "Failed to resolve git common dir: git process timed out after 60000ms"
  • mcpServerStatus/list ... durationMs=65209

Verification

Unplugging the offending HID device immediately and completely fixes the hang; the app then runs normally. No other software on the machine was affected by this device, since ordinary apps don't enumerate HID.

Expected behavior

HID enumeration should not run (or synchronously block) on the main thread, and per-device opens should be wrapped with timeouts — a single unresponsive HID device shouldn't freeze the entire app window.

Related issues

This looks closely related to the Codex Micro / Work Louder device-kit reports #33606, #33375, #33518, #33567, #33409 — my 0xc06d007f Application Error events on 26.707.x (17 events on Jul 16 alone) match the serialport.node delay-load failures described there. This report adds the 26.715 manifestation with a captured native stack: the HID.node path blocks the UI thread indefinitely on a real, unresponsive HID device, with a confirmed hardware trigger and unplug-verification.

Additional note (possibly a separate issue)

While diagnosing this I also found: if the MSIX package is installed on a secondary drive (Windows EFS-encrypts package files there by design), every "bundled executable relocation" copy fails with errno -4094 (ERROR_ENCRYPTION_FAILED surfaced as UNKNOWN, bundled_executable_relocation_failed ... during copy_directory) and the app retries endlessly on every focus event; on Windows Home (no EFS support) this is unrecoverable until the app is reinstalled on the system drive. Consider COPY_FILE_ALLOW_DECRYPTED_DESTINATION or a read+write fallback for that copy path.

What steps can reproduce the bug?

  1. Use a Windows machine with a HID device whose interfaces do not answer open requests. In my case: a Corsair composite mouse (VID_1B1C&PID_1B75, 4 HID interfaces) in a wedged state — CreateFileW on any of its HID interface paths never returns (verified with an out-of-process probe; every other HID interface on the system opens in <100 ms).
  2. Launch the Codex Windows app (26.715.2305.0, Microsoft Store).
  3. The window renders, then goes "Not responding" within seconds, and stays in ~60-second block cycles (briefly responsive between cycles). Windows logs Event ID 1002 (MoAppHang) for ChatGPT.exe on every launch.
  4. Unplug the offending HID device — the app immediately and permanently becomes responsive again.

Note: reproducing requires a HID device in this stuck state, which is why the bug appears hardware-random across users. Any HID device whose driver stalls opens will trigger it, since the enumeration happens on the main thread. On 26.707.x the same code path crashed instead (0xc06d007f, 17 Application Error events on Jul 16 alone on my machine).

What is the expected behavior?

HID/accessory detection (Codex Micro / device-kit path) should run off the main thread and wrap per-device opens with timeouts. A single unresponsive HID device should never freeze the entire app window, and its failure should degrade gracefully (skip the device, log once, no endless retry).

Additional information

_No response_

View original on GitHub ↗

45 Comments

github-actions[bot] contributor · 3 days ago

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

  • #33529

Powered by Codex Action

iAlexNT · 3 days ago

Same, After the update, it's impossible to work.

chrislopez24 · 3 days ago

Impossible to work after the update, same problem

victorsbd · 3 days ago

I can reproduce a closely related issue with a Corsair Gaming K63 keyboard on the exact same Codex Desktop package.

Environment

  • Codex Desktop: OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0
  • Keyboard: Corsair Gaming K63
  • USB hardware ID: VID_1B1C&PID_1B40
  • Corsair virtual bus driver: 3.0.88.0 (2022-07-27)
  • iCUE: updated to the latest version currently offered
  • Keyboard firmware: updated to the latest version currently offered

Normal-mode HID layout

In normal mode, Windows exposes the physical keyboard as a composite device with two USB interfaces and several HID collections:

USB\VID_1B1C&PID_1B40&MI_00
USB\VID_1B1C&PID_1B40&MI_01

HID\VID_1B1C&PID_1B40&MI_00&COL01  Keyboard
HID\VID_1B1C&PID_1B40&MI_00&COL02  Consumer control
HID\VID_1B1C&PID_1B40&MI_00&COL03  Vendor-defined
HID\VID_1B1C&PID_1B40&MI_00&COL04  Vendor-defined
HID\VID_1B1C&PID_1B40&MI_01        Vendor-defined

The Corsair software stack also exposes:

Corsair composite virtual input device
Corsair Bus

Reproduction and A/B isolation

  1. Start Codex with the K63 connected in normal mode.
  2. Use Codex normally.
  3. After some time, Codex begins experiencing severe intermittent stalls and becomes non-responsive for several seconds at a time.
  4. Disconnect only the K63 USB cable.
  5. Codex becomes responsive immediately, without restarting or terminating the application.

This has been reproduced more than once. Other USB devices can remain connected; disconnecting the Corsair keyboard alone is sufficient to recover Codex.

I also performed all of the following:

  • updated iCUE;
  • updated the keyboard firmware;
  • reset the keyboard by reconnecting it while holding Escape;
  • disconnected all USB devices and reconnected them one by one.

These actions temporarily improved the behavior, but the severe stalls returned in normal keyboard mode.

BIOS-mode comparison

After switching the K63 to BIOS mode, Windows exposes a much simpler physical HID layout:

USB\VID_1B1C&PID_1B40
HID\VID_1B1C&PID_1B40

The MI_00, MI_01, COL01, COL02, COL03, and COL04 child interfaces disappear. Corsair composite virtual input device and Corsair Bus remain present.

With the keyboard in BIOS mode:

  • active Codex conversations appear stable;
  • the previous severe in-thread stalls have not reproduced so far;
  • a short stall still occurs the first time an uncached conversation history is opened.

I tested that remaining first-open stall with the K63 physically disconnected. It still occurs without the keyboard and disappears on subsequent switches after the conversation has been loaded. That remaining symptom therefore appears to be a separate conversation-history loading/caching issue, not part of the Corsair HID problem.

I also queried the Windows Application event log immediately after one of the stalls for ChatGPT.exe, HID.node, serialport.node, 0xC06D007F, and MoAppHang. No matching Application events were recorded in the checked ten-minute window, possibly because these shorter stalls recover before Windows records an application hang.

This appears consistent with the synchronous HID enumeration problem described in this issue, but with a Corsair composite keyboard rather than the Corsair composite mouse in the original report. BIOS mode is currently an effective mitigation for the severe stalls on this system.

A supported temporary option to disable Codex Micro/accessory discovery would be useful until HID enumeration is moved off the main thread and protected by per-device timeouts.

chrislopez24 · 3 days ago

Just tested again and it’s also happening with my Corsair K70 keyboard and Scimitar mouse when connected

iAlexNT · 3 days ago

I have all Razer peripherals, plus a Lian Li LED controller.

I'm not sure which device is actually causing the issue, but it's extremely frustrating. Everything worked flawlessly before the update.

Tomk77 · 3 days ago

I can reproduce a closely related Windows failure on a different hardware configuration, with a useful version and workaround comparison.

Environment

  • Windows 11 Pro x64, version 10.0.26100, build 26100
  • NVIDIA GeForce RTX 2070 SUPER
  • NVIDIA driver 32.0.16.1047
  • 15.9 GB RAM
  • No Corsair or Razer device appears by name in the current PnP inventory. Windows exposes generic HID devices and a generic USB composite device.
  • Current working package after downgrade: OpenAI.Codex_26.707.9564.0_x64__2p2nqsd0c76g0

Version history and observed failures

26.707.9981.0

Windows repeatedly recorded Application Error Event ID 1000:

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

This coincided with severe Codex UI lag and brief system-wide mouse/input freezing. It reproduced many times on July 15 and 16.

26.715.2305.0

After updating to the current Store build, the app became nonresponsive shortly after launch and had to be closed. Windows recorded Application Hang Event ID 1002 for ChatGPT.exe version 150.0.7871.124 at:

  • 2026-07-17 14:34:48
  • 2026-07-17 14:40:39
  • 2026-07-17 14:50:31
  • 2026-07-17 15:56:31

The affected-build desktop log contains repeated warnings matching the secondary symptom described in this issue:

Failed to resolve git common dir: git process timed out after 60000ms
Failed to resolve git root: git process timed out after 60000ms

The stack traces point into the packaged 26.715.2305.0 Electron worker. I have not sampled the native UI-thread stack, so I cannot independently confirm that HID enumeration is the root cause on this machine.

Controlled GPU workaround on the older build

On 26.707.9564.0, disabling Chromium hardware acceleration in Codex's persisted Electron profile and recreating the GPU/shader caches resolves the severe renderer/GPU pressure:

"hardware_acceleration_mode": { "enabled": false },
"hardware_acceleration_mode_previous": false

Caches recreated:

  • GPUPersistentCache
  • GrShaderCache
  • ShaderCache
  • Default/DawnGraphiteCache
  • Default/DawnWebGPUCache
  • Default/GPUCache

Controlled send capture before the change:

  • Renderer CPU: 17.5% average of one core, 85% maximum
  • GPU subprocess CPU: 21.1% average, 38% maximum

Controlled send capture after the change:

  • Renderer CPU: 0%
  • GPU subprocess CPU: 0%
  • Independent 45-second confirmation showed no spikes above 60%

No new ChatGPT.exe Event ID 1000 or 1002 entries have appeared since downgrading to 26.707.9564.0. The currently running process started at 15:58:44 and remains responsive.

The hardware-acceleration preference survived the update and downgrade and is still false. Despite that, 26.715.2305.0 still became nonresponsive at launch. This suggests the newer launch hang is separate from, or occurs before, the renderer/GPU workaround can help.

Requested fixes

  1. Prevent optional HID/accessory discovery from blocking the Electron main/UI thread, and apply a timeout per device.
  2. Add a supported Codex setting or safe-start option to disable hardware acceleration.
  3. Ensure the persisted hardware-acceleration preference is honored before GPU/renderer initialization.
  4. Keep optional native integration failures isolated so they cannot hang or terminate the entire app.

I have retained the local desktop logs and Windows event details. I have not uploaded raw logs because they contain task/session identifiers, but I can provide sanitized excerpts if maintainers request them.

Gjalswns · 3 days ago

Adding a device-specific confirmation for the Corsair K70 LUX, plus a handle-level isolation result and a control run with Codex features restored.

Environment

  • Windows 11 Pro 25H2, build 26200.8875
  • Codex Desktop OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0
  • Corsair Gaming K70 LUX
  • USB ID VID_1B1C&PID_1B36
  • No Codex Micro / Work Louder device connected

Reinstalling Codex and resetting its local Electron profile did not stop the intermittent hangs.

Main-thread and device-handle isolation

Repeated live stack samples while ChatGPT.exe was non-responsive showed its main/UI thread blocked in this path:

ntdll!NtDeviceIoControlFile
KERNELBASE!DeviceIoControl
KERNEL32!DeviceIoControl
hid.dll!HidD_SetFeature / HidD_Get*String
HID.node
chrome.dll

The packaged HID.node is under the bundled @worklouder/device-kit-oai / node-hid integration.

I resolved the remote device handles back to their Windows PnP PDOs. The useful isolation result was:

  1. Initially blocked on HID\VID_1B1C&PID_1B36&MI_00&COL04 (\Device\0000006f).
  2. After temporarily disabling only COL04, the block moved to HID\VID_1B1C&PID_1B36&MI_01 (\Device\00000071).
  3. After temporarily disabling MI_01, the block moved again to MI_00&COL01 (\Device\0000006c), the actual keyboard collection.

All temporarily disabled interfaces were restored afterward. This shows that disabling a single vendor-defined collection is not a reliable workaround: the synchronous scan simply proceeds to another interface, eventually including the keyboard collection itself.

BIOS-mode A/B result

In normal mode, Windows exposed eight K70-related PnP entries: the USB composite device, two USB input interfaces, and five HID collections (COL01 through COL04, plus MI_01).

Moving the K70 LUX hardware polling switch to BIOS reduced that layout to two entries:

HID\VID_1B1C&PID_1B36
USB\VID_1B1C&PID_1B36

The already-hung Codex process became responsive immediately, without first restarting it.

For a final control run, I restored the Codex features I had temporarily disabled during diagnosis: apps, plugins, and remote_plugin were all enabled again. I then fully restarted Codex with the K70 still in BIOS mode and sampled the main process every two seconds for approximately 102 seconds:

  • zero non-responsive main-process samples;
  • zero non-responsive child-process samples;
  • more than ten accessory-discovery/reconnect intervals passed;
  • main-process working set settled from approximately 1.12 GB during startup to about 292 MB;
  • the first app/list completed in 10.566 seconds, subsequent calls in 254–272 ms;
  • plugin/list completed in 365–568 ms;
  • no actual app/plugin timeout was logged.

This complements the K63 BIOS-mode report above with the K70 LUX PID, direct handle-to-interface mapping, and a final run showing that stability followed the HID layout change rather than disabling apps or plugins. On this system, the observed freeze was an HID I/O wait and was not correlated with monotonic memory growth during the validation window.

daleforbes · 3 days ago

Adding a controlled iCUE startup-order A/B reproduction and descriptor-level timing for the same Corsair Harpoon PID reported here.

Environment

  • Windows 11 Home 25H2, build 26200.8875, x64
  • Codex Desktop OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0
  • iCUE 5.11.95
  • Corsair virtual bus driver 3.0.88.0
  • Corsair Harpoon RGB PRO: VID_1B1C&PID_1B75, HID bcdDevice/VER_0314
  • Corsair K100 also connected, but a per-interface probe isolated the blocking calls to the Harpoon
  • No Codex Micro / Work Louder device connected

Main-thread evidence

Three consecutive dumps of the non-responsive Codex main process, captured over approximately nine seconds, showed the same main/UI-thread path:

ntdll
KERNELBASE / KERNEL32
hid.dll
HID.node
chrome.dll

The bundled module path is under @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> node-hid.

Inspection of the packaged application flow showed:

CodexMicroBridge.getState()
  -> CodexMicro service start/connect
  -> findWLDevices([Project2077])
  -> nodeHID.devices()

The global HID enumeration occurs synchronously even though discovery is looking for a Work Louder device. With no matching device, the service schedules another discovery attempt approximately every 10 seconds.

Per-interface timing

An out-of-process probe tested all 17 present HID interfaces individually.

  • Every non-Harpoon interface completed in 1-65 ms.
  • All four Harpoon interfaces stalled immediately after HidD_GetAttributes, specifically inside HidD_GetManufacturerString, until the probe's 4,000 ms timeout:
  • MI_01
  • MI_00&COL01
  • MI_00&COL02
  • MI_00&COL03
  • Normal pointer input continued working while these descriptor requests were blocked.

Controlled startup-order reproduction

  1. With iCUE active, restarting Codex reproduced the frozen UI and four Harpoon descriptor timeouts.
  2. Stopping iCUE after the device had entered the bad state did not unwind it.
  3. Performing Corsair's full wired-mouse reset while Codex remained open and iCUE was stopped immediately restored all four interfaces to about 6 ms each and made Codex responsive.
  4. Codex then passed 42/42 responsive samples across more than four 10-second discovery/reconnect intervals.
  5. Starting iCUE after Codex was already running remained healthy: another 42/42 responsive samples, with all four interfaces still at about 6 ms.
  6. Restarting Codex while iCUE was active immediately reproduced the hang and four 4-second timeouts.
  7. After repeating the mouse reset, restarting Codex with iCUE still off remained healthy. Disabling iCUE automatic startup and rebooting also produced a responsive Codex startup.

This makes iCUE's presence specifically during Codex startup a reliable trigger on this configuration. The lower-level Corsair defect may be in iCUE, mouse firmware, or their driver interaction, but optional device discovery in Codex should still be isolated from the Electron main thread and bounded by timeouts.

Confirmed workaround

Disable iCUE automatic startup, launch Codex first, and only start iCUE afterward if needed. Close iCUE before restarting Codex.

Raw dumps were retained locally but are intentionally not attached publicly because they may contain process-memory data. Sanitized excerpts can be provided if maintainers request them.

daleforbes · 3 days ago

In-app /feedback has now been submitted with the current ChatGPT session logs for this reproduction.

Feedback/session ID: 019f6e4e-b91f-7f92-b50a-c7eede7d000c

This corresponds to the controlled iCUE startup-order and HID timing evidence in my diagnostic comment above.

daleforbes · 3 days ago

Important correction to my earlier iCUE startup-order report: iCUE is not required for the fault to recur.

After a clean reboot with iCUE automatic startup disabled:

  • no iCUE or Corsair user processes were running;
  • no iCUE or Corsair services were running;
  • Codex started normally and initially remained responsive;
  • approximately 24 minutes after the Codex process started, the severe lag returned.

A fresh per-interface probe at that point again showed exactly four timeouts, all on the Harpoon VID_1B1C&PID_1B75 interfaces:

  • MI_01
  • MI_00&COL01
  • MI_00&COL02
  • MI_00&COL03

Each reached the probe's 4,000 ms timeout immediately after HidD_GetAttributes; the K100 interfaces remained healthy. The Codex main window was non-responsive during the same capture.

After disconnecting the Harpoon and switching to a Dell USB mouse (VID_413C&PID_3029):

  • the Harpoon disappeared from the present PnP/HID inventory;
  • every remaining HID interface completed in approximately 1-6 ms;
  • the existing Codex process recovered without being restarted;
  • Codex passed 45/45 responsive samples across multiple accessory-discovery intervals;
  • a final full HID probe reported zero timeouts.

Revised conclusion and workaround

iCUE can accelerate or reliably trigger the bad Harpoon state during Codex startup, but it is not the sole cause. The Harpoon can re-enter the stalled descriptor state while iCUE is completely absent, plausibly after repeated global HID discovery calls.

The reliable temporary workaround is to leave the Harpoon disconnected and use a different non-Corsair mouse until Codex moves accessory discovery off the main thread, adds timeouts/filtering, or provides a supported opt-out.

areslp · 3 days ago

Adding another device-specific confirmation with a controlled A/B result.

Environment

  • Codex Desktop: OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0 (internal desktop version 26.715.21425)
  • Corsair Gaming K70 LUX RGB keyboard
  • USB ID: VID_1B1C&PID_1B33
  • No iCUE user processes were running; related Corsair/iCUE services were stopped or disabled

Failure evidence

Immediately after the Microsoft Store update, Codex became repeatedly unusable. Windows recorded:

  • 11 AppHangTransient WER reports for ChatGPT.exe
  • 1 Application Hang event (Event ID 1002)
  • Codex log errors including Timed out waiting for MCP response and repeated git process timed out after 60000ms

In normal keyboard mode, Windows exposed eight K70-related composite USB/HID entries.

BIOS-mode A/B

Moving the K70's hardware polling selector to BIOS reduced the present device layout from eight entries to two standard entries:

USB\VID_1B1C&PID_1B33
HID\VID_1B1C&PID_1B33

The already-running Codex process became responsive immediately, without restarting it.

I then sampled that same process every 10 seconds for 305 seconds:

  • 30/30 main-process samples were responsive
  • all 11 package processes remained alive
  • the app stayed responsive through an aggregate CPU spike of approximately 74%
  • zero new AppHangTransient reports
  • zero new Event ID 1002 records
  • 69 post-switch log lines contained zero MCP timeouts, Git timeouts, HID.node/hid.dll errors, or explicit hangs

Finally, I fully restarted Codex while the keyboard remained in BIOS mode. The new process tree started in the interactive desktop session, all 10 package processes were responsive on delayed verification, and there were still zero new WER hangs or Event ID 1002 records.

This strongly supports the synchronous HID-enumeration diagnosis and also confirms that iCUE is not required for this failure. BIOS mode is an effective temporary workaround on this K70 variant, but it disables/reduces normal keyboard functionality and is not a reasonable permanent fix.

Could this regression please be prioritized? A supported temporary opt-out for accessory discovery would also help until HID enumeration is moved off the Electron main thread and protected by per-device timeouts.

chrislopez24 · 3 days ago

Also, this https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86 workaround posted in other issue worked for me, but its temporary and we need something official and permanent

DKasza · 3 days ago

I managed to catch the hang with ProcDump on Codex 26.715.2305.0 and checked the dump in WinDbg.

!analyze -hang shows the main CrBrowserMain thread blocked here:

NtDeviceIoControlFile
DeviceIoControl
hid.dll!DeviceIoControlHelper
HidD_GetManufacturerString
node-hid/HID.node

The loaded HID module is from:

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

Failure bucket:

APPLICATION_HANG_BlockedOn_DeviceIO_cfffffff_hid.dll!DeviceIoControlHelper

serialport.node was not loaded in this dump, so this one is definitely the HID path.

I then checked the device VID/PID from the dump and Windows device list. The device it seems to get stuck on is:

VID_1B1C
PID_1B8B

This is my Corsair Scimitar RGB Elite. Windows exposes it as a composite HID device with mouse, keyboard, consumer control and vendor-specific interfaces.

So the Scimitar seems to be the trigger on my machine, but the actual bug is still in Codex: it is querying HID device information synchronously on the Electron main thread with no timeout. One HID request getting stuck freezes the whole app.

I do not have any Codex Micro / Work Louder device connected.

Lywx · 3 days ago

Best workaround is to rollback! Forced to use CLI today. Rollback with https://github.com/Wangnov/codex-app-mirror/releases#release-codex-app-26.707.71524 and done with it.

AleksandrRogov · 3 days ago

I can confirm the same issue with a different Corsair HID device.

Environment

  • ChatGPT/Codex Windows app: 26.715.2305.0
  • Desktop/internal version: 26.715.21425
  • Windows 11

Hardware

  • Corsair K55 RGB keyboard
  • No Corsair iCUE installed
  • Connection path: PC → USB hub → keyboard

I captured a WinDbg hang dump while the app was unresponsive. The CrBrowserMain thread was blocked in:

NtDeviceIoControlFile
→ DeviceIoControl
→ HidD_GetManufacturerString
→ HID.node / node-hid
→ @worklouder/device-kit-oai

I isolated the keyboard by disconnecting devices individually. When the app hangs, unplugging only the Corsair K55 immediately restores responsiveness without restarting the app.

I also submitted diagnostics through the desktop feedback dialog:

no-active-thread-019f7131-dd51-7a73-b633-66083d8ba90a

I have the WinDbg stack output and a full hang dump available if needed.

ojiabc · 3 days ago

Additional privacy-safe reproduction

  • Codex Windows MSIX package: 26.715.2305.0; browser process reports Chromium 150.0.7871.124.
  • Windows recorded MoAppHang / Application Hang Event ID 1002 for ChatGPT.exe.
  • Available RAM was normal at the incident, so this was not an out-of-memory condition.
  • No dump, session data, file paths, account data, timestamp, or device identifiers are attached or included here.

A ProcDump triage dump was captured only after the application window was confirmed hung. The hung process's UI thread was explicitly named CrBrowserMain and was blocked in this native call chain:

ntdll!NtDeviceIoControlFile
KernelBase!DeviceIoControl
kernel32!DeviceIoControlImplementation
hid.dll!DeviceIoControlHelper
hid.dll!HidD_GetSerialNumberString
HID.node + offset

The installed package contains the bundled chain @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> node-hid -> HID.node. This independently confirms that the Codex browser/main UI thread can synchronously block while an optional HID integration reads a device serial number.

The HID devices reported normal PnP status at capture time. The implementation should avoid serial-number/device enumeration on the browser UI thread and ensure an unresponsive HID driver/device cannot block it.

windsel · 3 days ago

Another affected user with a closely matching failure on the same package version.

Environment

  • Windows 11 Pro 25H2 (Build 26200.8655)
  • Intel Core i7-12700KF
  • NVIDIA RTX 3070
  • 32 GB RAM
  • Package: OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0
  • ChatGPT.exe version: 150.0.7871.124

Behavior

  • The app worked normally before the latest update.
  • After updating, it freezes immediately after launch and Windows marks it as Not Responding.
  • CPU usage stays near 0% while hung; memory remains around 400–450 MB.
  • The UI does not recover.

Troubleshooting already tried

  • Reinstalled the app from the official OpenAI website.
  • Restarted Windows.
  • Renamed %USERPROFILE%\.codex, which allowed one fresh start/sign-in.
  • Restored the original .codex; projects and sessions reappeared, confirming the local project data is intact, but the startup freeze returned.

Event Viewer

Windows records:

  • Application Hang, Event ID 1002
  • Event name: MoAppHang
  • Fault bucket: 2020343198852172000
  • Hang type: Unknown

The executable path is:
C:\Program Files\WindowsApps\OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe

This completely blocks access to existing Codex projects. The symptoms and package version appear to match this issue very closely.

DKasza · 3 days ago

After updating to version 26.715.3651.0 through the Microsoft Store, the HID-related issue is still present. The app may work briefly after launch, but it eventually becomes unresponsive again with the same freezing behavior.

mm0nst3r · 3 days ago

The temporary bypass tested in #33912 may also be useful for confirming or escaping this permanent-hang variant. It prevents the Work Louder discovery call entirely, so it avoids entering the bundled node-hid enumeration path. I validated it against periodic main-thread stalls; I did not reproduce the permanently wedged HID device described in this issue.

The current OpenAI.Codex 26.715.3651.0 package still contains the same discovery loop.

Unsupported diagnostic workaround used on a copied runtime only:

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

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

with [], padded with ASCII spaces to exactly the original byte length. In context this becomes [t] = [], reporting no Codex Micro device without changing the archive's size or file offsets.

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

The patched archive launched normally. As expected, Codex Micro detection is disabled in that runtime.

Measured result while an original and patched instance ran simultaneously, using independent 26-second window-message-loop probes:

| 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 user also immediately reported that the patched instance felt substantially better. Full ETW diagnosis and the controlled workaround result are in #33912.

This is not an appropriate product fix and users should not have to modify application archives. It is supporting evidence that bypassing only findWLDevices() removes the UI-thread problem. The proper fix remains moving HID discovery off the Electron main thread, adding timeouts around device operations, and avoiding repeated polling when the optional device is absent or unresponsive.

QinMoXX · 3 days ago

The same issue occurs in the new version.

ganada001 · 3 days ago

Additional confirmed hardware trigger: a Logitech wireless-charging mouse pad.

Environment/behavior:

  • Windows Codex/ChatGPT desktop app becomes completely unresponsive (Not Responding).
  • All USB devices are connected directly to motherboard USB ports, not through a hub.
  • A Logitech wireless-charging mouse pad is connected and used as the mouse receiver/charging device.
  • The hang appears when the wireless charging/device connection briefly drops and reconnects during normal mouse use.
  • Restarting Windows, repairing/resetting the app, and reinstalling the app did not resolve it.

A/B isolation:

  1. Connect and use the Logitech wireless-charging mouse pad.
  2. Launch Codex and use the mouse normally.
  3. When the pad's charging/device state briefly disconnects/reconnects, the entire Codex/ChatGPT window can hang.
  4. Completely disconnect the charging pad.
  5. Use the same mouse through its separate USB receiver or a wired connection.
  6. The problem disappears completely and Codex remains responsive.

This strongly suggests that the charging pad's USB/HID state-change event triggers the synchronous HID enumeration path described in this issue. The pad itself may be functioning normally for its intended use; Codex should tolerate HID disconnect/reconnect events without blocking the Electron main/UI thread.

This may affect other users with Logitech wireless-charging mouse pads or similar peripherals that periodically change HID/device state. Suggested handling:

  • move HID discovery off the main thread;
  • add per-device timeouts;
  • debounce device-change events;
  • skip or quarantine devices that fail to respond;
  • avoid retry loops that can freeze the full application.
jtabox · 2 days ago

Is this being worked on? The Codex/ChatGPT app is essentially unusable at this point, I can't even close it without terminating its task. Will probably install a previous version at this point and wait for a fix.

DKasza · 2 days ago

After updating to Microsoft Store package 26.715.4045.0, the issue is still present.
ExeFileVersion and ProductVersion are still 150.0.7871.124, and the app continues to freeze with the same behavior.

JSKYOO · 2 days ago

I can add a controlled A/B confirmation with a REALFORCE R2 keyboard.

Environment:

  • Windows 11 25H2, build 26200.8875, x64
  • Microsoft Store package: OpenAI.Codex_26.715.3651.0_x64__2p2nqsd0c76g0
  • ChatGPT.exe file version: 150.0.7871.124
  • Keyboard: REALFORCE R2, exposed as a composite HID device with VID_0853&PID_0146 and USB interfaces MI_00, MI_01, and MI_02

When Codex was already showing “Not responding”, disconnecting only the REALFORCE R2 immediately restored the existing app window without restarting Codex or Windows. This was directly observable: the window became usable again immediately after the keyboard was unplugged.

As a control, I first disconnected a Razer DeathAdder V3 Pro mouse (VID_1532&PID_00B6); that did not restore the hung app. The recovery occurred only after disconnecting the REALFORCE R2.

This system previously also recorded repeated 0xc06d007f crashes on the older 26.707.x package, followed by repeated Application Hang Event ID 1002 reports on 26.715.x. The device-removal recovery makes the HID enumeration path a strong match for the current permanent-hang behavior.

edwardchan999-hash · 2 days ago

Independent reproduction confirming this remains present in the newer Microsoft Store package OpenAI.Codex_26.715.4045.0_x64 (ChatGPT.exe 150.0.7871.124) on Windows 11 x64 build 26200.

Additional hardware trigger

The blocking device here is a vendor-defined collection on a Corsair Gaming K55 RGB Keyboard:

HID\VID_1B1C&PID_1B3D&MI_00&COL03\7&25783E20&0&0002
  • HID usage page: FFC0, usage 0002
  • Generic Microsoft input.inf driver 10.0.26100.8875
  • Device Manager reported the interface started with no problem
  • Corsair/iCUE was not installed or running

This is the K55's vendor-defined Col03, not the ordinary typing collection (Col01) or consumer/volume collection (Col02).

Full-dump evidence

Sysinternals ProcDump captured three independent hung-window full dumps. In every inspected dump, the Electron main thread (CrBrowserMain) was blocked in:

ntdll!NtDeviceIoControlFile
KernelBase!DeviceIoControl
hid.dll!HidD_GetManufacturerString
HID.node
Electron / Node / V8 / Chrome main loop

The request was HID IOCTL 0x000B01BA (manufacturer-string query). The exact device path recovered from the first dump was:

\\?\HID#VID_1B1C&PID_1B3D&MI_00&Col03#7&25783e20&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}

The renderer processes and bundled Codex app-server remained alive. The full dumps are retained locally and are not attached publicly because they may contain sensitive process memory; they can be provided through an approved private support channel if needed.

Bundled versions in package 4045:

  • @worklouder/device-kit-oai 0.1.10
  • @worklouder/wl-device-kit 0.1.18
  • node-hid 3.3.0

The bundled discovery calls unfiltered synchronous nodeHID.devices() before applying the Work Louder vendor/device filter, and retries after 10 seconds when no supported device is found.

Narrow workaround verification

As a reversible test, only the exact K55 Col03 instance above was disabled with pnputil; the keyboard/USB parent and all other collections remained enabled. After reboot:

  • Codex remained responsive through the verification period with zero new AppHang events.
  • Normal typing still worked.
  • K55 volume controls still worked.
  • Col03 remained disabled across reboot.

This confirms the issue is not limited to a Corsair mouse or to CreateFileW: an unrelated composite keyboard can block later in HidD_GetManufacturerString, and the UI-thread architecture makes either stall fatal to app responsiveness.

The most robust fix still appears to be prefiltering before opening unrelated HID interfaces, moving discovery off the Electron main thread, adding bounded per-device timeouts/cancellation, backing off after failure, and providing a supported way to disable optional Codex Micro discovery.

H0nok4 · 2 days ago

Confirmed on Microsoft Store package 26.715.4045.0, Windows 11 Pro 24H2 build 26100.2033, with a Corsair K68 (VID_1B1C / PID_1B3F). This is the same keyboard model reported in #33924.

Additional evidence from this machine:

  • 26.707.12708.0 was stable. Microsoft Store switched the installed package to 26.715.2305.0 at 2026-07-17 18:03 local time; the first matching AppHangTransient occurred at 21:15. There were no K68 PnP, driver-install, or device-configuration changes at the onset.
  • The same UI hang still reproduces after updating to 26.715.4045.0.
  • A separate node-hid 3.3.0 probe filtered to this K68 eventually blocks indefinitely while enumerating it; other HID devices on the same system complete in approximately 8–119 ms.
  • Restarting only the K68 USB composite device restores K68 enumeration to approximately 22–37 ms and makes the already-running Codex main window responsive again, without restarting Codex.
  • Disabling only the K68 MI_01 vendor interface is insufficient: the MI_00 collections remain present and the hang can recur.
  • During a captured hang, the main-window process used only about 281 MB private memory and the system had about 15.8 GB available, ruling out resource exhaustion.
  • Read-only inspection of the current 4045 package shows the same Codex Micro 10-second reconnect loop. WLDeviceDiscovery.findWLDevices() still calls synchronous, unfiltered nodeHID.devices() before filtering for Work Louder hardware.

This independently corroborates the root cause described in #33912. The K68 is a compatibility trigger, but the product defect is unbounded synchronous all-HID enumeration on the Electron main thread. Discovery should be moved to a terminable utility/child process with a hard timeout/circuit breaker, and descriptor access should be restricted by the target VID/PID. Until that ships, a server-side gate disable or supported local “disable Codex Micro discovery” setting would prevent the entire UI from being taken down by one wedged HID endpoint.

AdityaRajeshGadgil · 2 days ago

Independent confirmation on a Corsair K95 RGB Gaming Keyboard with the current Microsoft Store build.

Environment

  • Codex package: OpenAI.Codex_26.715.4045.0_x64
  • Internal app version: 26.715.31925 (build 5551)
  • Windows 11 Pro 25H2, build 26200.8655, x64
  • Keyboard: Corsair K95 RGB Gaming Keyboard, VID_1B1C&PID_1B11
  • iCUE: 5.48.58
  • K95 firmware: 3.08 (force-reinstalled during diagnosis)

Timing change does not remove the trigger

Before the firmware reset, Codex often hung immediately at launch. After force-reinstalling K95 firmware, Codex could open normally but would hang after roughly 2–3 minutes. The changed onset initially looked like a second issue, but the same HID signature appeared during the delayed hang.

Controlled evidence

The K95 exposes five HID interfaces on this system. During the Codex freeze:

  • an out-of-process descriptor probe showed all five K95 interfaces stalled together while unrelated HID interfaces returned;
  • the Codex Electron main thread was blocked in:
ntdll!NtDeviceIoControlFile
KernelBase!DeviceIoControl
hid.dll!HidD_GetManufacturerString
HID.node
Electron / Chromium main loop
  • restarting only the K95 USB composite parent with pnputil /restart-device made the already-running Codex window responsive immediately—no Codex restart and no Windows restart;
  • after the device-only restart, all five K95 descriptor reads returned normally again.

This reproduces on package 4045 even with current iCUE and freshly installed keyboard firmware. The keyboard is a compatibility trigger, but the product-level failure remains unbounded synchronous all-device HID enumeration on the Electron main thread.

Narrow workaround verification

A reversible per-user launcher was tested that leaves the signed MSIX, drivers, iCUE, account data, and project state untouched. It replaces only:

WLDeviceDiscovery.findWLDevices() -> []

The inherited serial bootloader discovery and all unrelated HID behavior remain intact. With only optional normal Codex Micro / Work Louder HID discovery bypassed:

  • the signed-in app and all existing Projects loaded normally;
  • UI navigation remained responsive;
  • repeated runs passed the previous failure window, including 424 s, 698+ s, and a final 10+ minute soak;
  • all five K95 HID interfaces remained available to Windows.

This suggests the durable product fix should move discovery into a terminable worker/utility process with a hard timeout/circuit breaker (or otherwise avoid synchronous nodeHID.devices() on the main thread). A supported setting to disable optional Codex Micro discovery would also provide a safe interim mitigation.

NeedMeSomeAnimeTiddy · 2 days ago

I can reliably reproduce this with a Corsair K70 Rapidfire keyboard connected in its normal USB mode.

Environment

  • Windows 10 x64, build 19045
  • New unified ChatGPT desktop app
  • Last known working version: 26.707.91948
  • First known broken version: 26.715.21316
  • Also reproduced on: 26.715.2305.0 and 26.715.4045.0
  • ChatGPT.exe version in the affected builds: 150.0.7871.124
  • Corsair keyboard USB ID: VID_1B1C&PID_1B3A
  • ChatGPT Plus account

Behaviour

After signing in, the app begins repeatedly freezing and showing “Not Responding”.

The freezes occur in a loop, roughly every 10 seconds. Individual freezes can last approximately 75 seconds or longer. The rest of Windows remains responsive.

The app may temporarily work after unplugging and reconnecting the keyboard, but the issue eventually returns.

Reproduction steps

  1. Connect the Corsair keyboard with its physical polling/BIOS switch set to normal mode.
  2. Launch the new ChatGPT desktop app.
  3. Sign in.
  4. Leave the app open.
  5. Within a short period, the app begins repeatedly freezing.
  6. Unplug the Corsair keyboard while the app is frozen.
  7. The app recovers and begins working again.

Confirmed workaround

Unplugging and Plugging the keyboard back in resets the freeze timer (~1 hour), or using the physical profile switch on the back of the keyboard to switch profiles, which restarts the keyboard also does the trick.

Corsair HID interfaces

The keyboard exposes these interfaces:

  • HID Keyboard Device:

HID\VID_1B1C&PID_1B3A&MI_00&COL01

  • Consumer control:

HID\VID_1B1C&PID_1B3A&MI_00&COL02

  • Vendor-defined:

HID\VID_1B1C&PID_1B3A&MI_00&COL03

  • Vendor-defined:

HID\VID_1B1C&PID_1B3A&MI_00&COL04

  • Additional vendor-defined interface:

HID\VID_1B1C&PID_1B3A&MI_01

Frozen thread stack

Process Explorer captured the following stack while ChatGPT was Not Responding:

ntoskrnl.exe!KeSynchronizeExecution
ntoskrnl.exe!KeWaitForSingleObject
ntoskrnl.exe!ExWaitForRundownProtectionRelease
hidusb.sys
HIDCLASS.SYS
ntoskrnl.exe!IofCallDriver
kbdhid.sys
ntoskrnl.exe!IofCallDriver
kbdclass.sys
ntoskrnl.exe!NtDeviceIoControlFile
!NtDeviceIoControlFile
blackShyan · 1 day ago

Independent reproduction: Logitech G102 LIGHTSYNC mouse (VID_046D&PID_C092)

I can independently reproduce the same HID-triggered Windows Desktop hang with a Logitech G102 LIGHTSYNC gaming mouse, rather than a Corsair device.

Environment

  • Windows 11 25H2, OS build 26200.8875
  • July 14, 2026 cumulative update KB5101650
  • ChatGPT/Codex Desktop MSIX 26.715.4045.0
  • Bundled app-server 0.145.0-alpha.18
  • Device: Logitech G102 LIGHTSYNC Gaming Mouse, USB\VID_046D&PID_C092
  • The physical keyboard is a standard Microsoft keyboard and is not the trigger.

Exact reproduction

  1. Launch the Windows Desktop app with the G102 connected.
  2. The app initially works normally.
  3. After some time, the entire Desktop UI becomes Not Responding. Agent tasks may continue in the background, and Codex CLI remains fully functional.
  4. While the Desktop window is hung, unplug the G102 USB cable.
  5. The ChatGPT/Codex UI becomes responsive immediately at device removal, without restarting the app.
  6. Reconnect the mouse. The app works again temporarily, then enters the same hang after some time.
  7. Unplugging it again immediately releases the hang.

Logging out through Codex CLI and signing back into the Desktop app also resets the condition temporarily, but the hardware A/B test shows this is not primarily an authentication problem.

Relevant PnP enumeration

This mouse is not exposed as only one mouse interface. Windows currently enumerates the same physical device as:

  • HID-compliant mouse — MI_00
  • HID Keyboard Device — MI_01&COL01
  • HID-compliant consumer control device — MI_01&COL02
  • HID-compliant system controller — MI_01&COL03
  • two vendor-defined HID collections — MI_01&COL04 and COL05
  • two USB Input Device interfaces
  • a Windows HID LampArray device

Windows Dynamic Lighting is enabled on this machine, and Logitech LampArray Service is running. The G102/G203 family also uses a 1000 Hz USB report rate by default. These may be useful dimensions for an internal repro, although I have not yet isolated whether the blocking interface is a normal HID collection, the vendor-defined collections, or LampArray.

The mouse continues to work normally in other applications. This case therefore suggests that the issue may not require a permanently wedged device: a periodic HID/accessory enumeration or open on the Electron main thread may enter the blocked state after the app has been running for a while, and physical device removal releases the wait.

Local Desktop evidence

The current 26.715.4045.0 Desktop log records:

  • [electron-sampler] Failed to collect child process snapshot during the affected session
  • bursts of ResizeObserver loop completed with undelivered notifications
  • Appshot hotkey inactive configured=true enabled=true platform=win32

Those may be secondary symptoms or load amplifiers; the immediate USB-removal recovery is the strongest causal signal.

Corroborating reports

A current Reddit thread contains the same immediate-unplug recovery with Corsair K55, K63, K70, and K95 keyboards. One user reports that closing iCUE does not help, while physically unplugging/replugging the keyboard restores the app temporarily:

https://www.reddit.com/r/codex/comments/1uzvw77/codexchatgpt_windows_app_keeps_freezing_and/

This Logitech mouse reproduction broadens the affected class from a particular Corsair keyboard/device to composite gaming HID devices generally.

Requested fix

Please keep HID/accessory enumeration off the Electron main/UI thread, apply a bounded timeout per HID interface open/query, and skip/log a device that does not respond instead of retrying synchronously. Device arrival/removal and periodic re-enumeration should also be safe against a single stalled HID collection.

blackShyan · 1 day ago

Follow-up A/B result: disabling Windows Dynamic Lighting prevents recurrence

A new controlled observation further narrows the trigger toward the Windows Dynamic Lighting / HID LampArray path.

Test

  • The Logitech G102 LIGHTSYNC remained physically connected and usable.
  • No mouse, keyboard, USB port, ChatGPT account, project, or Codex setting was changed.
  • In Windows 11, Settings → Personalization → Dynamic Lighting → “Use Dynamic Lighting on my devices” was turned Off.
  • Before this change, the app repeatedly became Not Responding after the usual delay, and unplugging the G102 released the hang immediately.
  • After disabling Dynamic Lighting, the hang has not recurred during the comparable observation period so far.

This is currently a preliminary but strong A/B result; observation will continue. It is more specific than the earlier unplug test because the physical composite HID device remains connected. The change disables the LampArray control path while preserving normal mouse input.

Updated hypothesis

For this Logitech case, the blocking interface may be the G102's HID LampArray / Dynamic Lighting integration, or an interaction between periodic Codex HID/accessory enumeration and the Logitech LampArray service, rather than the standard mouse interface or authentication state.

Relevant local state before the workaround:

  • G102 exposes a USB\VID_046D&PID_C092\LAMPARRAY device.
  • Windows HKCU\Software\Microsoft\Lighting\AmbientLightingEnabled was 1.
  • Logitech LampArray Service was running.
  • Physically removing the mouse tore down both its normal HID collections and LampArray, so the earlier unplug recovery could not distinguish between them.
  • This new test isolates LampArray/Dynamic Lighting much more strongly.

Suggested maintainer repro matrix

  1. G102 connected + Dynamic Lighting enabled: wait for periodic hang.
  2. Same device and app session conditions + Dynamic Lighting disabled: verify no hang.
  3. Instrument HID.node enumeration/open timing by usage page and interface path, especially the Lighting and Illumination / LampArray collection.
  4. Test behavior while logi_lamparray_service owns or queries the LampArray interface.
  5. Ensure LampArray enumeration/open is asynchronous and bounded by a timeout, and that a busy/stalled lighting collection is skipped without blocking Electron's main thread.

This workaround currently appears substantially better than repeated USB unplug/replug because normal mouse functionality remains available.

blackShyan · 1 day ago

Correction to the Dynamic Lighting A/B observation

This corrects my earlier follow-up comment: https://github.com/openai/codex/issues/33780#issuecomment-5014271562

After a longer observation period, the ChatGPT/Codex Desktop UI did hang again while Windows Dynamic Lighting was still disabled.

Confirmed state at recurrence

  • Windows HKCU\Software\Microsoft\Lighting\AmbientLightingEnabled remained 0.
  • The Logitech G102 remained connected.
  • All G102 composite HID collections and its LampArray device remained present.
  • Logitech LampArray Service remained running.
  • When the Desktop UI became Not Responding, physically unplugging and reconnecting the G102 again restored the existing app window immediately.

Corrected conclusion

The previous “no recurrence after disabling Dynamic Lighting” result was a false positive caused by an insufficient observation window, or at most a timing change. Disabling Windows Dynamic Lighting does not prevent this hang and should not be considered a reliable workaround.

The evidence does not currently isolate LampArray as the blocking collection. LampArray or the Logitech lighting service may still affect timing, but the stronger and durable conclusion remains:

  • the G102 is a composite HID device;
  • the Desktop app periodically performs synchronous, unfiltered HID discovery for optional Codex Micro / Work Louder hardware;
  • one of the device's HID queries can eventually stall;
  • because discovery runs on Electron's main thread without a bounded timeout, the whole Desktop UI becomes unresponsive;
  • resetting the physical USB composite device cancels/resets the stuck HID state and releases the UI immediately.

The only consistently confirmed recovery on this machine is a full G102 USB disconnect/reconnect. Authentication reset and Dynamic Lighting changes are temporary or non-causal observations.

Please treat the earlier Dynamic Lighting isolation claim as withdrawn. The requested product fix remains unchanged: prefilter supported hardware before descriptor access, move discovery out of the Electron main thread into a terminable worker/utility process, and enforce hard per-device timeouts/circuit breaking for HID enumeration and descriptor reads.

DrB1961 · 1 day ago

I can reproduce what appears to be the same problem with Corsair keyboard and mouse hardware.

ChatGPT Plus

Processor 12th Gen Intel(R) Core(TM) i7-12700KF (3.60 GHz)
Installed RAM 32.0 GB (31.9 GB usable)
Graphics card NVIDIA GeForce RTX 3070 (8 GB)
System type 64-bit operating system, x64-based processor
Pen and touch Pen support

Edition Windows 11 Pro
Version 25H2
Installed on ‎25/‎01/‎2025
OS build 26200.8875
Experience Windows Feature Experience Pack 1000.26100.334.0

On Windows, Codex Desktop hangs while enumerating the connected Corsair HID devices (K70 and mouse). Process inspection indicates that execution stalls around HidD_GetManufacturerString during manufacturer-string probing. The application eventually becomes briefly responsive, then retries the HID enumeration and freezes again.

Replacing the Corsair keyboard and mouse with a cheap AliExpress, non-Corsair, Machinivo RGB mechanical keyboard, and similar cheap RGB mouse, resolves the problem. Codex Desktop then launches and operates normally.

This suggests that the HID enumeration path may synchronously block not only while opening a device or retrieving its product string, but also while retrieving the manufacturer string. The per-device enumeration and string-probing operations may require timeouts and should not execute on the main UI thread.

sargearmstrong · 1 day ago

Insane find, I confirm unplugging my Corsair M65 and moving to USB3.0 seems to have solved the issue. I do not have iCUE installed, so wasn't hopeful.. but wow, just wow. Thanks.🤞

Edit: Issue recurred with corsair mouse in usb3.0 port, so have replaced mouse with offbrand and things are working normally.

jtabox · 1 day ago

So what does one need to do to work with Codex app? Disconnect my Corsair peripherals? I have both a Corsair keyboard, mouse and a fan controller. And running iCUE too. It's not so practical to disconnect everything or mess around with USB ports.

DrB1961 · 1 day ago

Switch out the KB and Mouse to anything else or, as one user reported, plug the Corsair KB into USB3. The fan controller should not be an issue.

edwardchan999-hash · 1 day ago

Follow-up: disabling one K55 collection only moved the main-thread block

I previously reported a narrow workaround on this same CNU system: disabling the Corsair K55 vendor-defined Col03 collection while preserving typing and volume controls. That was only a temporary/partial success.

Codex Desktop froze again on package OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0 (ChatGPT.exe 150.0.7871.124). A fresh ProcDump hung-window capture shows the same cause, now on a different collection from the same keyboard.

Fresh main-thread evidence

The triggered main-process dump caught Electron's main thread in:

ntdll!NtDeviceIoControlFile
KernelBase!DeviceIoControl
hid.dll
hid.dll!HidD_GetSerialNumberString
HID.node
chrome.dll / Node / V8 / Electron main loop

A companion full main-process dump independently caught the same thread in hid.dll!HidD_GetManufacturerString.

The exact interface path present on the blocked stack was:

\\?\HID#VID_1B1C&PID_1B3D&MI_00&Col02#7&25783e20&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}

Windows identifies this instance as the K55 HID-compliant consumer control device (COL02). This collection carries the user's working volume/media controls, so disabling it is not an acceptable workaround. Col03 remained disabled throughout this fresh reproduction.

Both renderer first threads were waiting normally in ZwWaitForSingleObject; the whole-window hang was the main-thread HID request. A PowerPoint artifact preview happened to be visible at the time, but it was not the blocking renderer path.

Activation/retry finding

Read-only inspection of the packaged app confirms that the Codex Micro / Work Louder service calls WLDeviceDiscovery.findWLDevices([DeviceType.Project2077]) and schedules another attempt after 10 seconds when no supported device is found. The Codex Micro bridge/UI is enabled by a remotely evaluated feature gate on this client, and package 4045 exposes no supported local off switch.

This result demonstrates that disabling unrelated HID collections one by one only moves the synchronous global scan to another interface. The most useful immediate mitigation would be to gate Codex Micro discovery off on affected Windows clients or expose a supported user setting. The durable fix remains to prefilter supported devices before descriptor access, run discovery outside Electron's main process/thread, and enforce hard per-interface timeouts/circuit breaking.

Raw full-memory dumps remain local because they may contain private task data, but sanitized stack/module details can be provided if maintainers need more.

mm0nst3r · 1 day ago

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.

jtabox · 1 day ago
Switch out the KB and Mouse to anything else or, as one user reported, plug the Corsair KB into USB3. The fan controller should not be an issue.

I mean sure but this doesn't seem like a viable solution. If every time I have to open this one specific app I need to switch out both my keyboard and mouse then I'm gonna cancel my sub and move on to something else, f that noise.

theslamduncan · 22 hours ago

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.

memesalot · 22 hours ago

Same issue here.

enguerrand1985-cloud · 19 hours ago

Reproducible K55 trigger and software recovery workaround

I can confirm this issue with a Corsair Gaming K55 RGB Keyboard (VID_1B1C&PID_1B3D) on the Windows Codex/ChatGPT desktop app.

Controlled observations:

  • Unplugging a webcam and several other devices from the same USB hub did not recover the frozen UI.
  • Unplugging only the K55 recovered the already-frozen app immediately.
  • Reconnecting the K55 restored normal UI responsiveness, but the hang returned later.
  • The issue also recurred with the K55 connected directly to a motherboard USB port, so the USB hub is not required to trigger it.
  • A fresh .codex profile, account reconnect, repair, reset, reinstall, and app updates did not resolve it.

A useful temporary workaround is a targeted PnP restart of the physical K55 device. This reproduces the effect of unplugging/replugging the keyboard without physically disconnecting it and without restarting Codex. It has successfully recovered the frozen UI five times so far.

Run from an elevated PowerShell prompt:

$pattern = 'USB\VID_1B1C&PID_1B3D\*'
$expected = 'Corsair Gaming K55 RGB Keyboard'

$devices = @(
    Get-PnpDevice -PresentOnly -Class USB |
        Where-Object InstanceId -like $pattern |
        Where-Object {
            $p = Get-PnpDeviceProperty -InstanceId $_.InstanceId `
                -KeyName 'DEVPKEY_Device_BusReportedDeviceDesc' `
                -ErrorAction SilentlyContinue
            $p.Data -eq $expected
        }
)

if ($devices.Count -ne 1) {
    throw "Safety stop: expected exactly one physical K55, found $($devices.Count)."
}

& "$env:SystemRoot\System32\pnputil.exe" /restart-device $devices[0].InstanceId
if ($LASTEXITCODE -ne 0) {
    throw "PnPUtil failed with exit code $LASTEXITCODE."
}

Notes:

  • Administrator rights are required.
  • The keyboard briefly disconnects while Windows restarts the device.
  • This was tested only with the K55 identifiers above; other users should substitute and verify their own exact physical device.
  • This is only a recovery workaround. The underlying issue remains: a HID operation should not be able to block the Electron main/UI thread.
victorsbd · 16 hours ago

Preliminary positive result on 26.715.7063.0

I have now updated the same affected Windows installation from 26.715.2305.0 to:

PackageVersion: 26.715.7063.0
PackageFullName: OpenAI.Codex_26.715.7063.0_x64__2p2nqsd0c76g0
ChatGPT.exe FileVersion: 150.0.7871.124
ChatGPT.exe ProductVersion: 150.0.7871.124

This is the same system and Corsair Gaming K63 (VID_1B1C&PID_1B40) described in my earlier comment.

After installing 26.715.7063.0:

  • I switched the K63 back from BIOS mode to its normal composite HID mode;
  • the severe periodic lag and prolonged freezes that previously made the app unusable have not reproduced so far;
  • active conversations remain responsive with the K63 connected in normal mode;
  • the previous first-open stall when opening a conversation whose history had not yet been loaded also appears to have disappeared;
  • switching between both previously loaded and not-yet-loaded conversations now appears responsive.

This is a preliminary observation immediately after updating, not yet a long-duration soak result. I will follow up if the HID-related stalls or freezes return, but 26.715.7063.0 currently appears to mitigate both the severe Corsair/HID behavior and the separate first-load conversation stall on this machine.

jtabox · 15 hours ago

Aye, updated to the latest version from Store and it seems to have been fixed. At least it won't hang directly at boot as it did with the previous version.

daleforbes · 12 hours ago

Preliminary positive result on 26.715.7063.0

I reconnected the original Corsair Harpoon RGB PRO (VID_1B1C&PID_1B75) that previously reproduced the HID-related Codex freezes. It is operating in its normal composite configuration with all seven USB/HID entries present.

So far, the prior hangs and system-input stalls have not returned during normal Codex use. A separate 90-second responsiveness probe collected 308 samples with zero nonresponsive samples while the Harpoon remained connected. No new ChatGPT.exe Application Hang or Application Error events were recorded.

This is an initial smoke test rather than a long-duration soak result. I’ll follow up if the problem returns or after several extended Unity/Codex sessions.