Mac Dictation Not Working in VS Code? 9 Fixes That Actually Work (2026)

Short answer: Mac dictation usually fails in VS Code for one of two reasons: the keystroke that starts dictation never reaches macOS because VS Code claimed it first, or dictation starts fine but the words land in a pane that is not the editor. Confirm dictation works in TextEdit, then check the shortcut, permissions, and focus.

VS Code is an unusual place to dictate, and that is why it breaks in ways Mail and Notes never do. It is not a native macOS text app. It is a browser engine wearing an editor costume, and it is aggressive about keyboard input: nearly every key on your keyboard is either a command, part of a chord, or a candidate for one. When you add a system service that also wants a key of its own, the two fight, and the loser is usually you standing there talking to a cursor that is not moving.

The good news is that the failure modes are small in number and easy to tell apart. Almost every report falls into one of three buckets. Dictation never starts. Dictation starts but nothing is inserted. Or dictation inserts text and something else immediately mangles it. Each bucket has a different fix, and diagnosing which one you are in takes about thirty seconds.

This guide works through them in order, starting with the test that saves you from changing settings you did not need to touch.

Start here: the TextEdit split test

Before touching a single preference, open TextEdit and create a blank document. Press whatever shortcut you use to start dictation. Say a short sentence.

• Nothing happens in TextEdit either. The problem is not VS Code. It is dictation itself, or the shortcut, or microphone access at the system level. Fixes 1, 3, and 8 below apply, and our full Mac dictation fix list covers the rest.
• It works in TextEdit but not VS Code. Now you have a genuine VS Code problem. Skip to fix 2 and work down.
• It works in TextEdit and in VS Code's search box, but not in the editor pane. That is a focus or text-insertion problem specifically inside the code surface. Fixes 4, 5, and 6 are yours.

This one test splits the entire problem space in half, and people skip it constantly. It is worth the thirty seconds.

Fix 1: The shortcut never reaches macOS

macOS dictation is triggered by a shortcut you choose in System Settings, and the default is a double press of a modifier key. Open System Settings, go to Keyboard, then Dictation, and confirm three things at once:

• Dictation is actually switched on. The toggle turns itself off after some system updates and after certain migration paths from another Mac.
• A language is selected, and it is the language you are speaking.
• The shortcut is set to something you know. Double press of Control is the safest default because nothing in VS Code uses a bare double tap of Control.

Then check the separate setting that trips up more people than any other on modern MacBooks. In System Settings, under Keyboard, there is an option for what the Globe key does when pressed. If that is set to change input source or show the emoji picker, and your dictation shortcut is the Globe key, the two are in direct conflict and the input source switch wins. Set the Globe key behavior to start dictation, or move dictation onto the double press of Control and leave the Globe key alone.

If your dictation shortcut is a function key you assigned yourself, be aware that the top row on a Mac keyboard sends media keys by default. F4 may be doing Spotlight duty, F5 is a debug command inside VS Code, and the row behaves differently depending on whether the setting for using function keys as standard function keys is enabled. This is also the root cause behind most cases where the Mac dictation shortcut stops working in one app but not another.

Fix 2: VS Code is eating the key before macOS sees it

This is the single most VS Code specific cause on the list, and it is why the app feels uniquely cursed.

System level shortcuts normally take priority over application shortcuts, which is why a double press of Control still triggers dictation even when an app has a Control binding. But a single key, or a key with modifiers that VS Code has claimed, behaves differently. If you remapped dictation to something like F13, F5, or a Command combination, VS Code may have a command bound to the exact same keystroke, and inside the editor window VS Code's binding is what you get.

Open the keyboard shortcuts editor with Command K followed by Command S. Click the record keys button at the top, then press your dictation shortcut. VS Code will show you every command bound to that keystroke. If the list is not empty, you have found your conflict.

You have two ways out. Remove or rebind the VS Code command, which is fine if it is something you never use. Or move dictation to a keystroke VS Code will never want. In practice, the second option is more durable, because extensions add new bindings over time and you will not remember this conversation in three months when a new extension quietly claims F13.

