Tutorial
Voz para texto no GitHub: como isso funciona de verdade
O GitHub não tem ditado próprio — os campos de issue, PR, comentário e markdown são apenas textareas comuns da web. Um app de atalho global do sistema segura uma tecla, transcreve o que você fala e cola no campo que estiver em foco.
Última atualização: junho de 2026

Voz para texto no GitHub significa ditar texto corrido nos campos do GitHub usando um app de atalho global do sistema, porque o GitHub não tem ditado próprio. Os campos de issue, pull request, comentário e markdown são apenas textareas comuns da web. Uma ferramenta como o Whisper segura um atalho, transcreve o que você fala e cola no cursor — na issue, no PR ou na nota de revisão que você tiver em foco.
Passei uma semana no ano passado convencido de que o GitHub tinha lançado discretamente um botão de voz em algum lugar do editor de issues. Não tinha. O corpo da issue é uma textarea. A descrição do PR é uma textarea. O comentário de revisão, o campo de Discussions, o editor de README — tudo textareas, do mesmo tipo que um formulário de contato usa. Não há ícone de microfone escondido em algum menu. A verdade sem graça é que a escrita que você faz em volta do seu código no GitHub é só entrada de texto, e qualquer ferramenta de ditado decente consegue preenchê-la.
Isso é uma boa notícia, porque significa que você não precisa esperar o GitHub criar um recurso. Você traz sua própria camada de voz. No Windows ou no Mac, o Whisper fica no nível do sistema operacional, então o mesmo atalho funciona no editor de issues, na descrição do PR, em uma thread de revisão de código, na sua IDE e no Slack — em qualquer lugar onde um cursor pisca. Você clica no campo, segura a tecla, fala e solta. Uma ressalva importante logo de cara, e vou repetir isso várias vezes: isso é para o texto, não para o código.
O GitHub não tem digitação por voz. Seu atalho é que faz o trabalho.

