[Windows App] Severe UI freezes correlate with Codex Micro HID/serial module; disabling it removes the hangs

Start at Codex Micro initialization, feature gate 3207467860, and the @worklouder/device-kit-oai module, including HID.node and the serialport bindings.node mentioned in the report. Reproduce the normal-versus-stubbed launch comparison and inspect whether device discovery blocks the Electron main process. Done means normal UI operations remain responsive when no compatible device is connected.

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

26.715.4045.0 Microsoft Store MSIX package: OpenAI.Codex

What subscription do you have?

[Fill in your subscription, e.g. Plus / Pro]

What platform is your computer?

Windows 11 x64, OS build 26100 32 GB RAM

What issue are you seeing?

The Codex Windows desktop app repeatedly becomes unresponsive during ordinary UI operations, including switching threads, opening or creating a task, typing, and sending a prompt.

Windows Task Manager does not permanently mark the app as hung, but the main ChatGPT.exe process repeatedly reports Responding=False for approximately 7.5–12 seconds. CPU usage is low during the freeze, and the renderer/GPU/backend processes remain alive.

Windows Event Viewer has also recorded Application Hang event 1002 for ChatGPT.exe.

After approximately two full days of troubleshooting, the strongest correlation I found is the private Codex Micro feature.

During a normal launch, the main ChatGPT.exe process loads these native modules:

• @worklouder/device-kit-oai/.../node-hid/build/Release/HID.node
• @worklouder/device-kit-oai/.../serialport/.../bindings.node

The installed app also contains feature gate 3207467860 and the strings "Codex Micro" and "@worklouder/device-kit-oai".

I do not own or have a Codex Micro / Work Louder device connected.

I then performed an A/B test using an experimental launcher that replaces only @worklouder/device-kit-oai with a no-device stub at startup.

The successful launch reported:

• mode: micro-disabled-worker-safe
• evaluation: codex-micro-disabled-worker-safe

In that process:

• HID.node and the serialport bindings were no longer loaded.
• The temporary localhost inspector port was closed after startup.
• 20 consecutive responsiveness samples were all Responding=True.
• So far, the UI freezes have not reproduced.

This strongly suggests that Codex Micro device discovery or communication is blocking the Windows Electron main process even when no Codex Micro device is present.

What steps can reproduce the bug?

1. Launch Codex normally from the Windows Start menu.
2. Switch between existing tasks, create a new task, or send a prompt.
3. Observe intermittent severe UI freezes / Windows "Not Responding".
4. Fully quit Codex.
5. Launch it with the Codex Micro module stubbed.
6. Repeat the same operations.
7. The UI remains responsive and the Work Louder native modules are not loaded.

What is the expected behavior?

Codex should remain responsive during normal UI operations.

The private Codex Micro device service should not initialize when the feature is not being used or when no compatible device is present. Any HID/serial discovery should run asynchronously and must not block the Electron main process.

A supported feature flag for disabling Codex Micro would also provide a safe temporary workaround.

Additional information

Related general Windows freezing report:
https://github.com/openai/codex/issues/20214

Experimental workaround used for the A/B test:
https://gist.github.com/triesmon/bdc20a18ec34108e2608c1294c451f86

Codex thread ID:
019f7e4f-38b3-7100-ba9f-27ba06a4ac12

I can provide sanitized desktop logs and Windows Application Hang events privately.