Function keys F13 through F19 are the traditional safe harbor here. They exist in the macOS keyboard map, most external keyboards can send them, and almost nothing binds them by default. If you use an external keyboard with programmable keys, mapping one physical key to F13 and pointing dictation at it removes this entire class of problem permanently.

Fix 3: Microphone permission, in two separate places

There are two permission layers, and people usually check only one.

The first is system dictation itself, which is a macOS service. When it is enabled, macOS handles microphone access for it, so there is no separate entry to approve. If dictation works in TextEdit, this layer is fine.

The second layer matters when the microphone is being used by an app rather than by the system service. Any tool that records audio inside VS Code, including extensions and any voice assistant panel, is asking VS Code itself for the microphone. Open System Settings, go to Privacy and Security, then Microphone, and confirm that Visual Studio Code appears and is enabled. If it is listed and switched on but still fails, switch it off, quit VS Code completely with Command Q, switch it back on, and reopen. Permission state for Electron apps is sticky, and a full quit is what forces it to be re-read. Closing the window is not the same as quitting.

One more wrinkle: if you run VS Code Insiders, or a fork such as Cursor or a Codium build, each one is a separate application identity with its own permission entry. Granting the microphone to one grants nothing to the others. Check that the entry you approved matches the icon in your Dock.

Fix 4: The text is going somewhere that is not the editor

VS Code is a mosaic of input surfaces that all look similar. The editor pane, the integrated terminal, the search field, the command palette, the settings UI, the source control commit box, notebook cells, Markdown preview, and any extension panel are all distinct targets. Dictation inserts into whatever has keyboard focus at that moment, and clicking a pane is not always the same as focusing its text field.

Two habits fix nearly all of it:

• Click directly into the text and watch for a blinking caret before you start dictation. A visible caret is the only reliable evidence that a text target has focus. A highlighted pane border is not.
• Never start dictation while the command palette is open. The palette grabs focus aggressively and dismisses on certain events, which can leave your words landing in a field that is disappearing as you speak.

The commit message box in the source control view deserves its own warning. It is a small editor, and in some configurations pressing Return in it commits rather than adding a line. If you dictate a multi-line commit message with a spoken new paragraph in the middle, you can end up committing half of it. Dictate the message somewhere neutral first, or turn off the setting that makes Return commit.

Fix 5: IntelliSense is swallowing your dictated words

This one produces the strangest symptom: you speak a sentence, and what appears is a partly correct sentence with a variable name jammed into the middle of it.

The suggestion widget in VS Code accepts a suggestion on certain commit characters, and one of them can be a space. Dictated text arrives as a stream of characters with spaces, so the editor treats the space after each dictated word as a signal to accept whatever suggestion is currently highlighted. You said "return the user record" and got back "returnTypeAnnotation the userRecord".

If you dictate prose inside code files often, such as comments, docstrings, and commit messages, adjust two settings in your user settings JSON:

• "editor.acceptSuggestionOnCommitCharacter": false stops suggestions from being accepted by a space or punctuation, so you only ever accept one on purpose with Tab or Return.
• "editor.quickSuggestions" can be set so suggestions do not fire inside comments and strings, which is exactly where dictated prose lives.

Auto closing brackets and auto indent cause a milder version of the same problem. When you dictate a spoken open parenthesis, the editor inserts the closing one for you, and then your spoken closing parenthesis produces a second one. It is not a dictation bug, but it looks like one, and it is a good reason to keep punctuation heavy work on the keyboard. Our guide to voice to text in VS Code goes further into which parts of the coding day are actually worth dictating.

Fix 6: Vim mode, and other modal extensions

If you use a Vim, Neovim, or Emacs keybinding extension and dictation appears to do random destructive things, you are almost certainly in normal mode.

