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

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().

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

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

Powered by Codex Action

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

Environment

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

Measured behavior

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

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

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

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

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

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

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

Temporary diagnostic workaround:

Close every process using the copied runtime.
Keep a byte-for-byte backup of resources/app.asar.
In the copied archive, replace the single expression
```
this.discovery.findWLDevices([a.Project2077])
```
with [], padded with ASCII spaces to exactly the original byte length. In context, [t] = [] makes discovery return no device without changing ASAR offsets or size.
Launch the copied executable with the original profile arguments.

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

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

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

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

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

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

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

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

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

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

150-second result:

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

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

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

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

Normal launch

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

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

Controlled A/B result

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

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

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

Requested product fix

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

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

Desktop package tested: OpenAI.Codex_26.715.4045.0_x64.
A 143-second WPR GeneralProfile trace recorded recurring foreground UI input delays on the ChatGPT Electron main thread at roughly 10.7-second intervals. Representative input/message delays were 734 ms, 687 ms, and 703 ms.
In each matching delay window, ETW stacks repeatedly showed the main UI thread in the bundled HID.node path:
@worklouder/device-kit-oai -> @worklouder/wl-device-kit -> node-hid -> hid.dll -> hidusb.sys -> HIDCLASS.SYS.
Three independently sampled delay windows contained 329, 317, and 296 HID.node stack samples respectively, spanning almost the whole delayed interval.
The relevant native module is present in the installed package under @worklouder/device-kit-oai; no Work Louder / Codex Micro device is connected or required on this machine.
HID completion activity in this trace involved ASUS AURA Sync's LightingService (RGB-lighting service). As a reversible A/B test, stopping only that service while leaving the app open made the periodic system/UI stutter disappear. This points to slow HID enumeration/interaction with a normal RGB/HID stack, not memory pressure, Git CPU, or a long DPC/ISR.

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

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

Tested package: OpenAI.Codex 26.715.3651.0.

Unsupported, version-specific procedure:

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.

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

Environment

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

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

HID interface-count A/B

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

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

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

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

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

Direct ChatGPT window measurement

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

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

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

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

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

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

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

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

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

Reproduction steps:

Connect the external USB DVD drive.
Restart Windows.
Launch Codex.
Codex enters repeated Not Responding / AppHangTransient cycles.
Close Codex and unplug the DVD drive.
Launch Codex again.
Codex works normally.

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

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

Temporary workaround: leave the external DVD drive unplugged.

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

+1

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

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

Same issue here.

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

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

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

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

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

Environment

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

Findings

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

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

Please consider:

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

Additional Windows/Lenovo reproduction and customer-impact report

Environment:

Lenovo Windows PC with Lenovo PC Manager installed.
Current ChatGPT/Codex desktop app; the problem began after a recent app upgrade.
No Codex Micro or Work Louder hardware is intentionally connected.

Symptoms:

Simply opening ChatGPT/Codex drives CPU usage extremely high and makes the entire computer nearly unusable.
Starting any task repeats the behavior.
Lenovo PC Manager is repeatedly triggered or pops up during the scanning activity and then consumes substantial CPU itself.
A trivial local PowerShell command that only reads a small text file stalled for more than 10 seconds, while online-only requests completed normally. This appears consistent with local HID/device/process discovery triggering a host hardware-monitoring component.
The desktop app has been effectively unusable for several days.

Customer and business impact:

I maintain three paid ChatGPT/Codex accounts and spend more than USD 300 per month in total.
I have been unable to work normally for several days because opening the desktop app or running tasks makes the machine unusable.
The resulting productivity and financial loss is significant.

The 10-second retry and synchronous HID discovery described in this issue closely match the recurring scans observed here. The symptoms also appear related to #33780 and #33606.

Requested action:

Urgently disable Codex Micro / Work Louder HID discovery by default unless the user explicitly enables or connects that hardware.
Move all optional device enumeration off the Electron UI thread and add strict timeouts and exponential backoff.
Provide a supported user-facing temporary switch to disable optional hardware discovery.
Investigate the interaction with Lenovo PC Manager, WMI, and Lenovo hardware-monitoring services.
Publish the first fixed app version and a safe workaround for affected Windows customers.

