Mac Dictation Not Working in Cursor? 10 Fixes That Work

Short answer: If Mac dictation is not working in Cursor, open System Settings, Privacy and Security, Microphone and make sure Cursor is listed and switched on. Then click into the editor or chat box so it has a text cursor, and check that Cursor has not bound your dictation shortcut key to an editor command.

Cursor is the app where people most want dictation to work and where it most often does not. That is not a coincidence. The whole appeal of an AI-assisted editor is that you describe what you want in plain English and the editor writes the code. Describing things in plain English is exactly what voice is good at, and typing a three-paragraph prompt by hand is exactly what voice is supposed to save you from. So you press your dictation key over the chat panel, nothing appears, and the value proposition quietly collapses.

The good news is that dictation failures in Cursor come from a short, knowable list. Cursor is a fork of VS Code, which means it inherits both VS Code's keybinding system and its identity as an Electron app on macOS. Almost every dictation problem traces back to one of those two facts. Work through the checks below in order and stop when text starts landing.

First, work out which layer is failing

Before you change any settings, spend ten seconds identifying where the failure happens. There are three distinct layers, and they break for unrelated reasons.

• macOS dictation is the system feature you trigger with a keyboard shortcut. It is supposed to work in any text field in any app. When it fails in Cursor but works in Notes, the problem is Cursor-specific.
• Cursor's own voice features. Some builds of Cursor expose a microphone button inside the chat or composer panel. That button asks for microphone access as the Cursor application, and it fails when that permission is missing or when no input device is selected.
• A third-party dictation app such as Voice Keyboard Pro, which sits above both and types into whatever field has focus. This layer fails for permission reasons of its own, usually Accessibility rather than Microphone.

A quick triage test: open TextEdit, press your dictation shortcut, and say a sentence. If words appear in TextEdit but not in Cursor, skip to the focus and keybinding sections. If words appear nowhere, the problem is system-wide and the permission checks below still apply, just not only to Cursor.

1. Give Cursor microphone permission explicitly

This is the single most common cause, and it has a wrinkle that catches people out. macOS grants microphone access per application. Cursor is its own application bundle, completely separate from VS Code, so any permission you granted VS Code months ago does not carry over. If you migrated to Cursor from VS Code and assumed your setup came with you, this is almost certainly your problem.

Open System Settings, go to Privacy and Security, then Microphone. Look for Cursor in the list. Three things can be wrong:

• Cursor is present but the toggle is off. Turn it on.
• Cursor is present and on, but the toggle was flipped after the last launch. Quit Cursor completely with Command Q and reopen it. Permission changes are read when an app starts.
• Cursor is not in the list at all. That means it has never asked. Trigger something that needs the microphone, such as Cursor's own voice input button, and accept the prompt when it appears.

If Cursor is missing from the list and no prompt ever appears, the request is being swallowed somewhere. Toggling the app off and on in Privacy and Security, quitting, and relaunching usually resets the state.

2. Make sure a text field actually has focus

Dictation types into whatever has the blinking cursor. Cursor's interface has an unusual number of things that can quietly take focus away from a text field: the file tree, the command palette, an inline diff, the terminal panel, a collapsed chat thread, the search box, and any of the AI panels that open and close on their own as you work.

The failure looks like dictation is broken, because the microphone indicator appears, you speak, and nothing arrives. In fact dictation is working perfectly and delivering text to a surface that discards it.

Fix it the blunt way. Click directly inside the editor pane, or directly inside the chat input box, and confirm you can see a text caret blinking. Then press your dictation shortcut. If you are using the AI chat panel, click into the prompt box rather than anywhere else in the panel. This one habit resolves a surprising share of reports.

3. Check whether Cursor has captured your shortcut key

Here is the Cursor-specific trap. Cursor inherits VS Code's keybinding system, and that system is aggressive. It can bind almost any key combination to an editor command, and when it does, the key never reaches macOS. Your dictation shortcut stops working in Cursor and only in Cursor.

