Mac Dictation Not Working in GitHub? 10 Fixes That Work

Short answer: If Mac dictation is not working in GitHub, click inside the comment box on the Write tab until the cursor blinks, then press your dictation shortcut. Anywhere else on the page, GitHub treats keys as shortcuts. Dictated text is not posted until you click Comment or submit your review.

A surprising share of a developer's writing happens on GitHub, and very little of it is code. It is the issue that explains a bug, the pull request description that says why a change was made, the review comment that asks a colleague to think again. That prose is much quicker to say than to type, which is why it is so irritating when you press your dictation shortcut and nothing lands in the comment box, or the page jumps to a search bar, or the review you spoke so carefully turns out to be invisible to everyone but you.

On a Mac, nearly all of this traces back to four facts about GitHub. First, most of a GitHub page is something you read, not a box you type in, and outside a text box GitHub treats single keys as shortcuts. Second, every comment box is a Markdown editor, so symbols in your text change how it is displayed, and a few of them open menus. Third, nothing you write is visible to anyone else until you press a button, and in a pull request review there are two buttons to press. Fourth, GitHub's comment boxes have no dictation of their own, so your words arrive exactly as if you had typed them, and GitHub applies every one of its usual rules to them.

This guide goes through the fixes in the order that finds the cause fastest. If dictation is failing in every app on your Mac, start with our full guide to Mac dictation not working and come back for the GitHub-specific parts.

First, where on GitHub are you writing?

A comment box in your browser

Issues, pull requests, discussions and review comments all use the same kind of box: a plain text area with Write and Preview tabs and a row of formatting buttons above it. This is where most dictation into GitHub goes. It needs a cursor in the box and nothing else. There is no mic button on these boxes, so your browser's microphone permission for the site does not come into it. Apple dictation and dictation apps both type at the cursor without it.

A single-line field

Issue and pull request titles, the search bar, filter boxes, branch names and commit summaries are one line each. They take dictated text, but they have no room for a line break, and in most of them the Return key does something: it searches, saves or submits.

The code editor

If you opened a file with the pencil icon, or landed in GitHub's web-based editor or a codespace, you are typing into source code. An editor built for code does not treat a spoken sentence the way a comment box does.

GitHub Desktop

GitHub Desktop is a separate Mac app with its own Summary and Description fields for a commit. Dictation types at the cursor there in the same way, but macOS treats it as a different application from your browser, with its own window and its own keyboard focus.

Knowing which of these you were in explains most of what follows.

The 30-second TextEdit test

Before you change any settings, open TextEdit, create a blank document and dictate one sentence the way you normally would.

• It fails in TextEdit too. The problem is your Mac's dictation settings, shortcut or microphone, not GitHub. Go to fixes 1 and 10.
• It works in TextEdit, but nothing is typed in GitHub. The comment box does not have keyboard focus, or you are not able to comment on this page. Go to fixes 2 and 4.
• The page jumps, a search bar opens or a menu appears. GitHub read a key as a shortcut. Go to fix 3.
• It worked earlier and stopped after a sign-in or password prompt. Go to fix 5.
• The text arrives, but looks wrong once posted, or parts are missing. That is Markdown, or one of GitHub's menus. Go to fixes 6 and 7.
• The text arrived, but your teammates cannot see it. It has not been posted. Go to fix 8.
• The text went somewhere else. Go to fix 9.

The 10 fixes, matched to what you see

1. Nothing happens when you press the dictation shortcut

If no microphone indicator appears at all, Apple dictation is either switched off or listening for a different shortcut. Open System Settings > Keyboard > Dictation, make sure Dictation is turned on, and read the Shortcut setting instead of assuming you know it. It is easy to be wrong about this on a work Mac that someone else set up, or after moving to a new keyboard. While you are there, confirm the language matches the one you speak.

If the shortcut uses the Globe key, also check what that key is set to do in System Settings > Keyboard. A Globe key assigned to switching input sources or showing emoji can get in the way. Our guide to the Mac dictation keyboard shortcut not working goes through every variation.

If you use a dictation app with its own hotkey, make sure the hotkey is not one GitHub already uses. Inside a comment box, GitHub takes Command-B, Command-I, Command-E and Command-K for bold, italic, code and links, and Command-Return to post. A dictation hotkey built on one of those will fight with the page.

