Have something to say?

This board helps us understand what actually matters to you, what improves your workflow, what slows you down, and what you’d love to see next. 💡 Upvote what matters to you!

Tell us what would make our gear more useful in your daily setup. Your feedback directly shapes what we build and what we’ll prioritize. 💜

‼️ Important: If you have multiple ideas, suggestions, or bug reports, please create a separate post for each one so we can track and address them individually.

Codex Micro: ChatGPT overrides underglow on non-Codex layers

Environment: macOS Codex Micro Work Louder Input 0.17.1 Device firmware v0.4.1 ChatGPT desktop app with Codex integration Issue: ChatGPT takes global control of the Codex Micro underglow and overrides the lighting configured for non-Codex layers. Steps to reproduce: In Input, configure Layer 2 with custom key backlighting and underglow at nonzero brightness. Completely quit ChatGPT. Switch to Layer 2. Both the key LEDs and underglow work correctly. Open ChatGPT. Switch between the Codex layer and Layer 2. Actual behavior: Opening ChatGPT overrides the device lighting. On Layer 2, the configured key LEDs can still illuminate, but its configured underglow remains off. Quitting ChatGPT restores the Layer 2 underglow. The issue reproduces in both directions regardless of which layer is active when ChatGPT launches. Expected behavior: ChatGPT should control Codex status lighting only while the Codex layer is active. On Layers 2–6, firmware should release RGB control and apply that layer's backlight and underglow settings from Input. Diagnostics: Input successfully saves the Layer 2 lighting configuration. Input logs show successful lights.preview and fs.writebin calls. After ChatGPT opens, the logs show Codex-specific v.oai.rgbcfg commands. The hardware and LEDs are confirmed working because all configured lighting operates normally when ChatGPT is closed. This appears to be a lighting-ownership conflict between ChatGPT's Codex integration and the per-layer Input configuration.

Zandre Azogue 11 days ago

8
🐛

Bugs

Creator Micro 2 Codex compatibility needs clarification and graceful fallback

I’m requesting clarification and a fix for the Creator Micro 2’s behavior with the ChatGPT desktop app’s Codex integration. ENVIRONMENT • Device: Creator Micro 2 Pro • Firmware: v0.4.0 • Work Louder Input: 0.17.2 • ChatGPT/Codex: 26.721.41059 (build 5848) • Platform: macOS • Connections tested: Bluetooth and direct USB-C WHAT HAPPENS Codex detects the Creator Micro 2 and begins initializing it as a Codex-compatible device. v.oai.rgbcfg succeeds v.oai.thstatus RPC 404 “Method not found” After v.oai.thstatus fails, Codex reports a connection problem, disconnects its HID session, reconnects, and repeats the loop. The Creator Micro 2 otherwise works normally as a keyboard/macropad. Work Louder Input and macOS both recognize it, and the problem occurs over Bluetooth and USB. TROUBLESHOOTING COMPLETED • Restarted macOS and ChatGPT • Tested Bluetooth and direct USB-C • Completely quit Work Louder Input • Confirmed Input reports v0.4.0 as current • Confirmed the device works normally as a keyboard/macropad • Confirmed Codex can communicate with it because RGB configuration succeeds • Checked for common keyboard remappers and security utilities • Reproduced the same missing-method response consistently LIVE VIDEO We encountered the compatibility problem during a live Creator Micro 2 unboxing and setup: https://youtube.com/live/NBBaNMBGij8?feature=share RELATED REPORTS ON THIS PORTAL • Exact RPC 404 report: https://feedback.worklouder.cc/p/creator-micro-2-fails-codex-initialization-voaithstatus-returns-rpc-404 • Creator Micro 2/Codex compatibility question: https://feedback.worklouder.cc/p/is-creator-micro-2-also-detected-by-codex-chatgpt-app • Codex Micro v0.4.1 HID/RPC stalls: https://feedback.

tfraley 7 days ago

3
🐛

Bugs

Codex Micro: issues / feature requests

