no-active-thread-019f746b-17c7-7e41-b376-2536056757e2

Start by tracing the codexMicro.getState() entry point into the Electron main process and the WLDeviceDiscovery.findWLDevices([Project2077]) call, including the HID.node path described in the report. Reproduce the periodic UI freeze on Windows and verify that device discovery no longer blocks the main thread when the required hardware is absent.

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

26.715.4045.0

What subscription do you have?

PRO 20X

What platform is your computer?

WINDOWS

What issue are you seeing?

What Was Actually Happening

I identified that the internal feature gate 3207467860 enables Codex Micro, even on systems that do not have the corresponding hardware.

The frontend calls:

codexMicro.getState()

The Electron main process then synchronously executes:

WLDeviceDiscovery.findWLDevices([Project2077])

The HID device enumeration blocks the main UI thread for approximately 10.3 seconds.

Because the expected device is not found, the process waits another 10,000 ms before trying again:

10.3 seconds blocked + 10 seconds waiting = one freeze every 20.46 seconds

While the Electron main thread is blocked, it stops processing UI messages. As a result, mouse movement and clicks appear to freeze completely.

During these freezes, the rest of the system continued operating normally:

• CPU usage remained normal.

• RAM usage remained normal.

• GPU activity remained normal.

• SSD activity remained normal.

• Windows Explorer remained responsive.

• Desktop Window Manager remained responsive.

A publicly available trace of the same issue reaches the following call chain:

HID.node → HidD_GetManufacturerString → DeviceIoControl

The related issue is still open as openai/codex#33884.

Evidence: Before and After

Measurement | Before | After -- | -- | -- Test duration | 50.137 s | 70.124 s Samples | 457 | 639 Unresponsive samples | 245 | 0 Freeze episodes | 3 | 0 Longest freeze | 10.398 s | 0 s Freeze cycle | 20.462 s | Eliminated Healthy latency | 0.367 ms | 0.150 ms

The live process confirmed that the hook successfully replaced WLDeviceDiscovery.findWLDevices() before device discovery occurred.

After restarting Codex, no new Windows Event Viewer entries with IDs 1000, 1001, or 1002 were generated for the Codex process.

Workaround

The workaround does not modify:

• The MSIX package

• The Windows Registry

• Device drivers

• USB configuration

• Codex conversations

• Global environment variables

It only replaces the hardware discovery result:

WLDeviceDiscovery.findWLDevices() → []

This prevents the unnecessary HID enumeration from blocking the Electron main thread when the required Codex Micro hardware is not present.

OPENAI-ISSUE-READY-TO-PASTE.md
README.md
RELATORIO-OPENAI.md

What steps can reproduce the bug?

When using the Codex, the freezing bug is triggered simply by having it open.

What is the expected behavior?

without the screen freezing every 20 seconds

Additional information

No response