← All guides

GitHub voice typing on Mac

GitHub’s website gives you editors—not a microphone.

GitHub’s current web documentation explains Markdown comment fields, issue forms, pull-request reviews, and submission shortcuts. It does not identify a native microphone control for those github.com editors. On a Mac, system Dictation can provide text to a supported focused field. GitHub Copilot CLI `/voice` is a separate terminal feature with a different processor and destination.

Source-reviewed

1. Keep github.com separate from Copilot CLI voice

GitHub’s website has editable surfaces for issue titles and bodies, pull-request descriptions, discussion posts, ordinary comments, line comments, and review summaries. Current GitHub web documentation describes text and Markdown controls for those surfaces, not one shared website microphone workflow.

GitHub Copilot CLI is different. Its native `/voice` command records at an interactive terminal prompt and GitHub documents local transcription there. Do not transfer the CLI shortcut, language models, `/refine` command, or local-audio claim onto github.com.

2. Dictate only after the intended editor has focus

Open the correct repository, issue, pull request, or discussion. Place the insertion point in the exact editable field, then start the current macOS Dictation shortcut. Speak, stop Dictation, and confirm that the transcript appeared in that field rather than a search box, command palette, or another browser tab.

For a new issue, keep the title and body separate. GitHub’s current issue procedure ends with Submit new issue; voice input should create reviewable field text, not choose the repository, issue type, assignee, labels, project, milestone, or final submission for you.

  • Confirm the repository and destination before speaking.
  • Focus the exact title, body, comment, or review field.
  • Stop Dictation before navigating or submitting.

3. Use Write and Preview as an accuracy check

GitHub says every comment field has a formatting toolbar and supports GitHub Flavored Markdown. Dictated prose can work well for context, reproduction steps, expected behavior, review rationale, and discussion replies, but exact Markdown, inline code, tables, task lists, URLs, and identifiers still need inspection.

Use the Preview tab before publishing a long issue or pull-request description. GitHub documents Command + Shift + P on Mac for toggling Write and Preview in comments and issue or pull-request editors. A clean transcript can still render incorrectly when punctuation changes a link, mention, task list, or code span.

4. Treat comment and review submission as consequential actions

GitHub documents Command + Enter on Mac as the shortcut that submits a comment. It also documents Command + Shift + Enter for submitting a review comment from Files changed. Keep those shortcuts separate from the Dictation shortcut and do not press them until the complete draft is visible.

A pull-request review has more state than an ordinary comment. Pending line comments can remain visible only to you until the review is submitted, and the final review can be Comment, Approve, or Request changes. Confirm the intended state and review summary before Submit review.

5. Review the details speech recognition is likely to damage

Check repository and issue references, usernames, @mentions, branch names, file paths, function names, package names, version numbers, negations, security language, and reproduction steps. Read exact code and commands from a trusted source rather than speaking them from memory.

For a bug report, verify the observed behavior, expected behavior, minimal reproduction, environment, logs, and impact. For a review, verify whether a statement is a question, a suggestion, a blocking concern, or a reason to approve or request changes.

6. Troubleshoot the input layer before changing GitHub settings

If Dictation fails everywhere, test one short sentence in TextEdit and follow Apple’s current checks for Keyboard settings, shortcut, language, microphone, Voice Control, and network requirements. If TextEdit works, system recognition is functioning.

If only github.com fails, confirm the field is editable and that focus is still inside it. Website microphone permission belongs to a site feature that directly captures audio; system Dictation is a separate Mac input path. Also check GitHub’s current page shortcuts so a character or modifier key is not navigating, previewing, or submitting unexpectedly.

7. Add IraVoice only for a distinct local or structured workflow

Use macOS Dictation first for occasional GitHub prose. Use Copilot CLI `/voice` first when the destination is already an interactive Copilot prompt.

IraVoice 0.7.1 is the separate option for macOS 26+ Apple-silicon Macs when recognition and supported formatting should run on the Mac across supported apps, or when a longer spoken requirement should become reviewable Markdown before you choose GitHub, Jira, or an agent. IraVoice does not sign in to GitHub, read repository context, select an issue or pull request, add mentions, choose a review status, press Submit, or merge code.

Decision guide

Which GitHub voice-input path fits?

Choose by destination, artifact, and whether GitHub should receive the text yet.

If you needChooseWhy
Dictate an occasional issue or comment on a MacmacOS DictationIt can provide text to a supported focused GitHub field.
Speak into an active Copilot CLI promptCopilot CLI /voiceIt is GitHub’s native terminal voice path with documented local transcription.
Check a long Markdown draft before publishingGitHub Write and PreviewPreview exposes broken formatting, links, task lists, and code spans.
Create a reusable structured bug or feature briefIraVoice Voice-to-SpecThe Markdown artifact can be reviewed before it reaches a repository.
Approve, request changes, submit, or mergeGitHub’s explicit controlsSpeech-to-text should not decide repository actions or review state.

Primary sources

Use the current documentation.

This guide was reviewed July 26, 2026. Product versions, settings, policies, and availability can change.

  1. GitHub Docs: About writing and formatting

    Current GitHub Flavored Markdown, web-interface, comment-field toolbar, mentions, references, task-list, and editor-font scope.

  2. GitHub Docs: Keyboard shortcuts

    Current Write and Preview, comment submission, review-comment submission, repository navigation, and accessibility-shortcut controls.

  3. GitHub Docs: Creating an issue

    Current title, body, repository, metadata, issue-form, and explicit Submit new issue workflow.

  4. GitHub Docs: Reviewing proposed changes

    Current pending comments, line and file comments, suggestions, summary, review type, abandonment, and Submit review workflow.

  5. Apple: Dictate messages and documents on Mac

    The separate system Dictation shortcut, focused-field workflow, stop controls, and configuration-specific processing check.

  6. Apple: If Dictation on Mac does not work as expected

    Current Keyboard, shortcut, language, microphone, Voice Control, connection, and app-field troubleshooting.

Questions

What readers usually ask next.

Does GitHub have built-in voice typing on its website?

The current GitHub web documentation reviewed here describes text and Markdown editors, formatting controls, and keyboard shortcuts but does not identify a native microphone path for github.com issue, pull-request, discussion, or comment fields. GitHub Copilot CLI `/voice` is a separate terminal feature.

Can I dictate a GitHub issue or pull-request review on Mac?

Yes, when the intended GitHub field accepts the configured macOS Dictation input. Focus the exact title, body, comment, or review field, dictate, stop, review the text and Markdown, then submit separately.

Will Mac Dictation submit my GitHub comment?

System Dictation provides text to the focused field; submission is a separate GitHub action. Be careful because GitHub documents Command + Enter as the Mac shortcut for submitting a comment.

Is GitHub website voice typing the same as Copilot CLI voice?

No. Copilot CLI `/voice` records inside the terminal prompt and has documented local speech models. Dictating into github.com uses a system or third-party text-input path in a browser field.

Can I dictate GitHub Markdown?

You can dictate prose into a GitHub Markdown field, but inspect exact Markdown, links, mentions, task lists, tables, code spans, paths, and identifiers. Use GitHub’s Preview before publishing a long draft.

Can IraVoice create or submit a GitHub issue for me?

No. IraVoice does not access repositories, choose issue metadata, add reviewers, select a review state, submit comments, or merge code. It can create local editable text or reviewable Markdown for you to place in the intended field.

macOS 26+ · Apple-silicon

Try the local Mac workflow for yourself.

Dictate ordinary text or turn a rough technical thought into reviewable Markdown during the 14-day full trial.