Held the hotkey, said the sentence, let go — and no pill appeared, no level meter moved, nothing landed anywhere. The instinct is to suspect the microphone itself, but on a Mac that plays audio and takes video calls normally, the far more common cause is that the app was never granted permission to use it, or macOS has the wrong device selected as input. Both are settings, not hardware failures, and both are fixed in under a minute once identified correctly.
Check the permission first — it is the honest fix most of the time
macOS requires an explicit, one-time grant before any app can hear anything, and if that grant was never given — or was silently reset by a system update, a reinstall, or a move to a new Mac — the app has no way to raise an error about it. The hotkey does nothing because the request to open the microphone was refused before it started.
Open System Settings → Privacy & Security → Microphone and look for Coii VoiceInput in the list. Three states are possible: it isn't listed at all, it's listed but switched off, or it's listed and on. Only the third one works. If it's missing entirely, launching the app and holding the hotkey once should trigger the system permission prompt again — approve it there rather than trying to add the app manually. If it's present but off, switch it on and hold the hotkey again; no restart is usually needed, though quitting and reopening the app clears up the rare case where it is.
Testing the microphone after re-enabling it in System Settings.
Confirm macOS itself can hear the microphone at all
Before assuming the app is the problem, rule out the hardware and the system input selection independently of it. Open System Settings → Sound → Input and speak while watching the level meter there. If it moves, the microphone and macOS agree it's working, and the issue is specific to how the app is reaching it — almost always the permission above. If it does not move, the problem is one level lower than the app and worth solving there first:
The wrong device is selected as system input. A Mac with a Bluetooth headset, a USB microphone, or an external display with a built-in mic connected has more than one input device available, and macOS keeps a single system-wide default. If the intended microphone isn't the one selected in this same Sound settings pane, nothing reaching it will register, regardless of which app is asking.
The microphone is muted at the hardware level. Some external microphones, webcams, and headsets have a physical mute button or switch, separate from anything in software. It's easy to bump without noticing, and it silences input before macOS ever sees a signal.
A privacy shutter or case is covering a built-in microphone opening. Uncommon, but worth a glance on a laptop that has been in a bag or case recently.
Bluetooth microphones have a failure mode of their own
A Bluetooth headset connecting successfully — showing as paired and selected in the Bluetooth menu — does not guarantee it is also selected as the input device. macOS treats Bluetooth output and input as separate settings, and a headset can be actively playing audio through its speaker while the Mac's built-in microphone is still the one listening. This shows up specifically as "the headset works for calls but not for dictation," because a calling app may switch input devices automatically in a way this one, correctly, does not do on its own.
The fix is the same Sound settings pane: confirm the headset is selected under Input, not just under Output or in the Bluetooth device list. Headset-specific quirks — including the audio-quality mode some Bluetooth headsets drop into once a microphone is active — are covered in more detail separately, since they affect more than just detection.
Another app holding the microphone
On most Macs, multiple apps can use the microphone without conflict, but a video call app left running in the background, a screen recorder capturing system audio, or another dictation tool still active can occasionally hold exclusive access on some hardware and macOS configurations. If permission is confirmed on and the system input meter moves correctly but the app still shows nothing, quitting anything else that touches audio and trying again rules this out quickly.
What the app is and isn't doing while this is happening
It's worth being precise about what "the microphone isn't detected" actually means here, because it isn't the same failure as a bad recording or a garbled transcript — it's that the microphone was never opened at all. The microphone opens only while the hotkey is held and closes the instant it's released; there's no background listening, no wake word, and no always-on stream that could be silently failing. That's a deliberate design choice, not a corner cut for this fix — but it does mean there's no ambient audio level to check outside of an actual hold, which is why testing with the hotkey held down, watching for the pill and the level meter, is the fastest way to see whether the fix worked.
- 1Key downthe target is chosen here
- 2You speaklevel meter, over your work
- 3Key up
- 4Written to historybefore the engine is asked
- 5Engineon your Mac
- 6Typedabout half a second
Working through it in order
- Confirm the permission is granted in System Settings → Privacy & Security → Microphone. This alone resolves the majority of cases.
- Confirm macOS itself hears the microphone, independent of any app, using the level meter in Sound settings.
- Confirm the correct input device is selected, especially with a Bluetooth or USB microphone connected.
- Rule out a hardware mute on an external mic or headset.
- Quit other apps that use audio and try again.
- Restart the app, and only after that, the Mac — a full restart clears a small number of stuck permission states that toggling alone doesn't.
Each step rules out one layer — system permission, system input selection, hardware, another app — rather than guessing at all four at once, and the level-meter test in step two is the fastest way to know which side of the problem is being dealt with before spending time on the wrong one.
If it worked yesterday and stopped today
A permission that worked before and stopped without anything being changed on purpose usually traces to a macOS update. Apple periodically re-prompts for microphone access after a major system update as a privacy safeguard, and if that prompt was dismissed or missed rather than approved, the permission reverts to off without any other symptom. The same Privacy & Security check above catches this; there's rarely anything else going on.
A less common but real cause is a full reinstall of the app itself, rather than an update. Depending on how it was reinstalled, macOS occasionally treats the new copy as a distinct entry and drops the old permission grant instead of carrying it forward. The Privacy & Security list will show whether that happened — a duplicate or missing entry there, rather than one that's simply switched off, is the signature of this specific case, and the fix is the same: toggle it on, or grant it fresh if the prompt appears again.
Permission is granted per user account, not per Mac
A detail that catches people on a shared or work Mac with more than one login: microphone permission in System Settings is scoped to the macOS user account that granted it, not to the machine as a whole. Switching to a different account — a separate profile for a different family member, or a work versus personal login on the same Mac — starts with no permission granted at all under that account, even though it was already approved under another one. This isn't a bug carrying over incorrectly; it's the same privacy boundary macOS applies to every app that uses the microphone, camera, or similar hardware. The fix is simply granting the permission again under whichever account is currently active, the same way it was granted the first time.
External audio interfaces and USB hubs
A USB microphone or audio interface connected through a hub, rather than directly into the Mac, occasionally drops out or fails to register at the exact moment a dictation starts, particularly on a hub that also has other devices drawing power through it. This looks identical to a permission problem from inside the app — nothing happens when the key is held — but the system-level test in the section above catches it: if the Sound settings level meter itself doesn't move, or moves inconsistently, the interface or its connection is the more likely explanation than anything in the app or its permission. Connecting the interface directly to the Mac, or to a powered hub if a hub is necessary, is worth trying before further troubleshooting.
Ruling out a hotkey problem instead
A hotkey that silently does nothing can look identical to a microphone problem from the outside — no pill, no meter, no error, either way. If the level meter in System Settings → Sound → Input moves correctly when speaking outside of any app, but the app's own pill never appears even with permission confirmed, the hotkey itself may be claimed by another app rather than reaching Coii VoiceInput at all, which is a different fix and worth checking once the microphone itself is confirmed working. Setting up a hotkey combination less likely to collide with anything else is the longer-term fix if this turns out to be a repeating problem rather than a one-time setting.
How this compares to Apple's own dictation
Apple's built-in dictation asks for the same category of system permission and can fail the same silent way when it isn't granted — this isn't a gap specific to a third-party app, it's how macOS handles microphone access for everything. The full comparison covers where the two actually differ, which is mostly in what happens after the microphone is working, not in how permission is requested.
When to stop troubleshooting and just restart the Mac
If the permission is confirmed on, the system input meter moves correctly, the right device is selected, and nothing else is holding the microphone, but the app still doesn't respond to the hotkey, a full restart of the Mac — not just the app — resolves a small remaining category of stuck permission states that nothing short of it clears. It's a reasonable last step precisely because it's rare that any of the earlier, more specific checks miss the actual cause; a restart fixing it after everything else has been ruled out is more common than a restart fixing it as the very first thing tried.
Once it's working again
There's nothing to configure differently going forward once the permission and input device are both correct — push-to-talk dictation simply resumes working the way it's designed to: hold, speak, release. What push-to-talk actually means as a mechanism is worth understanding once, since most of what looks like a microphone problem on a Mac traces back to one of the settings above rather than anything wrong with the hardware itself. Try it once the microphone is confirmed working end to end.