Something else happened instead of the pill appearing

Held the hotkey expecting the level meter, and instead a menu opened, a launcher window popped up, or a different app's window came forward — Coii VoiceInput never reacted at all. This is a different failure from a silent one: something visibly happened, just not the thing that was supposed to. That visible reaction is the tell. It means the key press reached another app first, not that anything is broken.

Why this happens at all

macOS does not keep a registry of which app owns which keyboard shortcut. Every app that wants a global hotkey — one that works no matter what's in focus — registers it on its own, and nothing stops two apps from registering the same combination. When that happens, the key press goes to whichever app claimed it in a way that wins: usually whichever one registered its hotkey first, or whichever one is currently frontmost if the other only listens while active. Coii VoiceInput's default is Hold ⌥ Space — a combination chosen for being easy to hold with one hand, and, for the same reason, one that a handful of launchers, window managers and other dictation or shortcut tools have also picked.

Confirming it's actually a conflict

Before changing anything, it's worth being sure this is a conflict and not one of the other reasons a hotkey can appear to do nothing. The distinguishing sign is a visible reaction somewhere else:

A menu, palette or launcher opens instead. Spotlight, a third-party launcher, or a window-switching tool are the most common culprits, since several of them ship with a hold-a-modifier-and-a-key default that overlaps with a dictation app's own instinct to use something similarly easy to reach.

A different app comes to the front, or a window on screen changes. A window manager or Space-switching tool reacting to the same combination looks like this — the screen changes, but not in the way dictating would change it.

Nothing happens anywhere, ever. This is the other failure mode entirely, and it points toward a permission the app hasn't been granted rather than a conflict — a conflicting app, by definition, does something, even if it's not the something that was wanted.

If the reaction is inconsistent — sometimes the pill appears, sometimes the other app reacts instead — that pattern fits a conflict too: it usually means the colliding app only claims the hotkey while it's frontmost, so which one wins depends on what had focus a moment before the key was pressed.

Finding which app has it

Check what reacted, and start there. If a specific app's window came forward or a specific menu opened, that app's own settings almost certainly have a hotkey preference using the same combination. Most apps with global shortcuts put them under a Preferences or Settings pane, often labeled Shortcuts, Hotkeys, or General.

Think back to what was installed or updated recently. A hotkey that worked yesterday and stopped today usually traces to something new — a launcher, a clipboard manager, a window-tiling tool — picking up a default shortcut that happens to overlap, without anything about Coii VoiceInput itself having changed.

Check System Settings → Keyboard → Keyboard Shortcuts. macOS itself reserves some combinations for system actions — screenshots, Spotlight, input source switching, accessibility shortcuts — and one of those can collide with an app's hotkey exactly the same way another app can.

The fix: change one of the two

There is no way to make two apps share one global hotkey — exactly one of them gets it, every time. The fix is deciding which app keeps the original combination and changing the other:

Change Coii VoiceInput's hotkey in its own settings if the colliding app's shortcut is one that's used often and worth keeping as is. Pick a combination that isn't already a system shortcut and isn't a default that other common utilities tend to reach for — a three-key combination is less likely to collide than a two-key one, simply because fewer apps default to it.

Change the other app's hotkey instead, if it's used rarely or its shortcut doesn't need to be that specific combination. This is often the faster fix when the colliding app is something installed recently and not yet relied on out of habit.

Test with a short dictation in an empty text field afterward, holding the new combination and watching for the pill and level meter, before trusting it during real work in something that matters. A conflict resolved incorrectly — the wrong app changed, or a new combination that turns out to collide with something else entirely — shows the same way the original problem did, so confirming it actually worked is worth the ten seconds it takes.

When more than two apps are involved

Occasionally a hotkey collides with more than one other app at once, particularly on a Mac with several utilities that each grab a default combination on install without checking what else is already using it. If changing the obvious culprit doesn't fully fix things — the pill appears sometimes but a second app still occasionally wins — the same diagnostic applies a second time: notice what reacted instead, check that app's settings, and change it too. It's slower than a single fix but no different in kind.

