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

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

• #34292
• #33912
• #33780
• #33606
• #33409

Powered by Codex Action

This has been doing on for DAYS! and OpenAI seems to not care! Likely thousands of devices not working

This has been doing on for DAYS! and OpenAI seems to not care! Likely thousands of devices not working

Update to the latest version from the store, it seems to have fixed the issue

Additional controlled A/B evidence on the current Windows build. This appears to connect the Codex Micro reports here with the downstream git.exe / taskkill.exe / WMI storm in #34260.

Environment:

• Windows 10 Pro 22H2 x64, build 19045.6466
• 32 logical processors
• Store package OpenAI.Codex_26.715.8383.0_x64__2p2nqsd0c76g0
• The Micro service reported status: not-detected throughout the test

I did not restart Codex and did not modify the signed MSIX or app.asar. With the same Electron main PID, I temporarily attached a loopback Inspector, replaced only the renderer codexMicro service slot with a no-device stub, called the existing service's own stop(), and immediately closed the Inspector.

Ten-second Microsoft-Windows-Kernel-Process ETW windows before and after:

| State | Direct children of main PID | Rate | git.exe | taskkill.exe | powershell.exe | Primary WmiPrvSE core equivalent |
| --- | ---: | ---: | ---: | ---: | ---: | ---: |
| Micro running | 648 | 64.36/s | 317 | 316 | 15 | 3.714 |
| Micro stopped | 19 | 1.89/s | 0 | 0 | 19 | 0.068 |
| Inspector closed, sustained | 21 | 2.09/s | 0 | 0 | 21 | 0.065 |

The direct process-start rate fell by about 97.1%, the primary provider-host CPU fell by about 98.2%, and the Git/taskkill churn disappeared completely. A later 10-second verification remained at 0 Git and 0 taskkill. The Codex main PID and start time did not change, and the Inspector was no longer listening.

This Codex process has no matching ChatGPT.exe Event 1000 faults since its start, so the problem is not limited to the older serialport ABI crash signature. On this machine, merely stopping the optional Micro service removes the process/WMI storm.

The current bundle has moved Windows discovery from broad nodeHID.devices() to a native filtered findCodexMicroInterfaces() topology watcher. However:

1. The Micro service module still top-level-requires the complete @worklouder/device-kit-oai transport before any matching device is confirmed.
2. serviceManager.getState() creates the service and unconditionally starts the watcher, even when the user has no device.
3. The ordinary renderer task/thread state bridge keeps the optional service in the normal task lifecycle.

Suggested product changes:

• Keep filtered topology detection separate from the Work Louder transport and lazy-load the transport only after a matching VID/PID is present or the user explicitly opts in.
• Do not let getState() implicitly start the native service; expose a stable disabled/not-detected state until opt-in or a safe device-arrival signal.
• Run topology/discovery off the Electron main thread, debounce and single-flight callbacks, and add bounded backoff/circuit breaking.
• Add a supported Windows setting to disable Codex Micro.
• Independently bound Git-worker and taskkill cleanup concurrency and replace repeated PowerShell/WMI full-process snapshots with a native process snapshot.

I retained the four small ETL captures and can provide sanitized exports privately if useful.

Current-build follow-up: Store package 26.721.3996.0

I repeated the check on the current official Windows x64 Store package using read-only inspection and a normally launched, unmodified process.

Package identity

• MSIX: OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0
• Internal app version: 26.721.31836
• Package signature/status: Store / Ok
• ChatGPT.exe SHA-256: 1aa14124b6586eae0f589e624c37854697789c4b57ab1103e04dc3920612291e
• app.asar SHA-256: 886ecd4906e918de164ac8eb1a6c4f1a77e051130b67b8a401c021b7f1cd6e50

No present PnP device matched the current service's Work Louder VID 0x303A and PIDs 0x8360, 0x8297, or 0x8298.

Live module map

The normal Electron main process had no --inspect argument and mapped:

• @worklouder/device-kit-oai/.../@worklouder/wl-device-kit/.../@serialport/bindings-cpp/build/Release/bindings.node
• resources/native/hid-topology-watcher.node

No Codex process mapped Work Louder's HID.node.

This is consistent with the newer Windows discovery implementation: codex-micro-service-DS07ThMO.js calls the filtered native findCodexMicroInterfaces() topology watcher on Windows; the node-hid devicesAsync() path is Linux-only. The service does not call WLDeviceDiscovery.findWLDevices() for Windows discovery.

Current import graph

The optional service nevertheless still loads the full Work Louder transport before a matching device is known:

main-D9Ntp4GD.js
  -> lazy require("./codex-micro-service-DS07ThMO.js")
     -> require("@worklouder/device-kit-oai")                0.1.11
     -> independently require("@worklouder/wl-device-kit")  0.1.23
        -> top-level require("node-hid")                     3.3.0
        -> top-level require("serialport")                   12.0.0
           -> loads bindings.node

The independent base-kit request is material for existing diagnostic workarounds: intercepting only the exact @worklouder/device-kit-oai request no longer suppresses the native-bearing base kit on this build, because the service subsequently requests @worklouder/wl-device-kit directly.

Interpretation

This confirms that 26.721.3996.0 still eagerly maps the nested serialport native binding when no supported Work Louder hardware is present. It also confirms that the older broad synchronous Windows HID.node enumeration path is not active in this process.