Deixa eu responder à pergunta que as pessoas realmente digitam no Google. Não, o GitHub não tem voz para texto nativo. Não há ditado nativo no editor de issues, no formulário de PR, no painel de revisão, em Discussions ou na wiki. Esses são textareas padrão da web. Para ditar neles, a voz tem que vir de outro lugar: do seu sistema operacional, do seu navegador ou de um app de terceiros.
O GitHub nunca bloqueia o ditado. Ele simplesmente não oferece nenhum por conta própria. Então suas opções são basicamente três. Seu sistema operacional já tem ditado embutido — a Digitação por Voz do Windows no Win+H, ou o Ditado do macOS. Uma extensão de navegador como o Voice In consegue digitar em uma aba do Chrome ou do Edge. Ou um app de desktop global como o Whisper dita em qualquer campo de qualquer app, com navegador ou não.
A diferença entre esses três é o alcance. O ditado do sistema operacional é gratuito e funciona em uma plataforma de cada vez, com qualidade que varia. Uma extensão de navegador só vive dentro da aba — ela não consegue te seguir até a sua IDE ou o GitHub CLI, e roda na nuvem. Um app de desktop como o Whisper não fica preso a uma aba; porque funciona no nível do sistema operacional, ele dita no GitHub no Chrome, no Firefox, no Safari ou no Edge, e também em uma mensagem de commit no GitHub Desktop.
O que você realmente pode ditar (e a única coisa que não pode)
Aqui está a linha que eu não vou deixar você cruzar por acidente. O Whisper dita a escrita em volta do seu código. Ele não vai escrever o código em si.
O que isso cobre é a maior parte do dia de digitação de um desenvolvedor, sinceramente. Relatórios de issue. Descrições de pull request. Notas de revisão de código. Respostas em Discussions. README e docs em markdown. O texto que explica a mudança, não a mudança. Quando você fala um parágrafo descrevendo por que uma migração é arriscada, o Whisper dá conta tranquilo. Quando você tenta ditar a migração, sua tarde vai ser ruim.
O motivo é simples. Código falado não sobrevive ao trajeto. Nomes de função, JSON, snake_case versus camelCase, uma flag do kubectl, um caminho de API — tudo isso sai como um inglês de melhor esforço e precisa de correção manual. Um modelo de voz ouve "user underscore I D" e escreve "user ID", e agora você está corrigindo. Então dite a frase que diz "este PR corrige a verificação de null no middleware de autenticação", e depois digite o identificador real. A maioria dos corpos de issue e PR é 80% explicação e 20% trecho de código, de qualquer forma. Dite os 80, digite os 20.
Aperte um atalho, fale, receba o texto no campo em foco
A mecânica é a mesma que você usaria em qualquer outro app, que é justamente o ponto. Clique no campo do GitHub que você quer preencher. Segure o atalho. Fale. Solte. A transcrição aparece no cursor.
O atalho padrão é Ctrl+Space no Windows e Command+Option no macOS. Ambos são push-to-talk: segure enquanto fala, solte para parar. Você pode mudá-los nas configurações se eles conflitarem com algo — e se você já brigou com um conflito de atalho, sabe por que essa opção mereceu seu lugar (mais sobre isso abaixo).
Um detalhe honesto sobre o escopo. O Whisper cola no único campo que você tem em foco, um de cada vez. Ele não preenche um formulário inteiro de issue do GitHub em um só fôlego. Então o fluxo para uma nova issue é: clique no título, dite, clique no corpo, dite aquilo. Dois campos, dois toques. Parece menos com mágica e mais com um digitador rápido que nunca toca no teclado. Esse é o modelo mental certo.
O app inteiro, ao vivo
Este é o app de verdade, rodando aqui mesmo — não é uma captura de tela. Explore à vontade. As configurações, o seletor de atalho e as opções de modelo são a coisa real.
Algumas coisas que vale a pena saber enquanto você clica. Não há uma aba específica do GitHub nem um "modo GitHub", porque não precisa haver. Para o Whisper, uma descrição de PR do GitHub é um campo de texto como qualquer outro. A mesma configuração que dita no editor de issues dita no seu e-mail e na sua IDE. Você configura uma vez. O alcance é o recurso.
Onde compensa: issues, descrições de PR, revisões, discussões
O retorno está na escrita chata e repetitiva — aquela coisa que você adia porque digitar é um saco.
Issues. Um bom relatório de bug é basicamente narração: o que você fez, o que esperava, o que aconteceu no lugar. Esse é o território natural do ditado. Fale os passos para reproduzir do jeito que você explicaria a um colega na sua mesa, e depois cole o stack trace na mão.
Descrições de pull request. O corpo do PR que todo mundo deixa de escrever porque o diff "fala por si" (não fala). Dite o porquê — o contexto de que o revisor precisa — e deixe o diff falar o quê.
Revisões de código. Os comentários de revisão são onde o tom importa e onde as pessoas explicam de menos. Falar uma nota de revisão tende a sair mais humana e mais completa do que digitar uma no intervalo entre reuniões. Você vai escrever "isso funciona, mas vai quebrar quando a lista estiver vazia" em vez de só "caso de borda?"
Discussions e docs. Texto longo, que é exatamente onde a voz se sai bem e exatamente o que ninguém quer digitar. Uma introdução de README, uma resposta em Discussions, um guia de migração — dite o rascunho e ajeite o markdown depois. A mesma lógica vale para ditar em tickets do Jira e outros gerenciadores; o GitHub é só mais um campo na pilha.
Limpe o ditado automaticamente
O ditado bruto tem enrolação. "Hum", "sabe como é", a frase que você começou duas vezes. O Whisper tem uma passada opcional de limpeza por IA que corrige palavras de preenchimento, pontuação e caixa, para que a issue ou o PR pareça que você escreveu com cuidado.
São dois sabores. No nível local gratuito, a limpeza roda na sua máquina via Ollama. No Pro, você traz sua própria chave da OpenAI e a limpeza roda na nuvem, com respostas da web também disponíveis. De qualquer forma, é opcional — desligue e você recebe a transcrição bruta. Eu deixo ligada para descrições de PR e desligada para comentários rápidos, porque um comentário rápido não precisa de edição e uma descrição de PR precisa.
Uma coisa que a limpeza não vai fazer é salvar código falado. Ela pole o inglês. Ela não sabe que você quis dizer getUserById quando falou "get user by I D". Continue ditando o texto; continue digitando os identificadores.
Offline e privado: nada sai da sua máquina no modo local

