Windows Codex freezes with UGREEN USB switch and recovers immediately when unplugged

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

• #33780
• #33912
• #33909

Powered by Codex Action

Independent reproduction on 26.715.4045.0 (Corsair K68, no USB switch)

I reproduced the same failure mode on a separate Windows system with a directly connected Corsair K68. A controlled gate-off A/B test strongly isolates the freeze to the Codex Micro HID-discovery path.

Environment

• Codex Microsoft Store package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
• Windows 11 Pro x64, version 10.0.26200
• Corsair K68: VID_1B1C / PID_1B3F
• No UGREEN switch or VID_05E3 hub was present
• Windows exposed five K68 HID collections: one keyboard, one consumer-control device, and three vendor-defined devices

Unmodified-build observations

On the unmodified Store build:

• The Electron main process loaded HID.node and hid.dll through the bundled @worklouder/device-kit-oai dependency chain.
• On one fresh launch, the main window reported nonresponsive for all 113 samples collected over 30 seconds.
• On a warm launch, the window initially responded and transitioned to Responding=False after approximately 15 seconds.
• Disabling all configured plugins did not remove the failure (34 of 51 samples were nonresponsive over 20 seconds).
• Launching with --disable-gpu did not remove it either (27 of 48 samples were nonresponsive over 20 seconds).
• No taskkill.exe executions or WMI CPU spike occurred during the fresh reproduction, which distinguishes this instance from the separate process-storm behavior reported elsewhere.

Inspection of the packaged JavaScript showed this sequence:

1. Renderer gate 3207467860 mounts the Codex Micro bridge.
2. The bridge immediately calls codexMicro.getState().
3. The main-process service imports @worklouder/device-kit-oai and calls WLDeviceDiscovery.findWLDevices([DeviceType.Project2077]).
4. When no supported device is found, reconnect is scheduled after 10,000 ms.

That timing matches the observed periodic loss of responsiveness.

Controlled gate-off A/B

I copied the same installed build to a user-local directory, retained the same Codex user profile, and changed only the two renderer expressions checking gate 3207467860 to the boolean constant false. The Microsoft Store package itself was not modified.

Archive identifiers:

Original app.asar SHA-256:
4F81FE8CFADD0ECD1D55A46F4B101B1DB70ABBB372B63A0120218B1D868008A3

Gate-off app.asar SHA-256:
1E1628A212687E5C5BF34E29B79557DEAE247BB916C9ADC7F278D733AC88C852

Changed expression offsets within app.asar:
23773659
23800151

Results with the gate disabled:

• Three automated UI-message-pump runs totaling 125 seconds
• 478 samples
• Zero Responding=False observations
• Zero SendMessageTimeout(WM_NULL) failures using a 250 ms timeout
• Maximum observed probe latency: 16.1 ms
• Zero new Windows Application events 1000, 1001, or 1002 for ChatGPT.exe during the measured process run
• Neither HID.node nor hid.dll was loaded in the repaired main process

This test does not identify which individual K68 HID collection stalls enumeration. It does show that, on this machine, preventing the Codex Micro bridge from mounting removes the freeze while keeping the same application build, profile, account, keyboard, and other configuration.

This also suggests the issue is not limited to UGREEN/Genesys USB switches. Moving HID enumeration off the Electron main thread, using the asynchronous node-hid API, and backing off or disabling discovery after a stalled/failed attempt would prevent an optional hardware integration from blocking the desktop UI.