Dictated text arrives as keystrokes. In normal mode, those keystrokes are commands. A dictated sentence beginning with the letter d will start a delete operation, a spoken word containing u will undo, and the result looks like your editor is possessed. Nothing is broken. The editor is doing exactly what those keys mean.

The fix is procedural, not technical. Enter insert mode first, confirm the mode indicator in the status bar, then start dictation. If that feels fragile, bind your dictation trigger to a macro that enters insert mode before it fires.

Fix 7: Remote SSH, dev containers, and Codespaces

When your workspace is remote, the editor UI still runs locally, so dictation still inserts locally and then the characters are sent onward. That normally works. What changes is latency and the failure mode when the connection stutters.

On a slow link, dictated text can arrive faster than the editor can echo it, and you see characters appear out of order or in a burst several seconds later. That is a rendering and round trip issue, not a transcription one. Dictate into a local scratch file and paste across when the connection is poor.

Codespaces in a browser is a different animal. There you are dictating into a web page, so the browser needs microphone permission, the tab needs to be the active tab, and the same suggestion widget behavior applies. If it fails only in the browser version, test the same dictation in a plain text field on any web page to isolate whether it is the browser or the workspace. The same reasoning applies to any editor running in Chrome, which we cover in Mac dictation not working in Chrome.

Fix 8: Managed Macs and configuration profiles

On a work laptop, dictation can be switched off by policy. The symptom is distinctive: the dictation toggle in System Settings is either greyed out, missing, or turns itself back off within seconds of being enabled, and it fails everywhere rather than only in VS Code.

Look in System Settings under General, then Device Management, to see whether a profile is installed. If dictation is restricted by policy, no amount of local troubleshooting will change it, and the fix is a conversation with whoever administers the fleet. It is worth asking rather than assuming, because the restriction is frequently a default in a security baseline rather than a considered decision about dictation.

Fix 9: The session keeps cutting out mid sentence

If dictation works but stops after a short burst, you are hitting a session limit rather than a VS Code fault. Keyboard dictation on a Mac has historically stopped listening after a period of continuous speech or after a pause, and the exact behavior depends on the macOS version and whether your language is available for on device processing.

Two things help. First, in System Settings, under Keyboard and then Dictation, download the language for on device use if the option is offered, which generally lifts the tight session limits. Second, change how you speak to it: dictate in complete sentences with brief, deliberate pauses rather than long unbroken paragraphs, and restart the session between blocks. If the cut offs persist, the pattern is documented in more detail in our post on the Mac dictation 30 second limit.

Four behaviors that look like bugs and are not

Before you spend another hour on settings, rule these out.

Spoken punctuation appearing as words. If you say "period" and the word period appears, dictation is running but in a mode or language where automatic punctuation is handling things differently. Check the dictation language and try the explicit punctuation commands rather than trailing off and expecting a full stop.

The first word missing. Dictation needs a moment to open the audio input. Speaking the instant you press the shortcut clips the beginning. Wait for the indicator, then talk. This is the same root cause as Mac dictation cutting off the first word anywhere else on the system.

Everything arriving in lowercase, or with odd capitalization. That is the transcription making a reasonable guess about prose, then meeting a file full of identifiers where the convention is different. It is not a fault, and no permission change will alter it.

Formatting rearranging itself after you finish. Format on save and a linter with fix on save will both reshape what you dictated the moment the file is written. Check whether the text was correct before the save, not after.

The deeper mismatch: system dictation is built for prose

Work through the fixes above and you can get macOS dictation running inside VS Code. Whether you should is a separate question.

System dictation is designed around continuous speech in a document. A code editor is the opposite environment. The text is half prose and half identifiers, the punctuation density is enormous, the surfaces you type into change every few minutes, and a modal extension can turn a stray word into an edit you did not want. Every one of the fixes above is really a workaround for that mismatch.

The parts of a developer's day that genuinely reward dictation are the prose parts, and there are more of them than most people admit: commit messages, pull request descriptions, code review comments, issue write ups, design docs, architecture notes, docstrings, README sections, and the long Slack message explaining why the migration is late. Those are ordinary English, they are tedious to type, and they are where the speed gap shows. Most adults type somewhere around 40 words per minute and speak at 130 to 150.