Se você dita issues e PRs sobre código que não é público, para onde o áudio vai importa. No modo local do Whisper, a transcrição acontece inteiramente na sua máquina. Nada do que você fala é enviado para um serviço na nuvem. Nenhuma internet é necessária durante a transcrição — a única vez em que você fica online é o download único do modelo, que vai de cerca de 140 MB a 3 GB dependendo do modelo que você escolher.
Este é o único lugar em que vou te dar uma opinião de verdade. Ditado só na nuvem é um desastre de privacidade esperando para ser transcrito. Uma vez vi um time interno acumular uma conta de nuvem de cinco dígitos em um único trimestre porque um protótipo de ditado caseiro mandava cada fala para uma API — e a parte pior não foi a conta, foi que as notas faladas de todo mundo sobre um produto não lançado agora viviam nos logs de um fornecedor. A planilha de salários do seu chefe, o problema de segurança que você está registrando em sigilo, a arquitetura proprietária que você está descrevendo em um PR — nada disso deveria sair do seu notebook só porque você quis digitar um parágrafo com a voz. Sua máquina já tem um microfone e uma CPU. Para um parágrafo, ela não precisa de um servidor no meio do caminho. Se a sua ferramenta só roda na nuvem, essa é a parte que eu consertaria primeiro.
Para o que ele não serve (escrever código)

Você pode ter vindo aqui procurando uma forma de escrever código por voz, ou se lembra do "Hey, GitHub!" e se pergunta para onde ele foi. Duas respostas honestas.
O "Hey, GitHub!" e o GitHub Copilot Voice eram uma prévia técnica do GitHub Next. O GitHub descontinuou a prévia em 2024. Ela nunca virou produto; os aprendizados foram para a extensão VS Code Speech. Então, se um post de blog te disser para ativar o "Hey GitHub" hoje, ele está desatualizado em alguns anos.
A faixa de voz-para-código ainda existe — ela só vive no seu editor e no terminal, não no github.com. A extensão VS Code Speech (às vezes chamada de "Hey Code") permite que você fale com o editor e com o Copilot Chat para código e comandos. E o GitHub Copilot CLI adicionou recentemente entrada de voz local que controla o agente do Copilot no terminal. Ambos servem para comandar código e um agente de IA. Nenhum dos dois dita texto corrido em uma issue do GitHub no seu navegador. Essa é uma faixa diferente, e é a que o Whisper domina: a escrita em volta do código.
Quando deixar o Whisper de lado no seu fluxo de GitHub
Prefiro que você use a ferramenta certa do que a que eu faço. Então aqui está quando deixar o Whisper de lado.
Se o que você realmente quer é comandar o Copilot ou o seu editor por voz — "conserte esta função", "rode os testes", "explique este bloco" — essa é a faixa de código/agente, não de texto. Use a extensão VS Code Speech ou a entrada de voz do GitHub Copilot CLI em vez disso. Elas falam com a máquina; o Whisper escreve as palavras que um humano lê.
Se você só dita de vez em quando um comentário de uma linha, seu sistema operacional já faz isso de graça. Aperte Win+H no Windows ou ative o Ditado no macOS e você consegue jogar uma frase rápida em um campo do GitHub sem instalar nada. O Whisper começa a valer a pena quando você está escrevendo parágrafos de verdade em vários apps, quer que funcione offline, ou quer um único atalho em todo lugar em vez de um recurso do sistema operacional que só cobre alguns campos. Abaixo desse patamar, a opção embutida serve bem, e não vou fingir o contrário.
Local gratuito, com Pro para a nuvem
O pipeline local — transcrição, a limpeza por IA no dispositivo, o atalho, tudo o que você precisa para ditar no GitHub — é gratuito para usuários logados, e não exige cartão no cadastro. Você instala, faz login e começa a ditar.
O Whisper Pro acrescenta a parte na nuvem: transcrição na nuvem da OpenAI, limpeza por IA na nuvem com a sua própria chave e respostas da web, com um teste curto para esse nível. Para ditar issues e PRs, o nível local gratuito cobre o trabalho inteiro. Os números do Pro estão na página de preços; não vou ficar citando eles no meio do parágrafo.
Uma última coisa sobre aquele atalho
Uma palavra sobre por que o atalho é personalizável, já que isso amarra tudo. A primeira versão do Whisper disparava o fim da gravação seis vezes por toque de tecla em certas máquinas Windows — eventos fantasmas de soltar a tecla vindos do framework de entrada, do tipo que funciona numa instalação limpa e quebra numa real. Foram precisos um debounce de 300ms e mais tempo do que vou admitir para deixar isso confiável. Aprendi mais sobre o tratamento de entrada do Windows do que jamais quis. A lição ficou: o atalho tem que se dobrar à sua máquina, não o contrário. Clique no campo, segure a tecla, fale. O código, você ainda digita sozinho — e acho que essa é a versão honesta do acordo.
Dite a sua próxima issue do GitHub
Clique no campo, segure a tecla, fale, solte. A transcrição cai onde o seu cursor está — no editor de issues, na descrição do PR e em todos os outros apps também.
Modo local gratuito para qualquer conta logada. Não precisa de cartão para começar.