2. The microphone appears, but no text is typed

Dictation types at the cursor, so a text box has to have keyboard focus, and most of GitHub does not qualify. A pull request page is a description, a timeline of comments, a list of commits and a set of diffs. An issue is a thread. A repository page is a file list and a rendered README. You can scroll and select all of it, but you cannot type into any of it. If the last thing you clicked was a line of a diff, a label or an empty part of the page, focus is on the page, and dictated words have nowhere to go.

Click directly in the comment box and look for a blinking cursor. Then run the one-character check: type a single letter on the keyboard. If it appears in the box, dictation will land there too, so delete the letter and dictate. If the page does something else instead, such as opening a search bar or a panel, GitHub took the key as a shortcut, which proves the box never had focus. Press Escape, click in the box again and repeat the check.

Three things on GitHub take focus away without looking like it:

• The Preview tab. Preview shows how your comment will look, and it cannot be edited. If you checked the preview and then started speaking, there is no cursor anywhere. Click Write first.
• A box that is not open yet. In the Files changed tab, a comment box only appears after you click the plus button beside a line of the diff. Under an existing review thread, the reply field is a single collapsed line until you click it.
• Something open on top of the page. A label picker, a reviewer list, an emoji menu or a confirmation dialog holds focus until you close it.

3. The page jumps or a menu opens instead of text appearing

GitHub is built to be driven from the keyboard. When focus is on the page and not in a text box, single keys are commands. On most pages a slash or the S key puts the cursor in the search bar. In a repository, T opens the file finder and a full stop opens the repository in the web-based editor. A question mark shows the list of shortcuts for the page you are on.

Apple's dictation generally types nothing at all when no text box has focus. But some dictation tools and text expanders deliver their text as real key presses, and so does any typing you do yourself while testing. GitHub acts on those keys. The result looks dramatic: you speak a sentence and the page changes, a file finder appears, or you land in a code editor you did not ask for.

Press Escape or use the browser's back button to get back to where you were, then click into the comment box before you dictate. If you never use GitHub's single-key shortcuts, you can turn them off. Open your GitHub settings, choose Accessibility, and under Keyboard shortcuts switch off Character keys. Shortcuts that use Command or Control keep working, and stray keys can no longer move you around.

Browser extensions that add keyboard navigation to every website cause the same symptom on every site, not only GitHub. If the page reacts to single keys even with GitHub's character keys switched off, an extension is the likely cause.

4. The comment box is missing, or will not take text

Sometimes the box is not there to click, and no dictation setting will bring it back.

• You are signed out. Sessions expire, and a private window starts signed out. In place of the comment box you see a prompt to sign in.
• The conversation is locked. Maintainers can lock an issue or pull request. Once it is locked, only people with write access to the repository can comment.
• The repository is archived. An archived repository is read-only. You can read issues and pull requests, but you cannot add to them.
• Interaction limits are on. Owners can temporarily restrict who is allowed to comment, for example to people who have contributed before.
• Your organization requires single sign-on. Until you authenticate, GitHub hides the organization's content behind a banner asking you to sign in.
• You are looking at someone else's text. An existing comment or description is not a text box. To change your own, open the menu on the comment and choose Edit. Changing another person's needs write access.

A new issue can also be a form. Many repositories replace the single description box with an issue form made of several fields, some of which are dropdowns and checkboxes. Dictation only goes into the text field that has the cursor, so click into each one in turn, pick from the dropdowns by hand, and watch for required fields that block the Submit button.

5. Dictation went dead after a sign-in or password prompt

While a password field is active, macOS limits what other apps can do with the keyboard, and dictation tools can stop responding. GitHub produces more of these moments than most sites. There is the sign-in page itself, the two-factor code that follows it, the prompt asking you to confirm access before a sensitive change to your settings, and your organization's single sign-on page. A password manager window left open counts as well.

Finish the prompt or close it, then click back into the comment box and try again. If dictation still does not respond, look for a second window or tab where a sign-in page is still waiting, and close that too. If that does not release it, quit the browser with Command-Q and reopen it. Apple dictation will not type into a password field in any case, which is by design.

6. The formatting is wrong, or words vanished

