Dictate commands, scripts, and code into your terminal

The terminal is a text field like any other. Hold your dictation hotkey in Terminal.app, iTerm2, or VS Code's integrated terminal and speak the command you want to run. Your words land in the prompt, ready to execute. This works for simple one-liners, multi-line shell scripts, and debugging commands — anywhere you would normally type in a terminal window.

Before you start: terminal accessibility

Dictation works in macOS terminals through the accessibility API, which most terminal applications support. Some older or heavily customized terminal setups may not. Test with a simple command first: hold your hotkey and speak something like ls minus l to see if the text lands in your prompt.

If dictation does not work in your terminal, or if text lands in the wrong place, the terminal may not support the accessibility API. This is rare in modern terminal applications but can happen with very specialized or embedded terminal environments. For those cases, using the terminal's built-in paste buffer (copying your dictation and pasting it) is a workaround.

Set up your workflow

1. Position your cursor in the command prompt

Before you start dictating, click the terminal window to make sure it has focus. Position your cursor where you want the text to land — usually at the command prompt. This is the same as any other text field: the app inserts text at your cursor position when you release the hotkey. If text lands in the wrong place, the terminal probably did not have focus when you released the key.

2. Use short, clear dictation for commands

Terminal commands are shorter and more structured than prose. Dictate in short bursts: ls minus l rather than one long sentence. This is faster and reduces the chance of a misrecognition mid-command.

3. Speak symbol names instead of trying to pronounce them

The macOS speech recognition engine does not understand "type a forward slash" — it understands the words you speak. Just as you would say the punctuation mark name when dictating prose, you speak the symbol's name in the terminal:

• / → forward slash
• - → dash or minus
• -- → double dash
• && → double ampersand or and and
• | → pipe
• $ → dollar sign
• * → star or asterisk
• ~ → tilde
• ? → question mark

Practice the ones you use most. ls minus l, grep foobar filename, cd forward slash home forward slash myname. The awkwardness passes quickly.

4. Build a dictionary for repeated symbols and commands

Add your most frequent symbols to your dictionary. If you dictate grep and awk often, add entries that ensure they are recognized correctly. If you have a multi-line script you dictate regularly (like a deployment command), you can add the entire thing as a dictionary entry and say it in one burst.

This is especially useful for:

• Language keywords: async, await, lambda, def, return
• Operators: ===, !==, =>, ::
• Paths: /usr/local/bin, /etc/, ~/Library/
• Package managers: npm, pip, brew, cargo

Dictionary entries stay exactly as you type them, so spelling matters. If you misspell an entry, the app will insert the misspelling. Verify each one by dictating it and checking the output.

Working with shell syntax

Multi-line dictation

You can dictate a shell script across multiple lines:

1. Speak the first line of the command.
2. Say enter when you want to move to the next line.
3. Speak the next command.
4. Repeat as needed.

Example: npm install dash save, enter, npm run build, enter, npm start

This dictates three lines of a deployment script. The text lands in your terminal as three separate lines, ready to execute.

Working with configuration files

Many terminal workflows involve editing configuration files. You can dictate into terminal text editors like vim or nano by speaking the content, then using the editor's commands to save and exit. Some editors are easier to dictate into than others:

• nano: Start with nano filename, then dictate. Exit with Control-X, confirm the save.
• vi/vim: More complex; requires learning modal editing commands. Dictating into insert mode is straightforward, but switching modes and issuing commands requires speaking vim syntax.
• echo redirecting: echo configuration content greater than filename sends text to a file without opening an editor.

For frequently-edited configuration files, using dictionary entries for the entire file path or common configuration blocks saves time. If you regularly edit /etc/hosts, add an entry: hosts path → /etc/hosts. For configuration blocks, add the entire block as a dictionary entry and speak it in one burst.

Environment variables and PATH

Shell environments often reference paths and variables. Practice dictating these:

• Environment paths: /usr/local/bin, ~/Library/Preferences
• Variable references: dollar HOME, dollar PATH
• Exports: export MY_VAR equals myvalue

Adding dictionary entries for your most frequently-used paths dramatically speeds up terminal dictation. If you work in a specific directory repeatedly, add it: work → ~/projects/myproject.