Voice Keyboard Pro approaches this from a different angle than a system service does. It is a small menu bar app for macOS: you hold a hotkey, speak, and release, and the text appears at your cursor in whatever app is in front of you. That includes the VS Code editor pane, the integrated terminal, the commit box, a browser tab with a pull request open, and the Slack window you switch to next. Because it is hold to talk rather than a session you start and stop, there is no session that can expire mid sentence, and because the trigger is a hotkey you choose, you can park it on a key VS Code will never claim.

Two features matter specifically for this environment. Smart Vocabulary is a personal dictionary with replacement rules, which is how you stop fighting the transcription over your own repository names, internal service names, and library names that no general transcription engine has any reason to know. Add them once and they come out right. Meeting Mode, with speaker detection and AI notes, covers the other half of the engineering day, the calls where the decisions get made and nobody writes them down. There is also an iPhone keyboard with a built in mic button if you capture thoughts away from the desk, and it does two way translation across 24 languages while you dictate, which matters on distributed teams.

Voice Keyboard Pro's transcription engine runs on our servers, and it is worth being precise about what that means. We store operational pings only. No audio and no transcript content is retained on the server, which is the answer to the obvious objection about dictating anything near a private codebase.

The practical division of labour is simple. Type the code. Dictate the English around it. For the terminal specifically, where a dictated command has to come out as a valid command rather than a sentence about one, see voice typing git commits in the terminal.

A five minute checklist

If you want the compressed version, run these in order and stop when it works.

1. Test dictation in TextEdit. If it fails there, the problem is not VS Code.
2. Confirm dictation is enabled in System Settings, with the right language, and a shortcut you recognize.
3. Check what the Globe key is set to do, and make sure it is not fighting your dictation shortcut.
4. Open Command K Command S, record your dictation shortcut, and remove any VS Code binding that claims it.
5. Move dictation to F13 or the double press of Control if the conflict list was not empty.
6. Verify Visual Studio Code in Privacy and Security, then Microphone. Quit fully and reopen after changing it.
7. Click into the editor and confirm a blinking caret before speaking.
8. Turn off accept suggestion on commit character if dictated words are being replaced by identifiers.
9. If you use Vim mode, enter insert mode first.
10. Check Device Management for a profile if the dictation toggle will not stay on.

Nine times out of ten it is the fourth or the seventh item. The fourth is a conflict you cannot see, and the seventh is a habit rather than a setting, which is why both survive so many rounds of troubleshooting.

Frequently asked questions

Why does dictation work in Notes but not VS Code?

Notes is a native macOS app using standard text fields, and VS Code is an Electron app that renders its own editor and claims most of the keyboard. The two most common consequences are a shortcut conflict and text landing in a pane other than the one you meant.

Does VS Code need microphone permission for macOS dictation?

System dictation is handled by macOS, so it does not require a separate microphone grant for VS Code. Any extension or embedded panel that records audio itself does, and that entry appears under Privacy and Security as Visual Studio Code.

Can I dictate into the integrated terminal?

Yes, because dictated text arrives as keystrokes and the terminal accepts keystrokes. The problem is not insertion but content: spoken English becomes a sentence, not a command, and a stray Return runs whatever is on the line. Dictate the command somewhere you can read it back first.

Is there a way to avoid the shortcut conflict permanently?

Put the trigger on a key nothing else wants. F13 through F19 are the usual choice, and a programmable external keyboard can send one from a convenient physical key. A hold to talk hotkey has a further advantage over a toggle: it cannot be left running in the background, so it cannot type into a window you switched to.

Will fixing this make dictation good for writing code?

Realistically, no. Dictation is excellent for the English in and around code and awkward for the syntax itself. The developers who stick with it are the ones who stopped trying to speak semicolons and started dictating the commit messages, the reviews, and the docs.