no-active-thread-019f746b-17c7-7e41-b376-2536056757e2
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?
<html>
<body>
<!--StartFragment--><html><head></head><body><h2>What Was Actually Happening</h2><p>I identified that the internal feature gate <code inline="">3207467860</code> enables <strong>Codex Micro</strong>, even on systems that do not have the corresponding hardware.</p><p>The frontend calls:</p><p><code inline="">codexMicro.getState()</code></p><p>The Electron main process then synchronously executes:</p><p><code inline="">WLDeviceDiscovery.findWLDevices([Project2077])</code></p><p>The HID device enumeration blocks the main UI thread for approximately <strong>10.3 seconds</strong>.</p><p>Because the expected device is not found, the process waits another <strong>10,000 ms</strong> before trying again:</p><p><code inline="">10.3 seconds blocked + 10 seconds waiting = one freeze every 20.46 seconds</code></p><p>While the Electron main thread is blocked, it stops processing UI messages. As a result, mouse movement and clicks appear to freeze completely.</p><p>During these freezes, the rest of the system continued operating normally:</p><ul><li><p>CPU usage remained normal.</p></li><li><p>RAM usage remained normal.</p></li><li><p>GPU activity remained normal.</p></li><li><p>SSD activity remained normal.</p></li><li><p>Windows Explorer remained responsive.</p></li><li><p>Desktop Window Manager remained responsive.</p></li></ul><p>A publicly available trace of the same issue reaches the following call chain:</p><p><code inline="">HID.node → HidD_GetManufacturerString → DeviceIoControl</code></p><p>The related issue is still open as <code inline="">openai/codex#33884</code>.</p><h2>Evidence: Before and After</h2>
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
<p>The live process confirmed that the hook successfully replaced <code inline="">WLDeviceDiscovery.findWLDevices()</code> before device discovery occurred.</p><p>After restarting Codex, no new Windows Event Viewer entries with IDs <code inline="">1000</code>, <code inline="">1001</code>, or <code inline="">1002</code> were generated for the Codex process.</p><h2>Workaround</h2><p>The workaround does not modify:</p><ul><li><p>The MSIX package</p></li><li><p>The Windows Registry</p></li><li><p>Device drivers</p></li><li><p>USB configuration</p></li><li><p>Codex conversations</p></li><li><p>Global environment variables</p></li></ul><p>It only replaces the hardware discovery result:</p><p><code inline="">WLDeviceDiscovery.findWLDevices() → []</code></p><p>This prevents the unnecessary HID enumeration from blocking the Electron main thread when the required Codex Micro hardware is not present.</p></body></html><!--EndFragment-->
</body>
</html>
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_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