Riffing off some issues: - the agent keys at the top don't care about "normal chat" windows - i can't switch between chat / work / codex using the nipple or the knob - i should be able to clear the current prompt with a button or swipe of the nipple if i make a mistake in the composer input, i thought the point was not to have to use the keyboard - i should be able to submit a prompt for a "normal" Chat (note: not a work / codex conversation) using the "Send message" – instead I get "This action is not available here", wtf! - if i can't edit the Codex layer in the Input app, why can't I carry across the special shortcuts from the codex layer to a new custom layer? and vice versa, why can't I add custom shortcuts to the codex layer? - i should be able to disable bluetooth or turn off the pairing mode function on the touch sensor, i've been switching layers and it's way too sensitive - going to ultra reasoning triggers the new warning about full access - either allow me to acknowledge this once, or give me a shortcut to accept - making a new layer, switching to it on the codex micro using the touch sensor, and deleting the layer on Input seems to leave me on the deleted layer - i can't get live agent status keys to work on a custom layer? get outta here! - give me something useful like a quick way to toggle usage limits and context usage % - maybe give me the option to use the knob contextually to dismiss popups like the full access warning - maybe just give me access and i can make it useful myself thought it’d be more customizable than this, can i get a refund?

sam_altman_2 10 days ago

💡

Feature Request

Can a third-party app drive per-key RGB on the Creator Micro 2?

Hi Work Louder team, I've just ordered a Creator Micro 2 Pro. Before it arrives I'd like to check what's possible on the host side, so I build the right thing rather than guess. I'm writing a small local macOS app for my own use that supervises coding-agent sessions - conceptually the same job the Codex Micro does for Codex, but for a different tool and running entirely on my own machine. Mapping keys to actions is straightforward with Input. What I'd like to know is whether the feedback direction is available to me: lighting individual keys from my own app to show live status, the way the Agent Keys work on the Codex Micro. Three specific questions: Does the Creator Micro 2 expose a raw HID interface (QMK-style usage page 0xFF60, or any vendor-specific interface) that a third-party host application can open and write to? Is there a supported or permitted way to set per-key RGB from a host app — an Input API, a documented report format, a local socket, anything? I understand the Codex integration is a specific partnership; I'm asking about the general capability, not access to that integration. If nothing exists today, is it something you'd consider? A documented "set key N to colour X" channel would make the Micro the obvious controller for any agent-style tool, not only Codex — that seems like it's in your interest as much as mine. Also useful to know, if you can say: is the Creator Micro 2 firmware QMK/VIA-based like the original Creator Micro, or a different stack? I noticed the v2 isn't in QMK mainline, so I don't want to assume. Happy to be pointed at docs if these are already answered somewhere — I couldn't find them. Thanks, Paulo

Paulo Ribeiro 6 days ago

4
💡

Feature Request

Creator Micro 2 fails Codex initialization: v.oai.thstatus returns RPC 404

I’m unable to connect a Work Louder Creator Micro 2 to Codex in the ChatGPT macOS app. Environment Device: Creator Micro 2 Firmware: v0.4.0 USB VID/PID: 303A:8298 ChatGPT/Codex: 26.721.41059 (build 5848) Work Louder Input: 0.17.2 Connection tested: Bluetooth and direct USB-C Steps to reproduce Connect the Creator Micro 2 over Bluetooth or USB-C. Ensure Work Louder Input is closed. Open or restart ChatGPT/Codex. Wait for Codex to detect and initialize the device. Expected result Codex connects to the Creator Micro 2 and enables its controls and agent-status lighting. Actual result Codex detects the device but repeatedly reports a connection problem. Diagnostics show: v.oai.thstatus → RPC 404 “Method not found” Codex Micro control-plane initialization failed The v.oai.rgbcfg command succeeds, indicating that Codex can communicate with the device. The failure occurs over both Bluetooth and USB. Troubleshooting completed Restarted macOS and ChatGPT/Codex. Tested Bluetooth and direct USB-C connections. Confirmed macOS recognizes the device as a USB/Bluetooth HID. Quit Work Louder Input completely. Confirmed Input reports firmware v0.4.0 as current. Confirmed no common keyboard remapper or security utility is claiming the device. The Creator Micro 2 is advertised as directly integrated with Codex, so this appears to be a compatibility mismatch between Codex and the current Creator Micro 2 firmware.

Ansh 8 days ago

3
🐛

