How to Dictate in GitLab: Voice to Text for Issues, Merge Requests, and Comments

Short answer: To dictate in GitLab, install Voice Keyboard Pro on your Mac or iPhone. On Mac, hold your hotkey and speak into any GitLab text box in the browser; on iPhone, tap the mic on the Voice Keyboard Pro keyboard inside GitLab in Safari or your client. Your words appear as text at the cursor in seconds.

GitLab is where a development team does its thinking out loud. The pipeline runs the code, but the reasoning lives in the prose around it: the issue that frames a problem, the merge request description that explains a change, the review thread that pushes back on an approach, the epic that ties a quarter of work together. That writing is the connective tissue of a team, and yet most of it gets typed in a hurry between other tasks, so it arrives thin, half-explained, or skipped entirely.

Speaking is simply faster than typing, and for a lot of people it is also easier to talk an idea through than to compose it in text. The average adult types around 40 words per minute, while comfortable speech runs 130 to 150 words per minute. When you can narrate a bug report at conversational speed, you naturally include the context you would otherwise leave out. This guide covers how to dictate directly into GitLab on both Mac and iPhone, how to handle markdown and GitLab's quick actions by voice, and how to make your issues, merge requests, and reviews genuinely clearer in the process.

Why dictate in GitLab at all?

There is a particular friction to writing on GitLab. You have the fix clear in your head, the reproduction steps obvious to you, the trade-off behind a design decision fully formed. Then you open the description box and stall, because turning all of that into typed paragraphs is slow and a little tedious. The result is the one-line issue everyone recognizes: "pipeline flaky, please look." Nobody enjoys receiving that, and nobody enjoys writing it either.

Dictation removes that friction. Speaking a bug report takes about the time it takes to describe the bug to a colleague standing at your desk, because it is the same act. You narrate what you did, what you expected, and what happened instead, and it lands as text. A merge request description that would have been two grudging sentences becomes three clear paragraphs, because the marginal cost of one more sentence is a few seconds of talking rather than another line of typing.

This matters most for the parts of GitLab that are pure writing:

• Issue descriptions: reproduction steps, expected versus actual behavior, environment details, and links to logs.
• Merge request write-ups: what changed, why this approach, what to test, and any follow-up you are deferring.
• Code review threads: the difference between a bare "change this" and a sentence that explains the reasoning behind the request.
• Epics and roadmap notes: longer-form framing where the argument matters more than any single diff.
• Wiki pages and READMEs: onboarding docs and runbooks that never get written because typing them feels like a chore.
• Commit message bodies: dictated in the GitLab web editor or in your terminal before you push.

Dictating in GitLab on Mac

GitLab on the desktop is a website, which is the easiest possible case for voice input. Voice Keyboard Pro for Mac lives in your menu bar and types at the cursor system-wide, so it works in any browser text field exactly the way it works in a native app. There is no GitLab integration to authorize and nothing to configure per project. It also works the same on GitLab.com and on a self-managed instance, because the app never talks to GitLab at all, it just types into whatever field has focus.

One-time setup

1. Download Voice Keyboard Pro for Mac from voicekeyboardpro.com and drag it to your Applications folder.
2. Open it once and grant microphone and accessibility permissions when macOS asks. Accessibility is what lets the app place text at your cursor in the browser.
3. Pick a hotkey you can hold comfortably. Many developers use a function key or a spare modifier so it never collides with editor or browser shortcuts.

Dictating into GitLab

1. Open the issue, merge request, or comment box in your browser and click into it so the cursor is blinking.
2. Hold your hotkey, speak the sentence or paragraph, then release.
3. The text appears in the field within about a second. Keep holding across several sentences, or release and re-press for each thought, whatever rhythm feels natural.

Because the app is system-wide, the same hotkey dictates into your code editor, your terminal, your chat client, and your email. You are not learning a GitLab-specific tool, you are building one dictation habit that follows you everywhere. If your team also tracks work elsewhere, the identical approach covers dictating in Jira and dictating in Linear with no change to your workflow, and it behaves just like dictating in GitHub if you move between the two.

Dictating in GitLab on iPhone

On the phone, GitLab writing is even more painful, because thumb-typing a detailed bug report on a small screen is nobody's idea of a good time. This is exactly where a voice keyboard earns its place. Voice Keyboard Pro installs as a custom iOS keyboard with a built-in mic button, so it works inside GitLab in Safari, in a mobile GitLab client, and in any other app you use to reach your project.

One-time setup

1. Install Voice Keyboard Pro from the App Store.
2. Open Settings → General → Keyboard → Keyboards → Add New Keyboard and add Voice Keyboard Pro.
3. Tap it in the list and enable Allow Full Access. This is what lets the keyboard send audio for transcription and return your text. If you want the reasoning behind that toggle, see our guide on enabling Full Access safely.

Dictating into GitLab

1. Open GitLab in Safari or your client and tap into an issue comment, a merge request thread, or a new issue body.
2. Switch to the Voice Keyboard Pro keyboard using the globe key.
3. Tap the mic button, speak, and watch your words appear. Tap again to stop.

The keyboard does not care which app you are in, so the same mic button dictates a GitLab review on your commute and a text message five minutes later. That is the whole point of a keyboard-level tool rather than an app-specific one.

Handling markdown and quick actions by voice

GitLab runs on markdown, and it adds its own layer of slash-based quick actions like /assign, /label, /milestone, and /close. The natural question is whether you can dictate all of that as well as the prose. The honest answer is that dictation is best at the words, and you add the structural markup and commands with a light touch. In practice this is faster than it sounds, because the words are the slow part and the symbols are the fast part.

A workflow that holds up well:

• Dictate the prose first, format second. Speak the whole comment or issue body as plain sentences, then go back and add headings, bullets, and code fences with a couple of keystrokes. You spend your voice on the 90% that is language and your fingers on the 10% that is punctuation.
• Speak your punctuation where it helps. Saying "comma," "period," and "new line" as you talk keeps sentences clean so you are not re-reading a wall of text afterward.
• Type the quick actions. GitLab's slash commands are short and precise, and they belong on their own lines. Dictate the human explanation of the change, then add /assign, /label, or /milestone by hand where they need to be exact.
• Use fenced code blocks for anything literal. Stack traces, job logs, and command output belong between triple backticks. Type those fences, then paste or dictate the surrounding explanation. Dictation is for describing the failure, not for reproducing the exact bytes of a log line.

The result is a comment where the writing is fast and human and the formatting stays correct, which is a far better trade than typing everything by hand just to keep the backticks and slashes in flow.

Getting technical vocabulary right

The one place generic dictation tends to stumble is on the vocabulary that fills a developer's writing: service names, class names, config keys, and acronyms that are not English words. You do not want to see "Cuban Eddie's" when you said "Kubernetes," or "post grey SQL" for "PostgreSQL," and you certainly do not want your own internal service names mangled every time.

Voice Keyboard Pro handles this with Smart Vocabulary, a personal dictionary with replacement rules. You add the terms you use constantly, spelled and capitalized exactly the way you want them, and the app applies them automatically. Add your framework and tooling names, your service and repository names, the runner and pipeline stages your team talks about, and the acronyms that fly around your standup. Once OAuth, nginx, PostgreSQL, and your own PaymentReconciler are in the dictionary, they come out right every time instead of being re-typed after every dictation.

This is the same reason dictation works well for the rest of your code-adjacent writing. If you want it inside your editor and command line too, our guides on dictation for coding and voice-typing git commits in the terminal go deeper on building a vocabulary that fits your stack, which is especially handy when you are writing the commit body that will become your merge request summary.

Fixing mistakes without retyping

No dictation is perfect, and the difference between a tool you keep and one you abandon is how painless the corrections are. On iPhone, Voice Keyboard Pro includes Voice Edit: instead of tapping backspace and retyping, you speak the change you want. If a sentence in your issue came out with the wrong word, you say what it should say and the text updates in place. For quick fixes on a phone screen, that is far less fiddly than trying to land your thumb between two characters.

On Mac, corrections are usually a matter of clicking into the spot and dictating the replacement, or just typing it, since your hands are already on the keyboard. The two input methods coexist. Dictate the paragraph, then fix the one word by hand. Most people settle into a hybrid where voice does the bulk and the keyboard does the surgery.

Writing GitLab issues and reviews that are actually good

Dictation does not just make writing faster, it changes what you are willing to write. A few habits that voice makes easy:

• Narrate the reproduction, do not summarize it. Talk through the exact steps as if walking someone to your screen. "I pushed to the feature branch, the build job passed, but the deploy job failed with a permissions error on the artifact." That level of detail is tedious to type and effortless to say.
• Explain the why in your merge request, not just the what. The diff already shows what changed. Use the description to say why this approach over the obvious alternative, and what you are leaving for a follow-up. Two spoken paragraphs here save your reviewer ten minutes of guessing.
• Make review comments complete and kind. "This could leave the transaction open if the request throws before commit, want to wrap it so it always rolls back?" reads very differently from "bug here." Voice makes the fuller, friendlier version cost almost nothing.
• Write the docs you keep skipping. The wiki page, the onboarding note, the runbook step for when the pipeline breaks at 2am. These get skipped because typing them feels like overhead. Dictated, they take a couple of minutes.

For teams, the compounding effect is real. Issues that reproduce cleanly get fixed faster. Merge requests with clear reasoning get reviewed faster. Epics where someone actually made the argument reach decisions faster. The bottleneck was never the thinking, it was the friction of typing it all out.

A note on privacy

Developers care about where their words go, and issue text can reference internal systems, unreleased features, and security details. Voice Keyboard Pro is built so that your dictation content is not stored on our servers. The transcription engine processes your audio to return text, and what we keep on the backend is limited to operational pings, not your audio and not the transcript of what you said. Your bug reports and review threads stay yours.

If private-by-default dictation is a priority for you across the board, our overview of private voice to text on Mac explains the approach in more detail.

Free tier and Pro

Voice Keyboard Pro has a free tier with a generous daily allowance, which is plenty to try dictating your next few issues and merge requests and decide whether it fits your workflow. If you find yourself living in GitLab and reaching for voice all day, Pro removes the daily limits and unlocks the full feature set for $4.99 per month or $34.99 per year. Pro spans both the Mac app and the iPhone keyboard, so one subscription covers dictating a review at your desk and filing an issue from your phone.

Frequently asked questions

Does dictating in GitLab need a browser extension?

No. On Mac, Voice Keyboard Pro types at the cursor across the whole system, so it works in GitLab's web interface in any browser with nothing to install per site. On iPhone, it is a keyboard, so it works in GitLab in Safari and in mobile clients alike.

Can I dictate code with it?

You can dictate code-adjacent prose easily, and short identifiers dictate fine once they are in Smart Vocabulary. For literal code, stack traces, and job output, use fenced code blocks and paste or type the exact characters. Dictation is best for the human language around the code, not for reproducing exact syntax character by character.

Will it get my service and library names right?

Yes, once you add them. Put your tools, services, repository names, and common identifiers into Smart Vocabulary with the exact spelling and capitalization, and they come out correctly every time instead of needing a fix after each dictation.

Does it work with self-managed GitLab?

Yes. The app does not integrate with GitLab directly, it types into whatever text field has focus, so it works the same on GitLab.com, on a self-managed instance, and on GitLab Dedicated, whether you reach it through a browser or a mobile client.

Is my issue text private?

Your dictation content is not stored on our servers. The backend keeps operational pings only, not your audio or your transcripts, so the words you speak into a GitLab comment stay yours.

Start dictating your next issue

The next time you have a bug to file or a merge request to explain, try talking it through instead of typing it. Open the box, hold your hotkey or tap the mic, and describe the problem the way you would to a teammate. The writing that used to feel like overhead becomes the fastest part of the task, and your issues, merge requests, and reviews get clearer as a side effect. Download Voice Keyboard Pro and dictate your next GitLab comment to feel the difference.