Pipes and redirects

Pipes and redirects are where the symbol-name system really helps:

• cat filename pipe grep foobar → cat filename | grep foobar
• ls dash l greater than output dot txt → ls -l > output.txt
• tail dash f logfile pipe grep error → tail -f logfile | grep error

The filters convert the spoken symbol names into the actual characters. This is faster and more reliable than trying to type symbols while dictating.

Control characters and escaping

Some shell syntax is harder to dictate because it conflicts with command parsing. For example, escaping a quote requires a backslash: echo "hello\"world". Speak it as:

echo quote hello backslash quote world quote

The app inserts the backslash and quotes in sequence. If your command fails because of escaped characters, check the history to see what the raw transcript looked like before filtering, then adjust your dictionary.

Improving accuracy in the terminal

Speak more slowly when dictating code

Shell commands are denser than natural language. The same words in a sentence and in a command have different meanings. for is a keyword, not a preposition. Speaking slightly more slowly gives the recognition engine more context. When dictating code comments, the same principle applies: clarity trumps speed.

Use your microphone quality

The terminal is less forgiving of audio errors than prose. A marginal microphone (built-in laptop mic, a cheap headset) will produce more misrecognitions. A quality USB headset or desktop microphone makes a noticeable difference.

Check the history

Every dictation, regardless of where it lands, is stored in your history. Check it to see what the engine heard before the text filters applied. If a command repeatedly gets misrecognized, the pattern in the history will tell you whether to adjust your microphone, your pronunciation, or your dictionary.

Practice the workflow before you need it

If you are dictating into production systems or during debugging, practice first with low-stakes commands. Spend a session dictating ls, pwd, echo commands until you are confident in the flow. The stakes are lower and the commands are simple.

Common patterns for developers and DevOps

Git commands

Git is a good starting point because commands are short and the stakes are clear (you need to see what you typed before committing). Many developers use Git daily, making it an excellent candidate for dictation:

• git add dash A → git add -A
• git commit dash m, quote, my commit message, quote → git commit -m "my commit message"
• git push origin main → git push origin main (no symbols)
• git log dash minus oneline dash five → git log --oneline -5

Once you have a standard workflow, you can add the entire sequence to your dictionary and speak it as one command.

Package manager operations

Package managers are repetitive and familiar, making them good for building your dictation muscle memory:

• npm install express (no symbols)
• npm run build (no symbols)
• pip install pytest (no symbols)
• brew upgrade (no symbols)

System administration

Longer commands with pipes and redirects are where dictation earns its time back:

• tail dash f forward slash var forward slash log forward slash system dot log pipe grep error
• find dot dash name star dot log dash exec rm braces braces semicolon

These are tedious to type, and dictating them is faster even with the symbol names. System administrators who manage multiple machines benefit especially from dictation — deploying a set of commands across servers is faster spoken than typed. The same holds for log file parsing, where you might dictate a awk or sed command to extract a specific field from millions of lines.

Database and query commands

Database administrators and data analysts who work with SQL or similar query languages can dictate:

• select star from users where status equals active semicolon
• grep dash i error forward slash var forward slash log forward slash application dot log pipe head dash twenty

The repetitive keywords (SELECT, FROM, WHERE) are ideal for dictionary entries. Once you add them, you can speak the query faster than you can type it while maintaining accuracy.

Container and orchestration commands

Modern DevOps workflows involve container tools and orchestration platforms. Common patterns include:

• docker run dash minus it docker image bash
• kubectl apply dash f config dot yaml
• docker compose up dash d

These tools have their own vocabulary, and building a dictionary for your workflow (especially for your most frequent deployment commands) significantly speeds up dictation.

When to use dictation and when not to

Dictation is fastest for:

• Short, familiar commands
• Symbols you have added to your dictionary
• When typing is uncomfortable (repetitive strain, accessibility needs)
• When you have the terminal visible and want to dictate and watch

Typing is faster for:

• Editing a previous command (arrow keys and command history are faster)
• Complex paths or filenames you cannot predict
• Commands you have to construct from scattered information
• Passwords or sensitive data (dictating passwords into a terminal is a security risk; paste or type them)