Bugs

Creator Micro 2 LED Color broken?

Creator Micro 2 LED Color broken? Hey I have just received my Creator Micro 2 and am successfully using it with the MX Pure Keycaps for Codex. I have noticed that some colors and especially White have a two tone split on the left and right with the LED on the inside of the switch. White for example has a very clear blue on the left and green on the right (side differs per row seems like) and doesn’t look like White at all. Some colors have the same tone on the left and right while some exhibit the same behavior with White being the most drastic. It looks horrible and nothing like the Images on the website or Videos of the Creator Micro 2. The look of the White is unbearable, there is no way this is intended. I tested it on my Mac and on Linux, in Codex and by manually setting the color. Both suffer from the same issue. I’m on the latest 0.6.1 firmware. - Pictures for reference - Bad ones: “White" (blue one one side, green on the other): Light blue (light blue/teal on one, dark blue on the other): Yellow (lime on one, yellow/orange on the other): Lime (green on one, light blue on the oth

maad Tech about 3 hours ago

🐛

Bugs

Creator Micro 2 broken

Yesterday I was happy to receive the Creator Micro 2, as I had the first version and was super happy with how it worked. However, this kinda turned into a nightmare very quickly. I was able to connect the device over BL but I wasn’t able to remap the keys to anything. I always got a failed to update notification. Connecting it to USB fixed it until it didn’t… Suddenly the bluetooth connection started to drop continuously. Tried other connections, same issue. Connecting it to USB would work but not with Codex where the connection-drop loop continued. Then suddenly the underglow and backlights went off. Even though the settings were correct, tried everything… Nothing worked. This left me no choice and try to follow the reset procedure, but that didn’t work either. And then, the unit just went dead. Nothing happened, not with USB. So after some searching found this thread: https://feedback.worklouder.cc/p/firmware-update-v022-kills-the-creator-micro-v2 I followed the instructions, uninstall, reinstall, restart,… tried it all but unfortunately my unit remains dead. So basically that upgrade went bad very quickly. I hope there’s any way to get this thing working again?

Joeri Van Cauteren 3 days ago

2
🐛

Bugs

Subject: Codex Micro (fw v0.4.1) — BLE identity not persisted across power cycles; reconnection impossible without re-pairing (measured evidence included)

Hi Work Louder team, I'm hitting a reproducible BLE reconnection bug on the Codex Micro and I have detailed measurements that may help you pinpoint it. **Environment** - Codex Micro, firmware v0.4.1 (device reports it via `device.status`) - Windows 11 Pro (build 10.0.26200), paired over BLE - Repro rate: every power cycle of the board **Symptom** After powering the board off and back on, Windows never re-establishes a working HID session. The board itself boots fine (its lighting preset shows), but the paired host cannot talk to it anymore. The ONLY reliable user fix is: forget the device in Windows + re-pair from scratch. **Evidence measured on my machine** 1. **The board's BLE address changes between pairings**: two pairings on the same day yielded `FB:02:B1:DD:2A:7E`, then `E8:54:66:01:D2:B8` (both static-random). This suggests the firmware regenerates its identity address instead of persisting it — so the host's existing bond can never resolve the board after a power cycle. 2. After a power cycle, Windows shows a **half-established state**: the BTHLE device node reports `IsConnected = True`, the HID child instances get re-created (new container instance ID), and a WinRT **GATT service discovery succeeds** (`GetGattServicesAsync(Uncached)` → Success, all services enumerated). Yet the **HID layer is completely dead**: output reports are written without any error but never reach the board, and no input reports ever arrive. I observed this state persisting for 17+ minutes. 3. **What un-wedges it** (any of these): a short tap on the board's comms button (board re-initiates the connection); host-side WinRT `GattSession.MaintainConnection = true` + an Uncached service discovery (HID layer comes back within ~90 s); a full re-pair. 4. Your public Creator Micro 2 changelog shows this exact class of fixes ("Improved BLE reconnect and pairing behavior", several v0.4.0 RCs, up to v0.6.0-rc "pairing, reconnection, host switching, sleep recovery"). The Codex Micro firmware line doesn't seem to have received the equivalent yet. **Requests** 1. Is a Codex Micro firmware update with the CM2-class BLE reconnect fixes planned? (v0.4.1 appears to predate them.) 2. Unrelated but important: Input 0.17.2 has **no firmware repository mapped for the Codex Micro**, yet the manual flash screen can offer firmwares of other boards — a user already bricked a Codex Micro this way (see the July 22 feedback post). A guard matching firmware ↔ device type would prevent this. Happy to provide logs, run test builds, or capture Wireshark/BTP traces if useful. Thanks!