I can provide the exact Lenovo model, ChatGPT/Codex app version, Windows build, Lenovo PC Manager version, and a Task Manager screenshot if maintainers request them.

I can reproduce the same class of system-wide input lag on a newer Windows build.

Codex package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
ChatGPT.exe file version: 150.0.7871.128
Windows: 25H2, build 26200.8875, x64
Trigger: cold-launching the ChatGPT/Codex desktop app
Symptom: the entire computer becomes noticeably laggy during startup; mouse-pointer movement visibly stutters

I have not yet confirmed whether synchronous HID/Codex Micro discovery is the cause on this machine, so this is a symptom/version confirmation rather than a root-cause claim.

Independent reproduction on a much newer Windows package, with a potentially useful focus-dependent clue.

Environment

Microsoft Store package: OpenAI.Codex 26.810.4967.0
Windows 11 Home x64, build 22621
Intel Core i5-13490F (16 logical processors), NVIDIA RTX 3060
31 present HID-class devices; no present PnP device matched Codex Micro VID 303A / PID 8360
The same symptom also occurs on a second, higher-performance Windows PC

Reproduction / behavior

Mouse-pointer movement stutters system-wide immediately after launching Codex.
Replacing the physical mouse did not change the symptom.
Closing Codex generally removes the stutter.
Minimizing Codex does not help. Making Chrome or VS Code the foreground app also does not help.
If Windows Task Manager itself is the active foreground window, the pointer becomes smooth immediately. As soon as Task Manager loses foreground focus, the stutter returns. Merely leaving Task Manager open is not enough.
Older Codex builds also caused startup stutter, but it usually disappeared after 1–2 minutes. With the current build the impact can spread beyond startup and persist much longer, although it may eventually improve.

Local measurements while VS Code was foreground

The Electron main ChatGPT.exe process averaged about 49.9% of one logical processor and peaked at 83% over a 24-second sample.
Total system CPU averaged about 4.4%; GPU, DWM, DPC, and interrupt activity were near zero; the bundled codex.exe app-server was idle.
Main-process private memory varied around 0.9–1.15 GB, with ample system memory still available.
A module snapshot of the current main process showed hid-topology-watcher.node and the Work Louder serial bindings.node, but not the older HID.node. This is only a snapshot, but it suggests the current package may be using the newer topology-watcher path while a similar system-wide input symptom remains.
During the first minutes after startup, the desktop log recorded 321 unknown conversation event errors and 80 conversation state not found errors; later it repeatedly logged ResizeObserver loop completed with undelivered notifications. These may be secondary/amplifying symptoms rather than the root cause.

This may be the same issue class or a newer regression in the replacement HID-topology path. The Task-Manager-foreground behavior seems especially diagnostic: it is immediate and depends on actual foreground focus. Please let me know if a WPR/ETW trace or sanitized log excerpts from this current build would help; no raw logs or user paths are attached here.

Additional reproduction on the current Microsoft Store build

I can reproduce the same issue, including the Task Manager foreground behavior.

Environment

Microsoft Store package: OpenAI.Codex 26.810.4967.0
Package installed: August 13, 2026
Windows 11 Pro 25H2, build 26200.9168
GPU: NVIDIA RTX 4070 Ti
NVIDIA driver: 32.0.15.9636
Display: LG UltraGear, 3840×2160 at 143 Hz
Mice tested:
- Razer DeathAdder V3 Pro
- Razer Pro Click V2
Both mice configured for 1000 Hz polling
No Codex Micro / Work Louder hardware is connected

Distinctive behavior

