[Windows 10 / 26.803] Codex Micro service causes Logitech wireless mouse stutter; full no-device service stub resolves it
Summary
On Windows 10, Codex Desktop caused severe system-wide stuttering when using a Logitech mouse through its wireless USB receiver. The same mouse worked normally over a wired connection.
Disabling only the HID topology watcher did not resolve the symptom. Replacing the complete optional Codex Micro service module with an API-compatible no-device stub did resolve it.
This is a controlled diagnostic A/B result on a copied runtime. The signed Microsoft Store installation was not modified.
Related reports: #34327 and #33912.
Environment
- Microsoft Store package:
OpenAI.Codex 26.803.5235.0, x64 - Internal desktop app version:
26.803.41515 - Windows 10 Pro 22H2, build
19045 - Mouse: Logitech wireless HID mouse
- Receiver: USB
VID_046D / PID_C54D - Exact retail mouse model: not exposed by Windows and therefore not guessed
Only the generic VID/PID is included. Device serial numbers, complete PnP instance IDs, usernames, account information, local paths, task IDs, configuration, conversations, and raw logs are intentionally omitted.
Symptoms
With Codex Desktop running and the mouse connected wirelessly:
- pointer movement became severely jerky across Windows;
- clicks and movement intermittently stalled;
- Windows occasionally displayed “USB device not recognized”;
- recovery sometimes required unplugging and reconnecting the Logitech receiver.
Using the same mouse through a wired connection did not reproduce the problem.
First diagnostic patch: disabling only CodexMicroService.start()
The current service chunk was:
resources/app.asar
-> .vite/build/service-CJETEjOt.js
The first copied-runtime experiment used a same-length UTF-8/ASCII replacement.
Original sequence:
start(){if(this.lifecycleState!==`started`){this.lifecycleState=`started`
Replacement:
start(){if(false ){this.lifecycleState=`started`
The bytes following false were padded with ASCII space bytes (0x20) so the service entry size and all later ASAR offsets remained unchanged.
This prevented the service from starting the native HID topology watcher. Runtime inspection confirmed that hid-topology-watcher.node and HID.DLL were no longer mapped.
However, the service module was still evaluated at the top level. It still resolved the Work Louder dependency graph and loaded the serialport native binding:
@worklouder/device-kit-oai
-> @worklouder/wl-device-kit
-> serialport
-> @serialport/bindings-cpp/.../bindings.node
The severe wireless-mouse stutter remained. Disabling only start() was therefore insufficient on this build.
Effective diagnostic patch: replacing the entire service module
The original service entry was 24,101 bytes and exported only CodexMicroService.
I replaced the complete entry with the following CommonJS module:
"use strict";
const noDeviceState = Object.freeze({
status: "not-detected",
transport: null,
model: null,
error: null,
battery: null
});
class CodexMicroService {
constructor(options = {}) {
this.options = options;
this.deviceState = noDeviceState;
}
getState() {
return this.deviceState;
}
start() {}
async updateLighting() {
return false;
}
async stop() {}
dispose() {
return this.stop();
}
}
exports.CodexMicroService = CodexMicroService;
The remaining bytes through the original 24,101-byte entry boundary were filled with ASCII 0x20 bytes. This preserved the entry size and every subsequent ASAR file offset.
The replacement retains the API used by CodexMicroServiceManager:
- constructor accepting the callback/options object;
getState();start();updateLighting();stop();dispose().
It always reports the normal no-device state and performs no hardware or lighting work.
ASAR integrity update
The patcher parses the ASAR header and identifies the service by content markers instead of relying only on the generated filename.
Required markers include:
@worklouder/device-kit-oai;@worklouder/wl-device-kit;exports.CodexMicroService=;- the expected
getState,updateLighting,stop, anddisposemethods.
It refuses to patch unless exactly one matching entry is found and all API markers match.
For this build:
- original service SHA-256:
506eb3058a2ce87f436dfb191df2ac3d4b675117281790209049a09c3ca98103 - patched service SHA-256:
a59101ef591b4a4e5a6f27ecd9ec7b0187f108e77da7887a1794a939dee222a7
Both the entry's integrity.hash and its single integrity.blocks[0] value were replaced with the patched SHA-256. The ASAR header length was unchanged.
The patch is version/hash pinned. After an application update it rebuilds from the new Store package and aborts rather than guessing if the module layout or API contract changed.
Validation
Static and behavioral validation confirmed that the patched service entry:
- contains no
@worklouderreference; - contains no
hid-topology-watcherreference; - contains no
serialportreference; - exports the expected
CodexMicroServiceclass; - passes JavaScript syntax validation;
- passes calls to
getState,start,updateLighting,stop, anddispose; - matches the updated ASAR entry and block-integrity hashes.
After launching the full-service-stubbed copy, the severe wireless mouse stuttering stopped.
Interpretation
On this system, removing only the HID topology watcher was not enough. The difference between the two copied-runtime tests indicates that the complete optional Codex Micro / Work Louder module-loading path must remain inactive when no supported device is being used.
The “USB device not recognized” symptom is reported as an observation; I am not claiming that Codex permanently damaged or reconfigured the receiver.
Requested product fix
Please provide a supported setting that disables Codex Micro before loading any Work Louder HID or serial native dependency.
When no compatible device is present or the feature is unused, the service should return a stable not-detected state without evaluating:
@worklouder/device-kit-oai;@worklouder/wl-device-kit;node-hid/HID.node;serialport/bindings.node;- the HID topology watcher.
Optional hardware integration should also remain isolated from the Electron main process and fail closed after native loading or discovery errors.
This byte-level replacement is an unsupported diagnostic experiment, not a recommended end-user workaround.
2 Comments
Is this the root cause for the massive stutter that occurs in Codex (not ChatGPT mode, just Codex) on Windows any time you bring the app into the foreground?
I don't know.
However, one thing for sure is that the Codex Micro service seems to affect wireless mice and keyboards. The issue disappears when connected via wire. Since I use them wirelessly, though, I currently have to reapply the patch with every update. Otherwise, the stuttering is far too severe.