Can’t tell, but seems like my device came with old or broken firmware, or there’s a bug with the Input app. Input 1.0.0 can't read my Creator Micro 2's firmware version. device.status returns 404, and the legacy 'version' request times out, but sys.version returns v0.1.50. So Input never offers the firmware update. None of my LED lights change for anything, they appear stuck on white no matter the setting. Codex reports “Creator Micro input remains available, but lighting and battery updates are temporarily unavailable” and “Connected with limited functionality”
Hello - I purchased one of the original ‘clicky’ codex mini keyboards from OpenAI supply. I’m not really sure how exactly it happen but I carry it in a brief case with my MacBook when traveling, and this last time doing that proved too much for dial-knob, and it’s now busted off. Anyway, I’m just hoping now to get the correct part number so I can take for repair here locally in Silicon Valley. Also, I don’t want to take this time to complain irrately but this is probably useful feedback…As I gathering up the pieces to inspect I noticed the rotary encoder shaft was so cheap that it made the heavy weight of the HID as a whole seem deceptive, at least a quality indicator—the metal housing cap sliced right through notch meant for seating the encoder shaft, that break what provided the give to bend the shaft ring of the cap.
On Windows 11, when Creator Micro 2 Base is connected and Codex Desktop is running, the display never turns off and Windows never enters automatic sleep. I traced this to the Creator Micro 2 vendor HID interface: VID 303A / PID 8297 Usage Page FF00 / Usage 0001 Firmware 0.6.2 About every 60 seconds, Codex appears to request device.status. Creator Micro 2 replies with three HID input reports, and those reports reset Windows GetLastInputInfo() to approximately zero. The HID payload decodes to a device.status response. { "result": { "version": "0.6.2", "profile_index": 0, "layer_index": 1, "battery": 0, "is_charging": false }, "id": 289, "method": "device.status" } powercfg /requests shows no active requests. Closing Codex immediately stops the periodic HID traffic, and Windows idle/display sleep works normally again.
SUMMARY While Input is running with its normal Dock icon visible, a second matching Input icon repeatedly appears beside it and immediately disappears. The Dock expands and contracts around the transient entry. The main window remains open and usable. The window movement in my recording is intentional: I am dragging it to demonstrate that the window works. The defect is the duplicate, flickering Dock icon, not the window movement. ENVIRONMENT • Input 1.0.0 (bundle identifier: it.focusense.input-app) • macOS 27.2, build 26B5091g; arm64 • Bundled Electron 40.10.6 • Creator Micro 2; firmware 0.6.3-rc.12 reported in Input's log • Observed 29 September 2026 OBSERVED BEHAVIOR 1. Input is already running, with the main window open and its usual icon in the Dock. 2. A second matching icon briefly appears next to it. 3. The extra icon immediately disappears and returns intermittently. The behavior repeats within a 13.35-second recording. The extra icon is visible near the start, absent around 2 seconds, and returns around 3.5 seconds. Dragging the window is not an established trigger. A clean-start reproduction recipe and frequency across separate sessions are not yet established. EXPECTED One stable app representation while Input is running, without an unexplained second icon repeatedly entering and leaving the Dock. IMPACT Distracting Dock flicker and layout movement. It looks as though Input is repeatedly launching even though its main window remains usable. No crash or data loss observed. INVESTIGATION — CAUSE NOT YET CONFIRMED A later process check sampled 20 times over roughly five seconds and found one stable main Input process plus the same four Electron helpers. All installed helper bundles declare LSUIElement=true, and Input requests a single-instance lock. No second main process was observed. This sampling was not synchronized with the original recording and cannot exclude very short-lived child processes. Read-only inspection of the installed app shows explicit app.dock.show()/hide() calls around main-window creation/destruction, tray reopen, and autostart. Electron 40.10.6 contains a workaround for rapid Dock hide/show transitions causing duplicate icons on macOS. This is an investigation lead, not proof that those transitions caused my symptom: https://github.com/electron/electron/blob/v40.10.6/shell/browser/browser_mac.mm#L474-L530 The radial-menu and cheat-sheet windows are transparent, non-focusable macOS panels configured with skipTaskbar:false. Their lifecycle is another path to check; that setting has not been established as the cause. RELATED REPORT / MORE SPECIFIC LEAD I found this existing report describing similar Dock behavior on the same macOS build: https://feedback.worklouder.cc/p/inputs-dock-icon-repeatedly-bounces-while-the-application-remains-running That reporter observed short-lived osascript processes launched by AppSense registering under Input's bundle identity as foreground applications. Their follow-up says a local change to read NSWorkspace.sharedWorkspace.frontmostApplication stopped those foreground registrations while polling continued. These are the other reporter's findings, not independently verified on my installation. Please consider whether my duplicate-icon symptom is the same issue and link or merge it if appropriate. REQUESTED CHECKS • Identify the transient Dock item's owni
macos, apple silicon. nomad [e] on firmware v0.6.1. input 0.18.3 never detects the keyboard – “no device found” – even though macos enumerates it correctly: • usb product name = “nomad e”, idvendor 0x303a, idproduct 0x1001 • serial port /dev/cu.usbmodemf09e9e10355c2 present • not in esp32 rom bootloader • display and menu fully responsive what worked: rolling input back to 0.6.1-rc.1. it detects the keyboard immediately. so 0.18.3 appears to have lost support for firmware v0.6.1. second problem: from input 0.6.1-rc.1, setup > download latest firmware version 0.9.0 downloads the file but flashing fails with “there has been an error! retry”. retried several times, same result. device still on v0.6.1 and still working, so nothing was bricked.
I’m using a Creator Micro V2 with Work Louder Input 18.0 and firmware 0.6.1 on a Mac running macOS Golden Gate 27. Bluetooth has been extremely unreliable. When the Creator Micro goes to sleep, it often fails to reconnect properly after waking. Restoring the connection can take 15–20 minutes of restarting the device, forgetting it in macOS, and pairing it again. Each successful re-pairing also appears as another Bluetooth device. I now have five or six duplicate Creator Micro entries. Even after turning the device off and choosing “Forget This Device,” the old entries continue to appear under Nearby Devices. I originally assumed this was caused by the beta software or firmware, but the problem remains after moving to the full Input 18.0 release with firmware 0.6.1. Expected behavior: The Creator Micro should reliably reconnect to the same Bluetooth pairing after waking from sleep. Actual behavior: It frequently fails to reconnect, requires extensive troubleshooting and re-pairing, and creates duplicate Bluetooth entries. At this point, the Bluetooth experience is frustrating enough that the device doesn’t feel dependable for daily use.
Hello, I received my Nomad E v2 keyboard today. When I tried to connect it to the Input app, it switched to bootloader mode (the keyboard was glowing yellow). I then tried to reset the keyboard using the reset button underneath the spacebar. After that, the keyboard started blinking yellow and has not responded to anything since. I have tried reconnecting it, but the keyboard still does not respond. Could you please let me know how I can get the keyboard working again?
I wanted to reset my key configuration, so I followed a guide and updated the firmware on my Figma Creator Micro using QMK*. However, after the update, the backlight settings disappeared. How can I restore the backlight configuration? https://i.imgur.com/HrmbGRL.png
I connected my nomad [e] 2 to my iPhone via bluetooth, I have musiv playing via Apple Music but it’s not showing up on the display. I am on iOS 27.2 with firmware 0.3.0-rc.16
If codex micro is connected via usb cable to a PC, and the PC sleeps, codex micro switches to bluetooth finding mode. Glowing, blinking and what have you — obviously noone can sleep in the room with codex. What should be done: if pc sleeps, codex that is connected via USB sleeps also. Why I don’t connect it via bluetooth? The fucker immediately wakes up my win 11 pc as soon as pc sleeps. But that is another bug. — How I fixed this for now: removed the battery alltogether. This way if PC sleeps, codex loses power → no glow.
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.
currently having an issue with the space bar. I believe it’s an issue with the stabilizers being too tightly squeezed by the auxiliary pins around them. Has anyone ever had this issue? I’m thinking of either cutting it off or sand the space bar stabilizer keycap connector. Any ideas?
I recevied my creeator micro 2 after coming back from a trip, and after connecting it to my windows pc via usb, the input software prompted me to update to the lastest firmware, however, after it showed that it was successfully installed, the device seemed to be kept in the bootloader mode with that yellow glow. I tried soft reset and re-try the process but no luck. If you have any clue on how to fix the issue, please do let me know! Thanks!
Environment: Creator Micro V2 / Input 0.18.0 / firmware flashed 0.4.0 to 0.6.1 / macOS over Bluetooth, also seen on Windows 11. A single physical key press registers as two or more presses. It affects every key, not one switch. THE DECISIVE TEST: after the problem survived the firmware update, I ran a full “Reset settings” from the Setup tab, leaving the device factory-blank (no custom layers, no macros, no Multi keys). I then assigned a single plain letter A to one key via Basic, opened a plain text editor, and tapped it slowly ten times. I still get doubled characters (aa) from single presses. That rules out everything on my end: not my keymap (device was wiped), not Multi-key logic (none existed), not macro complexity (a single unmodified keystroke). TIMING DETAIL: before the reset I built a Multi key to characterise it (tap types 1, double-tap types 2, hold types 3). One quick tap: expected 1, got 1 or 2 - Deliberate double-tap: expected 2, got 2, 22, or 21 - Hold ~1 second: expected 3, sometimes got 31 A single tap yielding 2 means one press bounces into two contacts inside the 250ms tap window. Hold yielding 31 means the RELEASE bounces too: the hold fires, then letting go registers as a fresh tap. So the board chatters on both make and break. This also corrupts ordinary single-action keys, not just Multi keys. A Delete key can remove two items from one press, which makes the pad risky to use in Outlook. ALSO: since flashing 0.6.1, the Firmware version field in Setup displays blank. Device model and Input version populate normally. It read 0.4.0 before the update. Possibly unrelated, possibly a sign the flash did not complete cleanly. I saw the report here about a corrupted keymap.json surviving a firmware update and producing repeated key input (“endless K”). Mine looked similar, which is why I tried the reset, but the reset did not resolve it. QUESTIONS: Is this known on this hardware revision or firmware line? 2. Is there a debounce / tapping-term setting, or a firmware build with a longer debounce window? 3. Should the Firmware version field be blank after a successful 0.6.1 flash? 4. If this is a hardware fault, what is the warranty process? Happy to run any diagnostic or reflash. My profile is exported, so wiping the device again costs me nothing.
The actions trigger but have no effect whatsoever in Codex. I would have expected these to acts as forwards and backwards arrow do in a web browser.
I’m having real trouble using my new Creator Micro 2 with Codex, which is what I bought it for. I connected it yesterday on BT#1 and this morning it wouldn’t connect and I end up having to pair it again, still on #1, which leads to both showing up, somehow. My presets keep disappearing from my keymap as I keep having to reconnect the Micro and I guess Input thinks it’s a new device. Codex shows it as connected but it is not working because the ChatGPT preset randomly disappears from the available ones.
Input Version 0.18.0 (0.18.0) MacOS Tahoe 26.2 Did both a manual reset on the board itself and multiple power cycles / modes. Nothing seems to get it to escape out of this state
Environment: - Creator Micro V2 wireless - Work Louder Input 0.18.4 - Firmware 0.6.2 - Windows 11 Issue: CODEX and ChatGPT are both visible in the Windows Start menu. However, in Work Louder Input > Layer 2 > Smart Action > App: - Searching CODEX returns "No software found". - Searching for ChatGPT also does not return ChatGPT as a usable app result. This prevents assigning a Layer 2 key to launch CODEX or ChatGPT through the Smart App action. Expected behavior: The Smart App picker should detect CODEX and ChatGPT from the Windows Start menu, or provide a manual executable/path picker.