Critical: Codex Micro v0.4.1 HID/RPC stalls — 116 disconnects in 2 days, including while idle

Severity: Critical / currently unusable

The Codex Micro is not reliable enough for normal use. The ChatGPT desktop app repeatedly displays:

“Codex lost communication with your Codex Micro and is reconnecting automatically. If your computer still shows the device and the problem continues, a keyboard remapper or security tool may be blocking access.”

This happens during active use and while the device is idle. It interrupts device controls and live RGB status, sometimes several times within a few minutes.

ENVIRONMENT

• Device: Codex Micro

• Firmware: v0.4.1

• Connection: Bluetooth Low Energy HID

• Host: Apple Silicon Mac

• macOS: 26.5.2 (25F84)

• Current ChatGPT app: 26.721.41059, build 5848

• Also reproduced on: 26.721.31836, build 5828

• Latest incidents: battery 87%, is_charging=false

• Work Louder Input: not installed or running

• No detected Karabiner, BetterTouchTool, Logi Options, SteerMouse, USB Overdrive, Keyboard Maestro, CrowdStrike, Sentinel, Jamf, Zscaler, Sophos, or Microsoft Defender process/system extension

• Mac is not MDM-enrolled

Bluetooth address, username, local paths, conversation IDs, and RPC IDs are intentionally omitted.

MEASURED FAILURE COUNT

ChatGPT’s local Codex Micro service recorded 116 connection invalidations over two days.

2026-07-24 UTC:

• 91 total

• 71 battery-rpc / device.status timeouts

• 19 lighting RPC timeouts (v.oai.rgbcfg or v.oai.thstatus)

• 1 lower-level SDK/HID read failure

• 67 while not charging, 23 while charging, 1 before charge state was available

2026-07-25 UTC through 10:42:

• 25 total in about 90 minutes

• 20 battery-rpc / device.status timeouts

• 5 lighting RPC timeouts

• All 25 occurred while is_charging=false

Across both days, at least 92 failures occurred while the device was not charging. Charging is not required to reproduce this.

CANONICAL FAILURE SEQUENCE

The automatic battery/status poll normally runs about once per minute. There is no request backlog: maximum observed device-call queue depth was 1 across 1,906 queued calls.

Representative incident:

06:59:32.668 Sending RPC call: device.status 06:59:42.672 WLDeviceError code=TIMEOUT, “Request timed out” 06:59:42.673 Connection invalidated: reason=transport-unavailable, source=battery-rpc 06:59:42.673 Disconnecting HID device 06:59:43.723 Connecting with HID 06:59:43.871 device.status response: version=v0.4.1, battery=100, is_charging=false

The call stalls for exactly 10 seconds. ChatGPT then closes only its HID session and reopens it; the device responds again in under 0.2 seconds. The same sequence occurs for v.oai.rgbcfg and v.oai.thstatus lighting calls. Two lower-level events also contained “could not read from HID device.”

WHY THIS DOES NOT APPEAR TO BE A REMAPPER OR SECURITY-TOOL CONFLICT

1. No relevant remapper, Work Louder Input process, security agent, third-party HID system extension, or MDM profile was detected.

2. Calls are serialized, with maximum queue depth 1, so this is not a growing RPC backlog.

3. Most failures are caused by ChatGPT’s automatic once-per-minute device.status poll, including when there is no user input.

4. macOS continues to show Codex Micro as a connected BLE keyboard during the failure.

5. A macOS bluetoothd log check around a confirmed timeout showed no Bluetooth link disconnect/reconnect. Only the application-level vendor HID session was reopened.

The evidence points to an intermittent stall in the device’s vendor HID/RPC endpoint or the Work Louder device transport library, not the Bluetooth pairing disappearing.

REPRODUCTION

1. Pair a Codex Micro running v0.4.1 with macOS over BLE.

2. Open the current ChatGPT desktop app with Codex Micro integration enabled.

3. Leave the device connected, even without pressing anything.

4. Allow the automatic device.status polling and live RGB updates to run.

5. Within minutes to tens of minutes, a call receives no response for exactly 10 seconds.

6. ChatGPT shows the lost-communication banner, closes the HID session, and reopens it.

7. The device usually responds immediately after the HID session is reopened.

The latest run reproduced 25 times in roughly 90 minutes while not charging.

EXPECTED

• The vendor HID/RPC endpoint remains responsive while the BLE keyboard remains connected.

• Battery polling and RGB updates do not cause repeated HID session resets.

• A single non-critical battery or lighting timeout is retried before invalidating the entire device connection and showing a disruptive banner.

REQUESTED ACTION

Please treat this as a high-priority firmware/transport defect:

1. Reproduce with Codex Micro v0.4.1 on macOS using the once-per-minute device.status polling pattern.

2. Investigate the vendor HID/RPC endpoint, BLE sleep/wake behavior, and Work Louder transport read loop.

3. Provide a Codex Micro-specific firmware update or beta containing BLE/HID reconnect and sleep-recovery fixes.

4. Ask the ChatGPT integration owner to retry failed battery/lighting RPCs before invalidating the entire connection.

5. Provide a supported diagnostic collection path and confirm an owner/ETA. The current frequency makes the product effectively unusable.

Possibly related reports:

• https://feedback.worklouder.cc/p/codex-micro-freezes

• https://feedback.worklouder.cc/p/codex-micro-disconnects-from-bluetooth-when-charging-via-usb-c

• https://feedback.worklouder.cc/p/subject-codex-micro-fw-v041-ble-identity-not-persisted-across