[Windows x64] Codex Micro HID.node repeatedly raises 0xC06D007F and causes UI stutter

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

26.707.9981.0

What subscription do you have?

ChatGPT Prolite

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex Windows app remains open but repeatedly raises native delay-load exceptions, causing visible UI and system stutter.

Windows Event Viewer records recurring Application Error event ID 1000 entries for ChatGPT.exe with exception code 0xC06D007F. During one app session, 169 matching events were observed. In the analyzed event sequence, 42 adjacent failures were separated by 3.5–5.5 seconds.

The affected machine has no Codex Micro / Work Louder device connected or installed, but the packaged Codex Micro bridge still attempts to load its native HID integration.

This appears related to #33375 and #33415, but the architecture, native addon, and failure behavior are distinct:

• This report: Windows x64, node-hid\HID.node, repeated non-fatal exceptions and stutter while the main process stays alive.
• #33375: Windows x64, serialport.node, severe lag.
• #33415: Windows ARM64, serialport prebuild, fatal app exit; it specifically predicted that HID.node could have the same delay-load problem.

This report confirms that the second native addon is affected on x64.

What steps can reproduce the bug?

1. Install and launch Codex App 26.707.9981.0 on Windows x64.
2. Use the app normally, such as switching tasks or interacting with the UI. No Codex Micro / Work Louder hardware needs to be connected.
3. Notice recurring pauses or UI stutter.
4. Open Event Viewer → Windows Logs → Application.
5. Observe repeated Application Error event ID 1000 entries for ChatGPT.exe with exception code 0xC06D007F.
6. Continue interacting with the UI; failures can occur immediately after an interaction and again about four seconds later.

The behavior may depend on the Codex Micro rollout or feature flag being enabled for the account.

What is the expected behavior?

Optional hardware integration should not load when no supported device is connected or explicitly enabled.

If its native module cannot load, Codex should disable that integration for the session and remain responsive instead of retrying the same deterministic failure after later UI updates.

Additional information

High-confidence binary analysis

Affected packaged module:

@worklouder/device-kit-oai/
  node_modules/@worklouder/wl-device-kit/
  node_modules/node-hid/build/Release/HID.node

PE import/export inspection shows:

• HID.node delay-imports node.exe for 61 named N-API functions.
• Its delay-load hook handles the node.exe target by calling GetModuleHandleA(NULL), which returns the ChatGPT.exe main module.
• ChatGPT.exe exports only two named symbols and none of the 61 required N-API symbols.
• The packaged chrome.dll exports all 61 required symbols.
• Other packaged native addons such as better_sqlite3.node, windows-account.node, and windows-updater.node resolve their N-API imports from chrome.dll and do not show this mismatch.

The installed MSVC delay-load helper source maps 0xC06D007F to a delayed GetProcAddress failure with ERROR_PROC_NOT_FOUND. A missing DLL would instead produce 0xC06D007E.

I could not access the WER dump's PDelayLoadInfo exception data, so I am not claiming which of the 61 N-API functions is the first runtime failure. The confirmed issue is that none of them can resolve from the selected ChatGPT.exe module, while all are present in chrome.dll.

Retry correlation

The packaged codex-micro-service code contains a 4000 ms selectionLighting transition timer. When native service loading fails, its cached service promise is cleared; later getState or lighting updates can attempt to load the module again.

Observed timing matches an immediate UI-triggered attempt followed by another failure roughly four seconds later. This explains why the app can remain alive while repeatedly invoking Windows Error Reporting and producing visible stalls.

Suggested remediation

1. Rebuild or relink the packaged node-hid addon for the app's Electron host so N-API symbols resolve from chrome.dll, or use an appropriate custom delay-load hook.
2. Feature-gate Codex Micro native loading until a matching device or explicit user opt-in is present.
3. Cache deterministic native-load failure for the rest of the app session instead of retrying it from subsequent UI or lighting updates.
4. Add Windows x64 and ARM64 packaging tests for both the serialport and HID native addons.

Internal Codex Feedback ID:

no-active-thread-019f69aa-041b-7ea0-a3e2-f2f8f1e13028

No conversation content, browser tabs, local usernames, absolute user paths, or memory dump files are included in this public report.