jayygigu 9 days ago

💡

Feature Request

Codex Micro “Push to talk” action does nothing, although the physical key works

Description I’m using a Codex Micro with the ChatGPT desktop app on macOS. Environment ChatGPT app version: 26.715.72359 (build 5718) Codex Micro: Connected Input Monitoring: Granted Microphone permission for ChatGPT: Enabled Selected microphone: Elgato Wave:3 Mic key action: Push to talk Expected behavior Holding the Mic key should start recording and show the sea-green lighting animation. Double-tapping should keep recording. Actual behavior Holding or double-tapping the Mic key does nothing. Recording does not start, and there is no lighting change. Troubleshooting completed Confirmed the Elgato Wave:3 works and shows input activity in macOS. Selected the Wave:3 under ChatGPT Settings → Voice → Microphone. Confirmed ChatGPT has macOS microphone permission. Confirmed Codex Micro Input Monitoring is granted. Confirmed the device is connected and other Codex Micro keys work. Configured ChatGPT’s Toggle Dictation shortcut; dictation works through that shortcut. Confirmed the Mic key is assigned to Push to talk. Remapped the same physical Mic key to another action; that action worked. This confirms the physical switch and key event are functional. Restored the Mic key to Push to talk, but it still produces no response or lighting change. This appears specific to the Codex Micro Push to talk action rather than the microphone, permissions, connection, or physical key

GOAT 10 days ago

1
🐛

Bugs

Completed

Codex Micro's agent keys get out of date when reordering pinned chats

Steps to reproduce: In Codex settings, set the “Agent keys” dropdown to “Pinned chats.” Back in the regular Codex view, tap the agent keys in succession to verify that they do indeed toggle between the 6 top pinned chats. Reorder the list of pinned chats by, e.g., dragging the first chat down to the 6th position. Tap the first agent key. Expected behavior: It toggles to the new first pinned chat — i.e., the one that became the first chat after step 3. Actual behavior: It toggles to the old first pinned chat — i.e., the one that became the 6th chat after step 3. Similar issues happen when unpinning pinned chats, or pinning new ones. My guess is that Codex Micro is somehow caching the pinned chats, and then using those cached values when a user presses the buttons — rather than looking up the pinned chats fresh each time. Proposed solutions: Update the cache every time a thread is pinned or unpinned, and every time the pinned chats are reordered. OR, don’t cache at all, and simply look up which ones are pinned at the time the buttons are pressed.

Jesse Pinho 12 days ago

2
🐛

Bugs

Spent $230 for what is starting to feel like trash at least software wise

Brand new out the box really disappointed. The firmware refresh itself succeeded, but the Micro is still not healthy. What I see: The ESP32-S3 was flashed to 100%, followed by “Flash ended,” “Reset done.” After reboot, it correctly reported firmware v0.6.1. macOS currently detects the Creator Micro 2 normally. However, its old keymap.json survived the reflash and is corrupted. Input reports invalid JSON at position 3076. That retained keymap contains KC_K, which likely explains the endless “K.” Shortly afterward, filesystem writes and Codex lighting/status requests begin timing out again. So the firmware binary is installed correctly, but the device’s persistent configuration/storage was not erased. Reflashing the merged firmware again the same way will probably produce the same result. The next repair is a full factory/chip erase, followed by one clean v0.6.1 flash. This will permanently delete every existing Micro profile and layer. If Work Louder Input does not provide an explicit Erase Flash, Factory Erase, or Format Storage option, I recommend contacting Work Louder before using a command-line ESP32 erase—the evidence is now specific enough for support to act on. Currently, Codex cannot establish a working control connection despite macOS seeing the device.

Hamilton Vereen about 1 hour ago

🐛

Bugs