Every comment box on GitHub reads Markdown, which means certain characters are instructions and not text. Dictation does not know that. It writes the sentence you said, and GitHub formats it by its own rules once you post.

• A line that starts with a hash and a space becomes a heading. The whole line turns large and bold.
• A line that starts with a number and a full stop, or with a hyphen, becomes a list item. A sentence that happens to begin with a figure can be indented and renumbered.
• Asterisks around words turn them italic or bold, and the asterisks disappear. Two file patterns in one sentence, each starting with an asterisk, are enough to do it.
• Text in angle brackets that looks like an HTML tag is treated as HTML. In most cases it is stripped out. This is the one that makes words vanish: write Array<string> without code formatting and the part in brackets is gone from the posted comment.
• Anything between HTML comment markers is hidden. Many repositories pre-fill a new issue or pull request with a template whose instructions sit between <!-- and -->. If your cursor was inside one of those blocks when you spoke, your description is saved but never shown.

The fix is the same for all five. Click the Preview tab before you post and read the comment as other people will see it. If something is missing or oddly formatted, go back to Write and wrap the literal part in backticks, or put code, logs and error output in a fenced code block, where nothing is formatted. Dictation is good at sentences and poor at symbols, so type or paste the literal parts and dictate the explanation around them.

Line breaks behave differently depending on where you are. In a comment, a single line break is kept. In a Markdown file such as a README, a single line break is ignored and you need a blank line to start a new paragraph. If your dictated README paragraphs run together, that is why.

7. A menu popped up, or the wrong issue or person got linked

Four characters open menus or create links inside a comment box, and dictated text can contain any of them.

• The at sign. It opens a list of people and teams. Once posted, an at sign followed by a name is a mention if an account by that name exists, and that person may be notified. Email addresses and package names that begin with an at sign are the usual way to mention a stranger by accident.
• The hash sign. It opens a list of issues and pull requests, and a hash followed by a number links to the issue or pull request with that number in the repository. If dictation writes "number 12" as #12, your comment now points at issue 12.
• The colon. A colon followed by letters can open the emoji list.
• The slash. At the start of a line it can open GitHub's slash commands, where those are available.

When you type, you see the menu and react to it. Dictated text arrives in a burst, and if a line break follows straight after, it can accept whatever the menu had highlighted. Press Escape to dismiss a menu you did not want, and check the names and numbers in the box before you post.

One GitHub rule deserves particular care. In a pull request description, the words fixes, closes or resolves in front of an issue reference link that issue to the pull request, and the issue is closed automatically when the pull request is merged into the default branch. A casual spoken sentence that comes out as "fixes #12" can close an issue you never meant to touch. If a number is not an issue reference, wrap it in backticks or write it without the hash. Text inside backticks is never turned into a mention or a link.

8. You dictated it, but nobody else can see it

Dictation fills the box. It does not post. This is the fix that settles the most confusing GitHub reports, because from your side everything looks finished.

• The comment was never sent. Text sitting in the box is a draft. Click Comment, or press Command-Return with the cursor in the box.
• Your review comments are pending. In the Files changed tab, a new line comment offers two buttons. Add single comment posts it at once. Start a review holds it, marks it Pending and shows it only to you. Every comment you add afterwards joins the same pending review. Nothing is visible to your teammates until you open the review button at the top of the Files changed tab, which is labelled Review changes, Finish your review or Submit review depending on the version, and submit it.
• An edit was not saved. After changing an existing comment or description, click Update comment. Cancel throws the change away.
• The draft was lost. Following a link, switching to another pull request or closing the tab can discard text you had not posted. GitHub sometimes restores an unsent comment when you return to the page, but do not rely on it.

For anything long, such as a pull request description or a design discussion, dictate it in Notes or TextEdit and paste it in. Whatever the browser does, the draft survives.

9. The words landed in the wrong box, or in the code

A Mac gives dictated text plenty of places to land, and a pull request page adds more than most.

• The search bar. If a slash or a click put the cursor there, your sentence becomes a search query, and Return runs it.
• The title field. Titles are a single line. A spoken line break has nowhere to go there, and may save or submit the form instead.
• A different comment box. A pull request has a main comment box at the bottom of the conversation, a reply field under every review thread, and a summary box inside the review panel. Each belongs to a different place in the discussion. Check which one has the cursor.
• A suggestion block. The suggestion button in a review comment inserts a block that already contains the line of code you are commenting on. Anything inside that block is proposed code, and one click on Commit suggestion writes it into the file. Put your explanation above or below the block, never inside it.
• The find bar or a file filter. Command-F and the file filter in the Files changed tab both keep the cursor until you close or leave them.
• The code editor. If you are editing a file, your words go into the source. Code editors indent lines and close brackets and quotes for you, so a spoken sentence does not arrive the way it was said. That is fine for a comment or a documentation file, and risky anywhere else. GitHub's web-based editor and codespaces are Visual Studio Code running in the browser, so our guide to Mac dictation not working in VS Code applies there.
• Another window. Dictation goes to the frontmost window. If GitHub Desktop, a terminal or a second browser window came forward while you were reading, the text went there. If the terminal is where you write commit messages, see our guide to voice typing git commit messages in Terminal.

The cursor's position inside the box matters too. If you clicked into the middle of text that was already there, dictation inserts at that point. Click at the end of the text, or press Command-Down Arrow, before you speak.

10. Nothing works, anywhere

If the TextEdit test failed too, the problem is at the system level, and GitHub is simply where you noticed it.

• Check the input device. Open System Settings > Sound > Input, speak, and watch the level meter. If it does not move, your Mac is listening to the wrong microphone, such as a display, a webcam, a dock or a virtual audio device left behind by a meeting app. Pick the right one.
• Check Bluetooth headsets. A headset can be connected and playing sound while its microphone is not active. Switch the input to the built-in microphone to test. Our guide to Mac dictation not working with AirPods covers this.
• Turn dictation off and on. In System Settings > Keyboard > Dictation, switch Dictation off, wait a moment and switch it back on.
• Try a private window, then another browser. A private window runs without most extensions, which rules out anything that rewrites the page or adds its own shortcuts. If GitHub works in one browser and not another, our guides to Mac dictation not working in Chrome and in Safari cover the browser side.
• Restart and update. Restart the Mac, then check for macOS updates and for updates to your browser.

GitHub quirks that look like broken dictation

• A long description stops halfway. Apple's dictation can end a session on its own when you pause, and a pull request description involves plenty of pauses. What you said before the pause stays in the box and the rest is lost. Our guide to Mac dictation stopping after 30 seconds explains why and what to do about it.
• Your comments say Pending. They belong to a review you have not submitted. See fix 8.
• A type, a tag or a placeholder is missing from the posted comment. It was in angle brackets. See fix 6.
• The whole description is blank after posting. It went inside a template's hidden comment block. Edit the description and move your text outside the markers.
• Library, function and branch names come out wrong. Dictation has to guess at words it has not met, and identifiers are the words it is least likely to have met. Our guide to why Mac dictation gets words wrong covers the causes.
• Commit summaries arrive with a capital letter and a full stop. Dictation writes sentences. If your team's convention says otherwise, tidy the summary by hand.
• Someone you do not know was mentioned. An at sign reached the comment. Edit it to remove the mention, though the notification may already have gone out.

Quick triage

• No microphone indicator when you press the shortcut: Dictation is off or the shortcut is different. Fix 1.
• Indicator shows, nothing is typed: the comment box does not have focus, or the Preview tab is open. Fix 2.
• The page jumps or a search bar opens: a single-key shortcut fired. Fix 3.
• There is no comment box: signed out, locked, archived or restricted. Fix 4.
• Dictation stopped after a sign-in prompt: a password field is still active. Fix 5.
• Headings, lists or missing words in the posted comment: Markdown. Fix 6.
• A menu appeared, or the wrong issue or person is linked: an at sign, hash, colon or slash. Fix 7.
• Nobody else can see the comment: not posted, or part of a pending review. Fix 8.
• The text is in search, the title, a suggestion block or a file: the cursor was somewhere else. Fix 9.
• Fails in TextEdit as well: input device, settings or extensions. Fix 10.

Why the writing around the code is worth speaking

