To dictate a GitHub issue, pull request description or review comment on a Mac, click into the Markdown text box on github.com, start Apple's built-in Dictation with the Microphone key or your Dictation shortcut, and speak. Press Command-Return to submit when you have read it. GitHub's docs do not describe voice input for the comment boxes on github.com. GitHub does document voice input for prompts in two Copilot tools, Copilot CLI and the GitHub Copilot app, which are a different job from writing an issue.
Publisher note: SuprFlow publishes this guide and is one of the products discussed. Competitor details come from each company's own pages, checked on 3 October 2026. Prices and features change; confirm before you buy.
Does GitHub have built-in voice to text?
Not for issues, pull requests or comments on github.com. GitHub's help pages do not describe a dictation feature for those text boxes as of 3 October 2026; see GitHub Docs.
GitHub does document voice input for Copilot prompts:
- Copilot CLI. Use voice input with Copilot CLI says to "Hold down the space bar" to record a short prompt, or press Control-X then V for a longer one. GitHub says "Transcription runs entirely on your local machine. Your audio is not sent over the network." It lists macOS on Apple Silicon as supported, not Intel Macs.
- GitHub Copilot app. Working with agent sessions says you can "use voice dictation to speak prompts in a session." You set it up in the app's settings: choose a shortcut, allow microphone access, and "Download a local transcription model."
If your goal is to speak a prompt to Copilot in those tools, use their voice input. For writing on github.com, use one of the routes below.
How do you dictate an issue with Apple Dictation?
Apple's Dictation guide for macOS 27 says "you can speak to enter text anywhere you can type it."
- Turn on Dictation once in System Settings → Keyboard → Dictation. On older macOS versions the wording may differ.
- Open the repository's issues list and press C to create an issue, or open the pull request you are describing (Keyboard shortcuts).
- Type the title. Short titles with file names and versions are faster to type.
- Click in the description box.
- Press the Microphone key or your Dictation shortcut. Speak in sections: what happened, what you expected, steps to reproduce. Say "new paragraph" between them.
- Stop with the same key. Paste logs, commands and code by hand inside code fences.
- Press Command-Shift-P to toggle the Preview tab, read it, then press Command-Return to submit.
Setup is in How to use voice to text on a Mac. See the Mac dictation shortcut guide, Mac dictation commands and Mac Dictation not working.
When is a push-to-talk dictation app worth it?
Code review produces a lot of prose: pull request summaries, review comments, replies, release notes. If you write that all day, and also dictate in your editor, terminal and chat, one hold-to-talk key across all of them is the reason to look at a dedicated app. A personal dictionary helps with service names, library names and acronyms that general speech recognition misses.
SuprFlow is one example. It is a menu-bar app for Apple Silicon Macs on macOS 14 or later. Hold the Fn key, speak, release, and it pastes the text into whichever text field has focus. Speech recognition runs on the Mac with an on-device model; optional cloud formatting sends transcript text, not audio, to the provider you pick. Default formatting is local cleanup of punctuation, capitalization and numbers. It costs $125 for lifetime access on up to 5 Macs you own, with no subscription and a 7-day refund on a first purchase (as of 3 October 2026).
Because it pastes at the cursor, it should work in an ordinary text field; test it in a draft comment on a test repository with a harmless sentence. We have not run a controlled benchmark against Apple Dictation. If you write a couple of issues a week, Apple's free Dictation is enough.
Which route should you use?
| GitHub's own voice input | Apple Dictation | System-wide app (SuprFlow as the example) | |
|---|---|---|---|
| Issues, pull requests, comments on github.com | Not documented | Yes | Should work; test first |
| Copilot CLI and Copilot app prompts | Yes, transcribed locally | Yes, if the field accepts it | Should work; test first |
| Cost | Part of your Copilot access | Free with macOS | $125 once |
| Start | Hold Space in Copilot CLI; your chosen shortcut in the app | Microphone key or shortcut | Hold Fn, release to insert |
| Best for | Prompting Copilot | Occasional issues and comments | Many reviews and comments a day |
What goes wrong when dictating into GitHub?
- Single-key shortcuts. GitHub uses keys such as C outside text boxes. Click into the box first. GitHub says you can turn off character key shortcuts in your accessibility settings.
- Return does not submit, Command-Return does. In issues and pull requests, GitHub "will render a line break automatically", so Apple's "new line" (which Apple calls "equivalent to pressing the Return key once") just adds a line. Command-Return submits the comment, so keep your hands off it until you have read the text.
- Markdown characters. Dictated punctuation can start formatting: a line starting with a number and period becomes a list, and "#" followed by a number links an issue. Check the Preview tab.
- Mentions. GitHub says @ plus a username "will trigger a notification." Type mentions by hand so you do not notify the wrong person, or miss the right one.
- Code, paths and versions. Function names, file paths, branch names, commit hashes and stack traces should be pasted, not spoken.
- Silence. Apple says Dictation stops after 30 seconds without speech.
What should you check before you submit?
- The repository, and whether it is public.
- Steps to reproduce, in order, with versions and operating system.
- Every "not", "never" and "only".
- Issue and pull request numbers that link where you meant.
- Mentions and code blocks in the Preview tab.
- No secrets, tokens, customer names or internal URLs.
On privacy: GitHub says "Anyone with read access to a repository can view a comment's edit history." Fixing a dictation slip after posting leaves the earlier text in that history unless an author or someone with write access deletes the revision. See where dictated text goes after insertion.
Questions people ask
Can I use voice to text for a pull request description?
Yes. Click into the description box and use Apple Dictation or another dictation app. GitHub does not document its own dictation for that box.
Does GitHub Copilot have voice input?
GitHub documents voice input in Copilot CLI (hold Space) and in the GitHub Copilot app (after you set a shortcut and download a local model).
How do I submit a GitHub comment from the keyboard?
GitHub lists Command-Return as the shortcut to submit a comment on a Mac.
Can people see what I wrote before I edited a comment?
Yes. GitHub says anyone with read access to the repository can view a comment's edit history.
Related guides
- How to dictate tickets and comments in Jira or Linear on a Mac
- How to dictate prompts to Claude Code, Cursor and other AI coding tools
- How to use voice dictation in VS Code on a Mac
- Voice to text in the Mac Terminal
- Teach SuprFlow names and acronyms
- How to use voice to text on a Mac