My Mac voice shortcut stopped responding, or won't reassign

Jude Mercer, SEO and Content, Memoe — 27 October 2026

Two bug reports against FluidVoice, a Mac dictation app, landed the same day in October 2026, about four hours apart. Neither is about speech recognition. Both are about the key itself — the part of a voice shortcut that has nothing to do with listening.

The key that won't come free

Joshua Gourneau filed one: disable a shortcut in FluidVoice's settings, and the key it used stays "reserved" by the disabled shortcut anyway — so you cannot hand that same key to a different shortcut until you first change the disabled one to something else. In his own words:

"When I disable the Command Mode shortcut, the Keyboard Shortcuts tab shows ‘no key set’ for it. But the app still keeps the old key registered to Command Mode. So I cannot assign that key to Primary Dictation. I must change the Command Mode key first. Then the key becomes free." (altic-dev/FluidVoice issue 1213, 21 October 2026)

The setting says the shortcut is off. The key disagrees.

The key that responds, then doesn't

Byron Wall filed the other, earlier that same day: with FluidVoice's "Reliable Paste" mode and an Option-based hotkey, a transcript sometimes fails to land in Chrome, even though FluidVoice's own log says it was inserted. The cause he traced is specific: macOS merges whichever modifier key is still physically held into the keystroke the app posts afterward, so a paste meant to arrive as ⌘V arrives as ⌘⌥V instead, which Chrome has no binding for. In his words:

"macOS ORs physically held modifiers into posted events by default… so the target app receives ⌘⌥V instead of ⌘V, even though the events set `flags = .maskCommand`. Chrome has no ⌘⌥V binding, so nothing is pasted… It's intermittent because it depends on how quickly the hotkey's modifiers are released." (altic-dev/FluidVoice issue 1212, 21 October 2026)

Nothing crashed, nothing was logged as a failure, and the fix depends on how fast a finger lifts off a key.

Two different things to go wrong, one part in common

These aren't the same bug. One is a setting that doesn't let go of a key it no longer uses. The other is macOS folding a key you're still physically holding into a keystroke posted a fraction of a second later. What they share is where they live: not in speech recognition, but in the shortcut mechanics around it — how a key gets assigned, and what happens to the one you're still pressing when the app acts on it.

What Moe holds instead

Moe's default way in is one key, held: hold right Option, say what you need, let go when you're done. There's no shortcuts table with several commands each claiming their own key, so there's nothing for a disabled one to go on reserving — pick a different key in Settings › Voice › Hold a key to talk and it works straight away, with the old one simply not in use any more. And letting go of the key doesn't post a keystroke into whatever app you were in; it ends the turn Moe is listening to. The two bugs above happen around a key doing something else. Moe's key does one thing.

The docs cover what to check if Moe's own shortcut goes quiet — Accessibility not yet on, another app already answering to the key you picked, or a press that landed mid-shortcut in a different app and was dropped on purpose — in Talking to Moe › If the shortcut does nothing. If you'd rather hold nothing at all, there's also Talking to Moe › Hands-free, with nothing held down. Changing which key you hold is its own page: change the talk key.

What it needs

Moe needs an Apple silicon Mac on macOS 15 or later. This page is about the shortcut mechanics, not a verdict on FluidVoice, which is a different app solving a different problem.