The cursor is smooth before signing in, then begins stuttering after the desktop and ChatGPT/Codex app load.
The cursor stutters in ordinary medium-integrity applications, including Explorer, Paint, ChatGPT, and a normal Notepad window.
The cursor becomes immediately smooth only when Task Manager is the actual foreground window.
A newly launched elevated/administrator Notepad window is also smooth.
A normal Notepad process set to High priority still stutters, so process scheduling priority does not explain the difference.
Scrolling, animations, and the monitor FPS indicator remain smooth while the pointer alone appears janky.
Both physical mice reproduce the same symptom.
Fully exiting the ChatGPT/Codex process tree fixes the cursor immediately without rebooting.

Process-count observation

Immediately before fully exiting the app, the user session contained:

node.exe: 124 processes
node_repl.exe: 37 processes

After fully exiting and reopening ChatGPT/Codex:

node.exe: 7 processes
node_repl.exe: 2 processes
codex-computer-use.exe: 0 processes

These are whole-session counts, so I am not claiming every node.exe belonged to Codex. However, 34 of the observed node_repl.exe processes had the live Codex backend as their parent, and most helper processes disappeared when the app was fully exited. This may overlap with the retained per-thread MCP process behavior described in #32154.

Negative results

The symptom was not changed by:

Exiting Razer Synapse, Logi Options+, Listary, Sogou components, or NVIDIA Overlay
Disabling and restoring G-SYNC
Raising a normal Notepad process to High priority
Resetting the Windows graphics stack
Enabling pointer trails
Switching input methods
Restarting Explorer
Testing with low CPU, GPU, memory, disk, DPC, and interrupt load

No matching ChatGPT.exe Application Error 1000 or Application Hang 1002 event was found during the affected period.

The elevated-window and pointer-only behavior may help distinguish this from general renderer or system-load stalls. It may indicate a normal-integrity input/cursor hook, overlay, or helper-runtime path.

Confirming this on a newer Microsoft Store build: OpenAI.Codex 26.810.6296.0 x64 (observed 2026-08-15).

The user reports system-wide mouse stuttering and short PC/UI freezes while Codex Desktop is open.

A read-only inspection of the unmodified Store installation showed that the main ChatGPT.exe process had this native module mapped:

@worklouder/device-kit-oai
  -> @serialport/bindings-cpp
     -> build/Release/bindings.node

Additional bounded checks:

no git.exe processes were observed during an 8-second sample;
no ChatGPT.exe Application Error event ID 1000 entries were found in the previous 14 days;
no workaround, launcher injection, or ASAR modification was applied.

This is useful confirmation that the Codex Micro / Work Louder native dependency is still loaded in build 26.810.6296.0, and that the system-wide input-stutter symptom can occur without the separate Git process storm and without the 0xc06d007f crash signature.

Navigation Menu

Repository navigation

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

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?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Normal launch

Controlled A/B result

Requested product fix

Environment

HID interface-count A/B

Direct ChatGPT window measurement

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

Additional reproduction on the current Microsoft Store build

Environment

Distinctive behavior

Process-count observation

Negative results

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

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?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 17, 2026

mm0nst3r commented on Jul 17, 2026

mm0nst3r commented on Jul 18, 2026

SCIMMS commented on Jul 18, 2026

MUMO7 commented on Jul 18, 2026

Normal launch

Controlled A/B result

Requested product fix

chengshu-ai commented on Jul 19, 2026

mm0nst3r commented on Jul 19, 2026

NeksiCat commented on Jul 20, 2026

Environment

HID interface-count A/B

Direct ChatGPT window measurement

harrywenjie commented on Jul 20, 2026

WilliamSmithEdward commented on Jul 20, 2026

theslamduncan commented on Jul 20, 2026

memesalot commented on Jul 20, 2026

NeksiCat commented on Jul 20, 2026

LZH98 commented on Jul 20, 2026

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

qq783840671-png commented on Jul 22, 2026

jasonari commented on Jul 26, 2026

chenyx7523 commented on Aug 14, 2026

Guoyuer commented on Aug 14, 2026

Additional reproduction on the current Microsoft Store build

Environment

Distinctive behavior

Process-count observation

Negative results

jbialas-listonic commented on Aug 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions