What version of the Codex App are you using (From “About Codex” dialog)?
26.715.21425 (Microsoft Store package 26.715.2305.0)
What subscription do you have?
prolite (as reported by Codex diagnostics)
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
After a Windows update and a Codex update, the Microsoft Store Codex app becomes unusable: the window shows “Not responding”, the mouse pointer lags/stutters system-wide, and the app can eventually show “Oops, an error has occurred” with “Update ChatGPT” / “Try again”.
A CPU profile of the Electron main process captured 49,395 samples. 47,121 samples (95.4%) were inside showdevices in:
resources/app.asar/node_modules/@worklouder/device-kit-oai/node_modules/@worklouder/wl-device-kit/node_modules/node-hid/nodehid.js
The hot path is the synchronous call:
function showdevices() {
loadBinding();
return binding.devices.apply(HID, arguments);
}
The Work Louder integration calls nodeHID.devices() from findWLDevices([DeviceType.Project2077]) to discover Codex Micro hardware. HID enumeration runs synchronously on Electron's main/UI thread. When no matching device is found, discovery retries every 10 seconds. On this Windows/HID stack, enumeration can block for a long time, starving UI rendering, IPC, and app-server/Git requests.
No Work Louder/Codex Micro device is connected or needed on this machine.
What steps can reproduce the bug?
- Install/update the Codex app from the Microsoft Store to package
OpenAI.Codex_26.715.2305.0_x64.
- Use Windows 11 build 26200 x64 with normal USB/HID devices connected, but no Work Louder/Codex Micro (
Project2077) device.
- Launch the Codex app.
- During startup, the optional Work Louder service calls
findWLDevices([DeviceType.Project2077]), which calls synchronous nodeHID.devices() on the Electron main thread.
- Observe that the app stops responding and the mouse cursor stutters. When no matching device is found, the scan is scheduled again every 10 seconds.
Workaround verified locally: preload a narrowly scoped shim for ChatGPT.exe that returns an empty device list only for the Work Louder package's node-hid import. With that optional discovery disabled, the app launches normally, remains responsive past the previous failure window, and a 45-second soak used only 0.438 seconds of CPU. Normal keyboard, mouse, controllers, and unrelated HID functionality remain unaffected.
What is the expected behavior?
Codex Micro discovery should not block Electron's main/UI thread. HID enumeration should run asynchronously or in a worker/utility process, have a timeout, and back off or disable itself after failure. The Codex app should remain responsive when no Work Louder device is present or when Windows HID enumeration is slow.
Additional information
Likely affected integration packages: @worklouder/device-kit-oai, @worklouder/wl-device-kit, and the nested node-hid package.
Please consider lazy-loading the optional integration only after the user enables/opens Codex Micro settings, and moving device enumeration off the main process. The feature appears to be guarded in the renderer, but the service still needs a safe failure mode because one slow native HID call can freeze the whole desktop app.
The workaround deliberately does not patch the signed MSIX package; it only intercepts the Work Louder package's private node-hid import at runtime and returns [] for devices() / devicesAsync().
What version of the Codex App are you using (From “About Codex” dialog)?
26.715.21425 (Microsoft Store package 26.715.2305.0)
What subscription do you have?
prolite (as reported by Codex diagnostics)
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
After a Windows update and a Codex update, the Microsoft Store Codex app becomes unusable: the window shows “Not responding”, the mouse pointer lags/stutters system-wide, and the app can eventually show “Oops, an error has occurred” with “Update ChatGPT” / “Try again”.
A CPU profile of the Electron main process captured 49,395 samples. 47,121 samples (95.4%) were inside
showdevicesin:resources/app.asar/node_modules/@worklouder/device-kit-oai/node_modules/@worklouder/wl-device-kit/node_modules/node-hid/nodehid.jsThe hot path is the synchronous call:
The Work Louder integration calls
nodeHID.devices()fromfindWLDevices([DeviceType.Project2077])to discover Codex Micro hardware. HID enumeration runs synchronously on Electron's main/UI thread. When no matching device is found, discovery retries every 10 seconds. On this Windows/HID stack, enumeration can block for a long time, starving UI rendering, IPC, and app-server/Git requests.No Work Louder/Codex Micro device is connected or needed on this machine.
What steps can reproduce the bug?
OpenAI.Codex_26.715.2305.0_x64.Project2077) device.findWLDevices([DeviceType.Project2077]), which calls synchronousnodeHID.devices()on the Electron main thread.Workaround verified locally: preload a narrowly scoped shim for ChatGPT.exe that returns an empty device list only for the Work Louder package's
node-hidimport. With that optional discovery disabled, the app launches normally, remains responsive past the previous failure window, and a 45-second soak used only 0.438 seconds of CPU. Normal keyboard, mouse, controllers, and unrelated HID functionality remain unaffected.What is the expected behavior?
Codex Micro discovery should not block Electron's main/UI thread. HID enumeration should run asynchronously or in a worker/utility process, have a timeout, and back off or disable itself after failure. The Codex app should remain responsive when no Work Louder device is present or when Windows HID enumeration is slow.
Additional information
Likely affected integration packages:
@worklouder/device-kit-oai,@worklouder/wl-device-kit, and the nestednode-hidpackage.Please consider lazy-loading the optional integration only after the user enables/opens Codex Micro settings, and moving device enumeration off the main process. The feature appears to be guarded in the renderer, but the service still needs a safe failure mode because one slow native HID call can freeze the whole desktop app.
The workaround deliberately does not patch the signed MSIX package; it only intercepts the Work Louder package's private
node-hidimport at runtime and returns[]fordevices()/devicesAsync().