Most people speak at around 130 to 150 words per minute. The average adult types at about 40, and even professional typists, at 80 to 100, do not reach speaking pace. For a one-word review comment the gap is irrelevant. For a pull request description that explains why you chose this approach over the obvious one, or a bug report with the steps, the expected result and what you have already ruled out, an average typist can say it in around a third of the time it takes to type.

There is a quieter benefit too. Typing is effort, so typed reviews shrink to a few words that the author has to decode. Speaking is cheap, so a spoken comment tends to arrive as a full sentence with the reason attached, which is kinder to read and quicker to act on.

For the writing itself, see our guides on how to dictate in GitHub and dictating pull request descriptions and review comments. If your team tracks work elsewhere, the same kinds of problems turn up there, and we have guides to Mac dictation not working in Jira and in Linear.

One hotkey for every box on GitHub

Much of the trouble above comes from system dictation ending a session when you stop to think, and from mishearing the names that matter most in technical writing. A dictation app that types at the cursor helps with both.

Voice Keyboard Pro is a Mac app that lives in the menu bar. Hold a hotkey, speak, release, and the text appears at your cursor, system-wide. Because it types wherever the cursor is, it works the same way in a GitHub comment box in any browser, in GitHub Desktop and in your editor. It still needs a text box with focus, and GitHub still reads what arrives as Markdown and waits for you to post it, so fixes 2, 6, 7 and 8 apply whichever tool you use.

Two things suit developers in particular:

• You control when it listens. Recording runs while you hold the key, so a pause to work out the next sentence does not end the session. A long description arrives as one piece of text.
• Smart Vocabulary. This is a personal dictionary with replacement rules. Add the framework names, repository names, internal service names and acronyms your team uses, spelled and capitalised the way you want them, and Voice Keyboard Pro's transcription engine applies them every time.

If your stand-ups and design reviews turn into issues afterwards, the Mac app also has Meeting Mode with speaker detection and AI notes, and it can detect meetings from your calendar.

On privacy, our servers store only operational pings. No audio and no transcript content is stored, which matters when an issue describes an unreleased feature or a security problem. There is a free tier with daily limits, and Pro is $4.99 a month or $34.99 a year. On iPhone, Voice Keyboard Pro is a custom keyboard with a built-in mic button, so the same approach works in the GitHub app there.

Frequently asked questions

Does GitHub have its own dictation or voice typing?

GitHub's comment boxes have no mic button. On a Mac you dictate with Apple's dictation or a dictation app, both of which type into whichever text box has the cursor, exactly as if you had typed the words.

Does my browser need microphone permission for GitHub?

No. Apple dictation is part of macOS, and a dictation app has its own microphone permission. Neither uses the browser's permission for the GitHub site. If nothing is typed, the comment box does not have focus, or Dictation is off in System Settings.

Why did the page jump to search when I tried to dictate?

Focus was on the page, not in a text box, and GitHub read a key as one of its single-key shortcuts. Click into the comment box first. You can switch those shortcuts off under Accessibility in your GitHub settings by turning off Character keys.

Why are my review comments marked Pending?

They are part of a review you started and have not submitted. Only you can see them. Open the review button at the top of the Files changed tab and submit the review, and they become visible to everyone.

Why did part of my comment disappear after I posted it?

GitHub treated it as HTML. Text in angle brackets that looks like a tag is usually removed, and anything between HTML comment markers is hidden. Edit the comment and wrap the literal part in backticks.

How do I post a dictated comment without reaching for the mouse?

With the cursor in the comment box, press Command-Return. A plain Return only starts a new line in a comment box.

Can I dictate code into GitHub?

You can dictate the prose around code easily. For literal code, logs and commands, type or paste the exact characters into a fenced code block. Dictation is built for sentences, and code editors change text as it arrives.

What to do next

Run the TextEdit test, then click into GitHub's comment box, type one letter to confirm it has focus, and dictate. Those two steps settle most GitHub dictation problems on a Mac. If the page jumps around, a single-key shortcut fired, so click into the box first or turn Character keys off. If the comment looks wrong, check the Preview tab before you post. And if nobody can see what you wrote, look for the Comment button you did not press or the review you did not submit.

If you would rather have one hotkey that behaves the same in GitHub and everywhere else on your Mac, Voice Keyboard Pro has a free tier. Install it, click into a comment box and speak your next review.