Mac Voice Dictation in VS Code and Terminal: What Works
Use Mac voice dictation in VS Code and terminals for prompts, docs, and commit text. Test app boundaries, shortcuts, permissions, and safe limits.
Voice dictation fits developer work when the input is prose: an agent prompt, a code comment, a commit message, or a pull request description. It fits less well when every character must be exact.
The main question is not whether your microphone works. It is whether the focused input accepts the kind of text that your dictation tool inserts.
Use this rule:
- Dictate intent, context, explanations, and review notes.
- Type commands, flags, paths, symbols, code, credentials, and destructive actions.
- Test the exact app and field before changing your Mac settings.
What changed in VS Code
VS Code now documents built-in dictation for chat, the Agents window, editors, and terminals. The feature is experimental. On macOS, its on-device speech model is available on Apple silicon after the model download completes. VS Code also documents separate commands for editor and terminal dictation, plus a cleanup setting for punctuation, paragraphs, lists, and number formatting. Read the current VS Code voice support documentation before relying on a setting name.
This is different from macOS Dictation. macOS Dictation is a system feature for text fields. VS Code dictation is an editor feature with its own microphone controls, commands, model, and permissions.
Run this ten-minute app-boundary test
Use one short, non-sensitive sentence in each target. Do not use a password, private customer detail, API key, or command that can change data.
- Write this sentence somewhere safe:
Draft a short explanation of the cache invalidation bug and list two tests. - Dictate it into Notes or TextEdit with macOS Dictation.
- Dictate it into a VS Code editor file or Markdown document.
- Dictate it into a VS Code chat or Agents input.
- Dictate it into a VS Code integrated terminal prompt.
- Test the same sentence in Terminal or iTerm2.
- Record whether text appears, whether it appears only after stopping, and whether punctuation changes.
Do not change the microphone, shortcut, language, and app permissions together. One controlled test tells you which boundary failed.
Read the result
| Result | Likely boundary | Next check |
|---|---|---|
| Text works in Notes and VS Code editor | Basic microphone and Dictation path works | Check the target input or its mode. |
| VS Code chat works, but the editor does not | Editor command, focus, or permission issue | Run Voice: Start Dictation in Editor and click inside a writable file. |
| VS Code editor works, but the terminal does not | Terminal mode or terminal input behavior | Run Voice: Start Dictation in Terminal from the Command Palette. |
| Terminal input works, but an agent prompt does not | Custom terminal UI may not expose a standard text input | Test the agent in a normal editor or browser field. |
| Text appears only after stopping | Finalization or cleanup behavior | Stop the session before judging the final punctuation. |
| No text appears anywhere | System setup problem | Check Dictation, shortcut, microphone input, and permissions. |
This table separates a product or app boundary from a broken microphone. It is a diagnostic plan, not a claim that every Mac or editor behaves the same way.
Use VS Code's built-in dictation when the field supports it
VS Code documents these paths:
- Chat and Agents: use the microphone control or the documented shortcut. Stop dictation before you submit the prompt.
- Editor: run Voice: Start Dictation in Editor, then stop it from the microphone control or Command Palette.
- Terminal: run Voice: Start Dictation in Terminal. VS Code adapts the result for command-line input.
VS Code's terminal mode is useful for natural-language prompts and explanations. It is not a reason to dictate shell syntax. A speech recognizer can turn dash dash force into something that looks plausible but does not mean what you intended.
Use macOS Dictation as the control test
Apple documents Dictation in places where you can type. It also documents spoken punctuation, “new line,” and “new paragraph” commands. Those breaks can appear when dictation ends. Apple's Dictation guide and command reference show the current behavior.
Use Notes or TextEdit as the control app. If text works there, do not start by reinstalling macOS. Check the target field, the active dictation mode, and the app's permissions first. If the system feature itself fails, use the Mac Dictation troubleshooting checklist.
Check terminal security settings
Secure Keyboard Entry can block other programs from seeing what you type. Apple documents this setting for Terminal, and iTerm2 documents the same behavior for its own Secure Keyboard Entry menu item:
- Stop dictation.
- Turn Secure Keyboard Entry on when you type passwords or other secrets.
- Turn it off for a controlled dictation test in a normal, non-sensitive prompt.
- Turn it back on before entering sensitive data.
Read Apple's Secure Keyboard Entry guide and iTerm2's menu documentation. Do not weaken a security setting while entering credentials.
Dictate prose. Type syntax.
Voice saves time when you have to explain a change. It can cost time when you need exact symbols.
| Good voice input | Keep on the keyboard |
|---|---|
| “The login form accepts the request before the session is stored.” | sessionStorage, URLs, file paths, and identifiers |
| “Add a regression test for the rejected purchase case.” | Test commands, flags, and package names |
| “Keep this change inside the access-bind route.” | Shell pipelines and destructive commands |
| “Write a short PR summary with risk and verification.” | JSON, regular expressions, code, and secrets |
Use a scratchpad when you need to think aloud. Paste exact syntax after you decide what the code or command must say. Read the final prompt before sending it to an agent.
Use Heynds across the writing layer
VS Code dictation helps when you stay inside VS Code. macOS Dictation helps with direct text entry. Heynds fits the step after capture when a rough explanation needs structure, rewriting, refactoring, translation, or a repeatable custom command.
For example:
- Dictate the issue context into the current text field.
- Select the draft.
- Apply one custom command for Context, Expected, Observed, Scope, and Verification.
- Add paths, commands, and quoted errors by keyboard.
- Check every technical detail before sharing.
Test that workflow with the Heynds browser demo. Heynds describes its product as a macOS writing and voice-to-text workflow that supports rewriting, refactoring, translation, and custom commands. It does not remove the need to check exact developer input.
Keep the data path visible
VS Code documents its built-in speech model as on-device after the model download on supported Apple silicon Macs. That claim applies to the VS Code feature described above.
Heynds AI features follow a different path. The Heynds privacy policy says that submitted AI content is routed through OpenRouter to endpoints marked Zero Data Retention. OpenRouter's ZDR documentation limits that control to inference-provider routing. It does not automatically cover optional tools or plugins, and it does not make every Heynds workflow offline.
Remove sensitive details before using any cloud-backed writing feature. Keep credentials out of dictation and custom commands.
Choose the smallest tool that solves the problem
| Need | Start with |
|---|---|
| Short text in a normal Mac field | macOS Dictation |
| Voice inside VS Code chat, editor, or terminal | VS Code built-in dictation |
| Prompts, comments, or PR text across Mac apps | A system-wide voice-to-text workflow |
| Rough speech that needs structure or rewriting | Heynds or another writing layer |
| Exact shell syntax or code | Keyboard, with voice for the explanation |
| Dictation fails in one app only | App-boundary test before system resets |
Voice dictation works best when you treat it as an input choice, not as a promise to replace the keyboard. Find the failing boundary, speak the prose, type the exact parts, and review the result before you run or share it.