A Mac accumulated over several years tends to have the most of these stacked up, simply because more utilities have passed through it — some still running, some quit but left registered in a way that isn't obvious from the Dock. Going through recently installed menu-bar utilities one at a time, rather than assuming the newest install is automatically the cause, catches the cases where an older, half-forgotten tool turns out to be the actual owner of the combination.

Why the same hotkey can behave differently on two Macs

A combination that works cleanly on one Mac and collides on another, even with what looks like the same set of apps installed, usually comes down to which utilities are actually running in the background rather than just installed. An app sitting in Launchpad but never opened claims nothing; the same app running quietly in the menu bar, set to launch at login, claims its hotkey the moment it starts. Checking the menu bar itself, not just the Applications folder, for anything unfamiliar is often faster than working through every installed app's settings one by one — a menu-bar icon for something rarely opened is frequently the one holding a global shortcut nobody remembers granting it.

Picking a hotkey that's unlikely to collide again

Setting up a dictation hotkey covers choosing a combination up front that avoids both common system shortcuts and the defaults a handful of popular launchers and window managers tend to ship with. A combination involving three keys, or one that isn't a natural first guess for "quick access to something," is meaningfully less likely to collide with whatever gets installed next, compared to a two-key combination that several kinds of utility all reach for by instinct.

Ruling out a launcher specifically

Launcher and productivity-shortcut apps are the single most common source of this particular conflict, because their entire purpose is claiming a fast, memorable global combination the moment they're installed — often before the person installing them has even opened the app to see what shortcut it picked. The comparison with Raycast covers one specific case of this, including which combinations each tool tends to default to, if a launcher is the suspected cause here.

What a conflict is not

It's worth ruling out the two problems this can look like from a distance. If the hotkey reaches Coii VoiceInput fine but the words land somewhere unexpected, that's a window-focus problem, not a conflict — the pill and level meter still appeared in that case, which a true conflict prevents entirely. And if absolutely nothing reacts anywhere, not even another app, that points toward a microphone permission that hasn't been granted rather than two apps fighting over the same key.

Understanding what "hold" actually means here

Push-to-talk dictation depends entirely on the hotkey reaching the app the instant it's pressed — there's no fallback trigger, no menu-bar click that substitutes for it, because the whole design is built around a key held down for exactly as long as speaking takes. That's precisely why a conflict is worth fixing properly rather than working around: a hotkey that only sometimes reaches the app turns a one-motion action into something that has to be checked every time before trusting it.

Nothing about a conflict costs any words

A hotkey that's claimed by another app means a dictation never started, which is a different situation from one that started and then went missing — there's nothing to recover here, because nothing was said into the app in the first place. Once the conflict is fixed, dictating works exactly as before: hold, speak, release, and the transcript is written to history the instant the key comes up, the same as any other successful dictation.

Deciding which app deserves the combination

When both apps have a real claim on the same easy-to-reach combination, it's worth deciding deliberately rather than by whichever one happened to win first. The app used more often, or the one where re-learning a new shortcut costs more attention, is the one worth keeping on its original hotkey; the other one absorbs the change. For a launcher or window manager opened dozens of times a day out of muscle memory, changing its shortcut is a real cost for a few days until the new one becomes automatic — the same is true of a dictation hotkey, which is exactly why it's worth making the call once, deliberately, rather than discovering the collision again a week later and re-deciding under time pressure.

A habit worth adopting when installing something new

Once a hotkey has been fixed after a conflict, the same collision can reappear the next time a new utility is installed with its own default global shortcut. Checking a new app's keyboard-shortcut settings once, right after installing it, and changing anything that looks like it might overlap with an existing habit — before the collision actually happens — is a small amount of friction up front against a repeat of the same troubleshooting later. It's a five-minute habit that mostly pays for itself the first time it prevents a hotkey from silently stopping mid-project.

Try it once the hotkey reaches the app cleanly — a single test dictation in an empty text field is the fastest way to confirm the fix actually held.