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

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?

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).
Launch the Codex Windows app (26.715.2305.0, Microsoft Store).
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.
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

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

[Windows x64] Codex Micro HID.node repeatedly raises 0xC06D007F and causes UI stutter #33529

Powered by Codex Action

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

Impossible to work after the update, same problem

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

Start Codex with the K63 connected in normal mode.
Use Codex normally.
After some time, Codex begins experiencing severe intermittent stalls and becomes non-responsive for several seconds at a time.
Disconnect only the K63 USB cable.
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.

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

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.

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

Prevent optional HID/accessory discovery from blocking the Electron main/UI thread, and apply a timeout per device.
Add a supported Codex setting or safe-start option to disable hardware acceleration.
Ensure the persisted hardware-acceleration preference is honored before GPU/renderer initialization.
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.

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:

Initially blocked on HID\VID_1B1C&PID_1B36&MI_00&COL04 (\Device\0000006f).
After temporarily disabling only COL04, the block moved to HID\VID_1B1C&PID_1B36&MI_01 (\Device\00000071).
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.

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

With iCUE active, restarting Codex reproduced the frozen UI and four Harpoon descriptor timeouts.
Stopping iCUE after the device had entered the bad state did not unwind it.
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.
Codex then passed 42/42 responsive samples across more than four 10-second discovery/reconnect intervals.
Starting iCUE after Codex was already running remained healthy: another 42/42 responsive samples, with all four interfaces still at about 6 ms.
Restarting Codex while iCUE was active immediately reproduced the hang and four 4-second timeouts.
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.

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.

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.

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.

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.

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:

Fully close Codex.
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.
Replace the single expression:
```
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.
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.

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.

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.

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.

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.

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.

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.

Updated independent reproduction: K70 RGB `PID_1B13` still correlates with hangs on `26.715.8383.0`, but the Windows discovery implementation has changed

I am amending this report after inspecting the currently installed 26.715.8383.0 package. The keyboard A/B remains valid, but the current build no longer follows the same Windows node-hid discovery path documented for the earlier builds.

Environment

Current running Codex Desktop package: OpenAI.Codex_26.715.8383.0_x64__2p2nqsd0c76g0
Windows x64 25H2, build 26200.8894
Corsair K70 RGB Gaming Keyboard: VID_1B1C / PID_1B13 / REV_0308
Corsair iCUE: 5.48.58
Direct USB connection to the Intel XHCI root hub (VID8086 / PID7A60), ACPI port XHCI.RHUB.HS04
No external USB switch or intermediary hub in the K70 device-parent path

Current user-observed A/B

With the K70 in normal mode, the Codex/ChatGPT window eventually becomes unresponsive while the rest of Windows remains usable.
Moving the keyboard to the direct Intel root-hub port did not eliminate the symptom.
Switching the same physical K70 to BIOS mode restores usability without changing the Codex task/session.
Switching BIOS -> normal may look fixed temporarily, but the symptom later recurs.
The repeated USB removal/arrival events in this machine's history were mostly manual recovery/mode-change attempts made after the UI froze, not spontaneous disconnects proven to cause the original hang.

In BIOS mode, current PnP state is:

USB\VID_1B1C&PID_1B13&REV_0308
Parent: USB\ROOT_HUB30 (Intel VID8086/PID7A60)
Location: ACPI ... XHCI.RHUB.HS04
Children: one standard HID keyboard endpoint
Device problem code: 0

Important implementation difference in `26.715.8383.0`

Inspection of the packaged codex-micro-service shows:

Windows no longer calls WLDeviceDiscovery.findWLDevices() or nodeHID.devices().
The Windows path calls await hid-topology-watcher.node.findCodexMicroInterfaces().
node-hid.devicesAsync(VID, PID) is now used only on Linux in this service.
The native Windows addon imports the Node-API Promise/AsyncWork functions (napi_create_async_work, napi_queue_async_work, etc.), which is evidence that interface discovery is already dispatched as asynchronous native work.
Native inspection shows that the addon matches Codex Micro (VID_303A / PID_8360) before calling CreateFileW; the topology callback uses the same matcher. The K70 (VID_1B1C) is therefore rejected before the addon opens or queries the interface.
The addon imports HidD_GetAttributes, HidD_GetPreparsedData, and HidP_GetCaps, but not the manufacturer/product/serial string probes implicated in the earlier global enumeration path.
The Electron main process currently loads hid-topology-watcher.node and HID.DLL.

This materially changes the diagnosis for the latest build: the K70/BIOS correlation still points toward HID topology or descriptor handling, but there is no new native stack or Event ID 1002 proving that 26.715.8383.0 blocks the Electron main thread in the same old HID.node -> hid.dll call chain.

Also, the Event ID 1001 entries timestamped July 21 on this machine are reprocessing an older WER report from 26.715.4045.0; they are not fresh WER proof for 26.715.8383.0. The current-build recurrence is a live user observation, not a captured stack.

Maintainer request and proposed hardening

Could a maintainer provide a diagnostic build/symbols or guidance for capturing a safe stack when the 26.715.8383.0 UI hangs? The next capture should determine whether the block is in:

native topology-watch initialization/callback handling;
the async worker completion path;
HID descriptor probing inside the private addon;
or a different main-process path that is merely reset by changing the composite HID topology.

If any native HID operation can remain stuck after asynchronous work has started, a JavaScript Promise.race() timeout cannot cancel it. A robust boundary would be:

Run the full topology watcher and descriptor scan in a dedicated Electron utilityProcess.
Use a watchdog to kill/recreate that process after a hard deadline.
Enforce single-flight discovery plus circuit breaker/cooldown and rate-limited logging.
Preserve the existing Codex Micro VID/PID prefilter as a tested invariant so non-target HID interfaces are never opened or queried.
Coalesce topology-event bursts.
Test a permanently blocked native scan, 100-event bursts, disposal/late replies, and x64/ARM64 packaging.

Small evidence correction to my comment above: the Windows Event ID 1001 entries timestamped July 21 are reprocessing an older WER report from package 26.715.4045.0; they are not fresh WER confirmation of a hang in 26.715.8383.0. The latest separately confirmed Application Hang/Event ID 1002 on this machine was July 20 at 16:06 on 26.715.4045.0.

The 26.715.8383.0 recurrence reported above is a live user-observed A/B result (normal mode hangs; switching the same K70 to BIOS mode restores usability), corroborated by the current process/package path and the current BIOS-mode PnP topology, but no new native stack or Event ID 1002 was captured for that build.

this still happens to me impossible to work

thanks for the detailed diagnostics here: the hid enumeration hang was fixed, and affected users confirmed it was resolved in 26.715.7063.0

closing as completed: please open a new issue with a current stack if this still reproduces

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Summary

Root cause (diagnosed locally)

Verification

Expected behavior

Related issues

Additional note (possibly a separate issue)

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 17, 2026

iAlexNT commented on Jul 17, 2026

chrislopez24 commented on Jul 17, 2026

victorsbd commented on Jul 17, 2026

Environment

Normal-mode HID layout

Reproduction and A/B isolation

BIOS-mode comparison

chrislopez24 commented on Jul 17, 2026

iAlexNT commented on Jul 17, 2026

Tomk77 commented on Jul 17, 2026

Environment

Version history and observed failures

26.707.9981.0

26.715.2305.0

Controlled GPU workaround on the older build

Requested fixes

Gjalswns commented on Jul 17, 2026

Environment

Main-thread and device-handle isolation

BIOS-mode A/B result

daleforbes commented on Jul 17, 2026

Environment

Main-thread evidence

Per-interface timing

Controlled startup-order reproduction

Confirmed workaround

daleforbes commented on Jul 17, 2026

daleforbes commented on Jul 17, 2026

Revised conclusion and workaround

24 remaining items

DrB1961 commented on Jul 19, 2026

edwardchan999-hash commented on Jul 19, 2026

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

Fresh main-thread evidence

Activation/retry finding

mm0nst3r commented on Jul 19, 2026

jtabox commented on Jul 20, 2026

theslamduncan commented on Jul 20, 2026

memesalot commented on Jul 20, 2026

enguerrand1985-cloud commented on Jul 20, 2026

Reproducible K55 trigger and software recovery workaround

victorsbd commented on Jul 20, 2026

Preliminary positive result on 26.715.7063.0

jtabox commented on Jul 20, 2026

daleforbes commented on Jul 20, 2026

Preliminary positive result on 26.715.7063.0

Tauri-EPO commented on Jul 21, 2026

Updated independent reproduction: K70 RGB PID_1B13 still correlates with hangs on 26.715.8383.0, but the Windows discovery implementation has changed

Environment

Current user-observed A/B

Important implementation difference in 26.715.8383.0

Maintainer request and proposed hardening

Tauri-EPO commented on Jul 21, 2026

gilbertgiles commented on Jul 22, 2026

chess-oai commented on Aug 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

`26.707.9981.0`

`26.715.2305.0`

Preliminary positive result on `26.715.7063.0`

Preliminary positive result on `26.715.7063.0`

Updated independent reproduction: K70 RGB `PID_1B13` still correlates with hangs on `26.715.8383.0`, but the Windows discovery implementation has changed

Important implementation difference in `26.715.8383.0`