The usual suspects are the Fn key and Control pressed twice, because those are the common defaults for macOS dictation. Extensions carried over from a VS Code profile are a frequent source of surprise bindings, since many of them register shortcuts without announcing it.

To check, open the keyboard shortcuts editor in Cursor with Command K then Command S, and search for the key you use to start dictation. If anything is bound to it, either remove the binding or change it. If you would rather not lose the editor command, the cleaner move is to change the dictation shortcut instead: open System Settings, Keyboard, Dictation, and pick a different trigger that Cursor does not use.

This same collision pattern shows up across every editor in this family, which is why we wrote a separate walkthrough for dictation not working in VS Code. The fix is identical because the keybinding engine is the same.

4. Rule out Secure Input

macOS has a mode called Secure Input that apps enable when they show a password field. While it is active, the system blocks other processes from observing keystrokes. That protects your password, and it also disables dictation and most text-expansion and hotkey tools, system-wide.

The problem is that apps sometimes enable Secure Input and forget to turn it off. A terminal session waiting on a sudo password, a password manager, a browser sign-in tab left open, or a crashed dialog can all leave the lock stuck on. Since Cursor has a built-in terminal, developers hit this more often than most people.

Symptoms are distinctive: dictation stops working everywhere at once, not just in Cursor, and Caps Lock may behave oddly. To clear it, close any terminal that is waiting on a password prompt, quit your password manager, close browser tabs sitting on a sign-in form, and lock and unlock your screen. If it persists, log out and back in. A restart always clears it.

5. Confirm the right microphone is selected

Dictation uses whatever input device macOS considers current. If that device is not the one you are speaking into, the system hears silence and gives up after a few seconds, which reads as a failure.

Open System Settings, Sound, then the Input tab. Speak normally and watch the level meter. If the bars do not move, the selected device is wrong or muted. Pick the correct one and watch the meter again.

Developers get bitten by this more than most because of hardware churn: an external display with a built-in microphone, a docking station, a webcam, an audio interface, and a headset can all register as input devices, and macOS may switch to whichever appeared most recently. Plugging in a monitor can silently hand your microphone input to a panel on the far side of the desk.

Bluetooth headsets deserve their own warning. When a headset switches into its call profile, the microphone becomes available but audio quality drops hard, and some headsets take a second or two to complete the switch. Words spoken during that window are simply lost. If your first two or three words disappear every time, this is usually why.

6. Wait out the language download

The first time you enable dictation for a language, macOS downloads support files in the background. Until that finishes, the shortcut appears to do nothing. There is no obvious progress indicator, so it feels broken rather than pending.

Go to System Settings, Keyboard, Dictation and look at the language list. If a download is in progress, give it time on a solid network connection and try again. This also explains the confusing case where dictation works in one language and not another on the same Mac.

7. Restart Cursor, then restart the Mac

This is not filler advice. Electron applications hold on to system resources in ways that go stale, and Cursor is a large one that many people leave running for days across sleep cycles. Audio input in particular tends to break after the machine wakes, because the app is still holding a reference to a device that no longer exists in the same form.

Quit Cursor fully with Command Q rather than closing the window, then reopen it. If that does not do it, restart the Mac. A restart also clears a stuck Secure Input lock and resets any audio device confusion, so it covers several causes at once.

If dictation reliably breaks after your Mac wakes from sleep and comes back after a restart, that is a known pattern worth reading about separately in our guide to dictation not working after sleep.

8. Check for an extension intercepting input

Cursor runs VS Code extensions, and extensions can register global keybindings, install input handlers, and change how text is inserted into the editor buffer. Vim emulation is the classic example: in normal mode, the editor is not a text field at all, it is a command surface, so dictated characters get interpreted as movement and edit commands instead of being typed.

If you use a modal editing extension, make sure you are in insert mode before you start dictating. If you are not sure whether an extension is the culprit, start Cursor with extensions disabled from the command palette and test dictation again. If it works, re-enable extensions a few at a time until the problem returns.

9. Look at where the text is actually landing

