Skip to content
How to · Mac voice writing

Dictate GitHub issues and pull request descriptions on a Mac

How to dictate GitHub issues, pull request descriptions and review comments on a Mac, where GitHub documents voice input, and what to check before you submit.

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."

  1. Turn on Dictation once in System Settings → Keyboard → Dictation. On older macOS versions the wording may differ.
  2. Open the repository's issues list and press C to create an issue, or open the pull request you are describing (Keyboard shortcuts).
  3. Type the title. Short titles with file names and versions are faster to type.
  4. Click in the description box.
  5. Press the Microphone key or your Dictation shortcut. Speak in sections: what happened, what you expected, steps to reproduce. Say "new paragraph" between them.
  6. Stop with the same key. Paste logs, commands and code by hand inside code fences.
  7. 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 inputApple DictationSystem-wide app (SuprFlow as the example)
Issues, pull requests, comments on github.comNot documentedYesShould work; test first
Copilot CLI and Copilot app promptsYes, transcribed locallyYes, if the field accepts itShould work; test first
CostPart of your Copilot accessFree with macOS$125 once
StartHold Space in Copilot CLI; your chosen shortcut in the appMicrophone key or shortcutHold Fn, release to insert
Best forPrompting CopilotOccasional issues and commentsMany 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.

Sources

Keep going

Read next

More how to
Put the guide to work

Make the first useful sentence.

Set up SuprFlow on your Mac, then try this guide in the app where you actually write.

  1. 01Download a speech model
  2. 02Dictate a harmless sample
  3. 03Check the text in its destination
SPECIAL OFFER$29 once Original price: $125

One license. Up to 5 Macs you own.Special offer, down from $125.Apple Silicon · macOS 14+

Get SuprFlow for Mac

7-day no-questions-asked refund on your first purchase. Contact support within seven days for a full refund. Read the refund terms ↗