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”
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
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.
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.
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.
Environment Creator Micro v2 (wireless), firmware 0.6.2 Work Louder Input 0.18.4 Windows 11, connected over Bluetooth ChatGPT desktop app with Codex integration Configuration Layer 1: native ChatGPT / Codex Layer 2: Windows shortcut layer configured in Input ChatGPT device settings: Brightness 100%; Auto-dim 3 minutes Issue After switching to Layer 1, the outer underglow and the bottom/backlight illumination turn off within a few seconds. Layer indicators and some native status lighting may remain visible. When I switch to Layer 2, the outer underglow and bottom/backlight remain continuously lit. The Layer 2 mappings also work after Input is closed. This is different from the completed report “ChatGPT overrides underglow on non-Codex layers”: my Layer 2 lighting is working correctly on firmware 0.6.2. The behavior appears limited to Layer 1 / native ChatGPT mode. Expected behavior / question With Brightness at 100% and Auto-dim set to 3 minutes, should Layer 1 underglow and bottom/backlight remain on for that interval? If this is intentional native ChatGPT behavior, please document it or provide a setting to keep the Layer 1 underglow/backlight on.
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
I’m having a recurrent connection problem with the Codex Micro after my Mac wakes from sleep. What happens: Before sleep, the Micro works normally over Bluetooth. After the Mac has been asleep overnight, I tap the Micro to wake it. It flashes blue. Layers 2 and 3 still work normally Codex layer 1 does not work. The Agent Keys, dial, and other Codex controls do nothing, and ChatGPT does not reconnect to the device. Fully quitting and reopening ChatGPT immediately fixes the problem. I do not need to re-pair Bluetooth or restart the Micro. This has happened more than once. It makes the Codex layer unreliable because I have to restart ChatGPT after the computer sleeps.