Troubleshooting

Text lands in the wrong window

If your dictation landed in a different app instead of the terminal, the terminal did not have focus when you released the key. Click the terminal window and try again. This is especially common if you are switching between the terminal and another app rapidly.

Symbols do not convert correctly

If you said forward slash but the app typed forward slash as text instead of /, check your dictionary. Make sure you have the symbol entries added. Without them, the recognition engine tries to transcribe the words you spoke, and the text filters do not know to convert them.

Multi-line commands do not parse correctly

Shell interpreters are picky about spacing and line breaks. If your multi-line command fails, check the raw transcript in your history. Look for extra spaces, missing special characters, or syntax errors that might be invisible. Paste the command into a text editor to see it clearly.

Terminal does not respond to dictation at all

Verify that the terminal application has focus and that the accessibility API is enabled for it. In System Preferences > Security & Privacy > Accessibility, make sure Terminal.app, iTerm2, or whichever app you use is listed. Some very new or sandboxed terminals may not support the accessibility API at all.

Building your command vocabulary

Over a week of using dictation in the terminal, you will develop a mental dictionary of how to speak each symbol and command. Some people find it helpful to keep a cheat sheet of their most frequent patterns:

my common git workflow:
git checkout dash b newfeaturename
git add dash A
git commit dash m quote my feature dot quote
git push origin newfeaturename

Dictate this workflow once or twice until you have the pacing and rhythm down, then add the entire sequence as a dictionary entry. When you teach your app your jargon, each entry becomes a command you can reuse. Next time you need to do it, you can dictate the whole thing in one burst.

Over time, dictation in the terminal becomes as natural as typing — you speak the command, listen to the prompt to confirm, and execute. The initial learning curve is steep (especially with symbol names), but it flattens quickly. Having a long document of commands you dictate often lets you reference and practice them.

Terminal-specific tips and tricks

Repeat last command: The Unix convention !! reruns the previous command. You can dictate this or add a dictionary entry: again → !!

Conditional execution: The && operator runs the next command only if the first succeeds. Speak it as double ampersand or add and then → && to your dictionary. Similarly, || (or operator) can be double pipe or or else → ||.

Variable assignment: Environment variables are common in shell scripts. You dictate them the same way: export DEBUG equals true or MY_VAR equals myvalue

File descriptors and redirection: Advanced shell users work with file descriptor redirection like 2>&1 (redirect stderr to stdout). These are complex to dictate; adding a dictionary entry for common patterns is worth the setup: redirect stderr → 2>&1

History and search: The shell history buffer lets you search previous commands with ctrl R. This is a keyboard shortcut you would need to execute manually; dictation plays well with shell history when you want to recall and re-execute a previous command.

Protect your security while dictating

Never dictate passwords, API keys, or tokens into a terminal. Even though your audio is not uploaded, saying a password aloud introduces a second person (your assistant, your coworker, anyone in the room) into the authentication process. Paste these from a password manager instead.

For the same reason, avoid dictating during sensitive debugging sessions where system information or user data might be visible on your screen. Your words are not uploaded, but the people around you are still present.

Improving speed and reducing mistakes

As you build muscle memory with terminal dictation, your speed will increase. The biggest improvements come from:

1. Building a comprehensive dictionary: Each entry you add saves you from speaking symbol names. The more entries you have for your workflow, the faster you go.

2. Speaking in natural pauses: Dictate commands in logical chunks, not word by word. git commit dash m quote my message quote is one burst, not four separate ones.

3. Checking frequently: Use the history feature to see what the engine heard. If misrecognitions are happening, adjust your dictionary or your microphone position, and move on.

4. Focusing on the most frequent commands: Do not build a dictionary entry for every command. Focus on the ones you use daily. Start with Git, npm, and your most common tools, then expand from there.

Dictating into a terminal is a skill that improves with practice. Start with simple commands, build your symbol vocabulary, and gradually add more complex workflows. The payoff is a terminal experience that works for your hands and your voice. Within weeks, you will find yourself reaching for the microphone instead of the keyboard for command-line work.