Occasionally dictation works, the text arrives, and it goes somewhere you did not expect. In an editor with multiple cursors, a split pane, and an AI panel that steals and returns focus, "the text vanished" and "the text went into the other pane" look identical at a glance.

Undo with Command Z a few times and watch what disappears. If your dictated sentence shows up mid-file in a source file you were not looking at, the problem was never dictation. It was focus, and the fix is step 2.

This is also worth checking when an AI response streams in while you are speaking. Panels that resize or scroll during generation can move focus, and the tail end of a dictated sentence ends up in a different box from the beginning.

10. Use a dictation layer that does not depend on the app

If you have worked through everything above and dictation in Cursor is still unreliable, it is worth naming the structural problem rather than fighting it one setting at a time. macOS dictation is deeply entangled with whichever app has focus. Every app gets its own permission entry, its own keybinding table, and its own opinions about what a text field is. An editor as extensible as Cursor has more of those opinions than most.

The alternative is to stop routing voice through the app's own machinery. Voice Keyboard Pro runs in the Mac menu bar rather than inside any single application. You hold a hotkey, speak, and release, and the finished text is typed at your cursor in whatever app is in front of you. Because it inserts text the same way regardless of the app, an editor cannot break it with a keybinding or a custom input handler.

Practically, that means one microphone permission and one Accessibility permission, granted once, instead of a per-app permission audit. It also means the same gesture works in Cursor, in the terminal, in your browser, and in Slack, which matters more than it sounds like it should. Most of the friction in dictation is not accuracy, it is remembering which apps it works in.

Two features tend to matter specifically for writing prompts. Smart Vocabulary is a personal dictionary with replacement rules, so the names of your repositories, frameworks, internal services and variables come out spelled correctly instead of phonetically approximated. And because the transcription engine handles natural speech rather than command-and-control phrasing, you can describe a refactor the way you would describe it to a colleague, at speaking pace.

That pace difference is the real argument. Most adults type around 40 words per minute, and even strong typists land somewhere around 80 to 100. Conversational speech runs about 130 to 150 words per minute. For code, the keyboard still wins, because code is dense with symbols and precise structure. For prompts, commit messages, pull request descriptions, code review comments and design notes, the gap is enormous and it is all in favor of speaking.

Cursor made prompting the primary interface to your codebase. Typing those prompts by hand gives back most of the speed the tool was supposed to buy you.

A quick checklist

If you want to run through this fast, here is the order that resolves the most cases with the least effort:

1. Test dictation in TextEdit to see whether the problem is Cursor-specific.
2. Check Privacy and Security, Microphone for a Cursor entry, then quit and relaunch.
3. Click directly into the editor or chat box and confirm a blinking caret.
4. Search Cursor's keyboard shortcuts for your dictation trigger key.
5. Clear Secure Input: close password prompts, quit your password manager, lock and unlock.
6. Verify the input device in Sound settings by watching the level meter.
7. Give a first-time language download time to finish.
8. Quit Cursor with Command Q, then restart the Mac.
9. Disable extensions, especially modal editing ones, and retest.
10. Press Command Z to find out whether the text went somewhere unexpected.

Nine times out of ten the answer is one of the first four. The microphone permission gap after migrating from VS Code and the keybinding collision are the two that are genuinely specific to Cursor, and they are the two most people never think to check.

If you want voice to be a habit, not a fix

There is a difference between getting dictation working once and having it be something you reach for without thinking. The checks on this page get you the first. The second needs voice input that behaves the same everywhere, so you never have to remember whether this particular app is one of the ones where it works.

That is the case for moving dictation below the app layer. Voice Keyboard Pro has a free tier on Mac and iPhone, so you can test the difference on your own prompts before deciding anything. Pro is $4.99 a month or $34.99 a year if you end up using it daily. Nothing you dictate is stored on our servers: the service keeps operational pings only, no audio and no transcript content.

If your work spans more than the editor, our guide to voice typing in the terminal covers the other half of a developer's day, where the same focus and Secure Input issues show up in a different costume.