Module presence alone does not prove that the serialport binding causes the observed lag. This startup independently logged a 31,453 ms shell-environment timeout and a 4,131 ms app-server initialization handshake, so those remain substantial alternative contributors. A controlled current-build A/B is still needed before attributing responsiveness problems to this remaining eager load.

No signed package, app.asar, application data, settings, credentials, conversations, plugins, or startup configuration was modified for these observations.

Current-build A/B reproduction plus residual IPC stalls (26.727.6591.0)

I reproduced the severe Windows freezes on a newer Store build and then measured what remains after the Codex Micro path is disabled. The evidence points to two separate contributors:

1. the optional Work Louder/Codex Micro service is the main cause of the severe multi-second and system-input stalls;
2. after that service is disabled, shorter UI stalls remain and correlate with high-volume IPC/state traffic between the Electron processes and multiple local Codex agents, which appears related to #25779.

Environment

• Store package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0 (Status: Ok)
• Windows 11 Pro x64, build 26200
• 24 logical processors, 64 GB RAM
• NVIDIA RTX 4060, driver 32.0.16.1074

Current package/runtime path

Read-only inspection of this build found:

• @worklouder/device-kit-oai version 0.1.11
• unpacked node-hid and @serialport native dependencies
• the current service bundle is .vite/build/service-4uQDVZZZ.js
• the lazy-load call originates from .vite/build/main-C1YkadXg.js

This build no longer follows the older WLDeviceDiscovery.findWLDevices() path described in some earlier reports. It uses a native HID topology watcher, but the service bundle still eagerly resolves/loads @worklouder/device-kit-oai and its Work Louder dependency chain.

I launched a new process paused before application JavaScript and instrumented only Node's module loader. Before allowing any suspicious native add-on to execute, the observed sequence was:

./service-4uQDVZZZ.js
  parent: app.asar/.vite/build/main-C1YkadXg.js

@worklouder/device-kit-oai
  parent: app.asar/.vite/build/service-4uQDVZZZ.js

The test process was then terminated. The signed MSIX, app.asar, application data, credentials, conversations, plugins, and MCP configuration were not modified.

Controlled A/B result

For an unofficial diagnostic A/B test, I used a version- and hash-pinned external launcher. It replaces only the exact internal Micro service request above, and only when the parent is the exact main bundle, with a minimal service returning the existing not-detected state. The loopback inspector was bound to 127.0.0.1, closed immediately after injection, and had a fail-closed timeout.

Self-test results:

• the exact Micro service request was intercepted once;
• no @worklouder file entered require.cache;
• the inspector listener closed;
• the app remained responsive and no new matching crash/WER report appeared;
• the severe multi-second freezes and system-wide mouse stalls improved substantially.

This confirms that the Codex Micro/Work Louder path remains a major contributor on 26.727.6591.0. An old workaround that only stubs WLDeviceDiscovery.findWLDevices() is not applicable to this build because the service implementation changed.

Residual stalls after Micro is disabled

I then ran a separate 30-second, 10 Hz local measurement while switching among several large chats and sending a short prompt. The sampler recorded only process counters, input-activity timestamps (not keys/content), and WM_NULL message-queue latency. It did not inspect chat contents, logs, commands, or file paths.

Results after the Micro service had already been disabled:

• 11 distinct main-window message-queue timeout clusters using a 25 ms threshold;
• 2 clusters longer than 500 ms;
• longest cluster: 2.016 s;
• two codex.exe processes and two code-mode hosts were present;
• the 2.016 s cluster was dominated by the second codex.exe and coincided with about 41.3 MB read and 9.6 MB written through Windows process I/O counters;
• an 814 ms cluster was dominated by a ChatGPT subprocess and coincided with about 26.4 MB read and 9.0 MB written;
• one ChatGPT subprocess wrote 142.6 MB while another read 141.5 MB during the capture (an inference: the near-symmetry is consistent with internal pipe/IPC transfer, although process I/O counters cannot prove the transport);
• combined Codex-agent counters: 266.0 MB read / 36.2 MB written;
• combined ChatGPT counters: 149.7 MB read / 147.7 MB written;
• main process private memory: about 2.64 GB to 2.72 GB; total ChatGPT private memory remained around 3.8 GB.

There was ample free RAM, negligible paging, no sustained DPC/interrupt activity, and no new crash/WER report. CPU was not globally saturated, but on a 24-logical-processor system one fully occupied thread is only about 4.2% total CPU. The data is therefore consistent with a blocked/saturated Electron event loop plus IPC/backpressure rather than overall system resource exhaustion.

Suggested fix surfaces

For the severe Micro path:

• do not initialize or load Work Louder native dependencies when no supported device is present and the feature is unused;
• keep HID/serial enumeration and native binding loads off the Electron main/UI thread;
• provide a supported no-device/disable switch so users do not need an inspector-based diagnostic workaround;
• fail closed and stop retrying when native ABI/DLL initialization fails.

For the residual stalls:

• bound and/or coalesce high-frequency agent/turn IPC updates;
• avoid full-history/state hydration on hot chat-switch/send paths;
• add per-stage timing/queue-depth telemetry for app-server → main → renderer traffic;
• profile multiple concurrently active codex.exe processes against the state-retention scenarios tracked in #25779.

The Micro workaround is unofficial and intentionally aborts after an app update. I am reporting the measurements rather than recommending that workaround to other users.