Comentários e reações em PR: como funciona a sincronização entre Cursor e GitHub?

Metade do time revisa no GitHub, a outra metade vive dentro do editor, e aí bate aquele frio na barriga: o PR vai virar dois lugares onde ninguém sabe qual comentário é o oficial?

Esse é o medo real de quem ouviu falar que o Cursor agora hospeda código

O Cursor soltou o Origin em beta e puxou pull request pra dentro do editor, com sincronização de repositórios do GitHub junto

E a pergunta que interessa não é "tem PR no Cursor?", é "a conversa da revisão continua uma só?" 🙂

O que é o Origin e por que a revisão de PR mudou de lugar

O Origin é a plataforma de hospedagem de código do Cursor

Ele entrou em beta inicial no dia 17 de agosto de 2026, liberado pra quem está em plano pago (Pro, Teams e Enterprise), com opt-out pros administradores de organizações Enterprise que preferirem ficar de fora

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

No plano gratuito ele não aparece, então já corta essa dúvida logo de cara

A estreia veio com repositórios, pull requests, navegação de código, sincronização com GitHub e acesso aos agentes do Cursor

Onde isso mora? Segundo o changelog do próprio Cursor, na aba Codebase, que é a home dos repositórios do Origin dentro do editor

E tem a coincidência que rendeu piada na timeline: o lançamento caiu no mesmo dia em que o GitHub teve uma interrupção significativa 😀

O que muda para um time em que parte revisa no GitHub e parte no Cursor

Aqui é o coração do assunto

Em repositório sincronizado, os pull requests sincronizam nos dois sentidos: o comentário que você escreve no Cursor é publicado no GitHub, e a reação ou resposta feita no GitHub aparece no Cursor em segundos

Ou seja, ninguém precisa escolher um lado da mesa

Se você já brincou de sincronização bidirecional com n8n entre ferramentas diferentes, a ideia é a mesma: um evento de um lado vira evento do outro, sem alguém ficar copiando e colando na mão

Tem mais: uma revisão atribuída a você no GitHub pode ser revisada e mesclada de dentro do Cursor

O review request chega, você atende e o merge sai dali mesmo

E o histórico não fica órfão dentro do editor, porque o GitHub continua sendo a fonte da verdade no repositório sincronizado: os pushes feitos no Origin passam adiante para o GitHub

Então o repositório que o resto da empresa enxerga segue sendo o de sempre, beleza?

Como sincronizar um repositório do GitHub com o Cursor

Antes do passo a passo, o PORQUÊ do conceito

Espelhar (mirror) copia um repositório do GitHub para o Origin e mantém o Origin atualizado conforme o repositório do GitHub muda

É cópia viva, não é um zip que você baixou e esqueceu num canto

Os nomes de tela abaixo são os que a documentação do Cursor usa, então bora ver o caminho:

1. Confira os requisitos. Você precisa de uma conta Cursor com acesso ao Origin em plano Pro, Teams ou Enterprise, e do app do Cursor no GitHub conectado à organização ou conta dona do repositório. Erro comum deste passo: tentar sincronizar com o app conectado na sua conta pessoal quando o repositório pertence à organização, ou procurar o fluxo estando no plano gratuito (nesse caso ele simplesmente não existe pra você)
2. Abra a home do Codebase e escolha Sync from GitHub. A doc é explícita: é essa opção, não o New, que é pra repositório novo. Erro comum deste passo: clicar em New no automático e acabar com um repositório vazio no Origin, sem vínculo nenhum com o GitHub
3. Selecione a organização e o repositório do GitHub. Se a org não aparece na lista, o problema quase sempre está no passo 1, na conexão do app
4. Confirme a sincronização. A partir daí o Origin passa a acompanhar o que muda no GitHub

Recomendo começar por um repositório de baixo risco, aquele projeto interno que ninguém vai chorar se precisar detachar depois

Como fica a revisão na prática: timeline, diff, comentário e merge

Na página de pull request do Origin o revisor encontra a timeline com commits, checks, arquivos alterados e a visão de diff

É nesse diff que ele comenta, e é ali que fica o botão de merge

Quem já revisou PR na web não vai se perder: a leitura é a mesma, o que muda é o endereço

Cenário 1: o revisor abre no Cursor, o autor acompanha pelo GitHub

O revisor lê o diff dentro do editor e deixa os comentários por lá

Esses comentários são publicados no GitHub, então o autor vê a revisão no lugar de sempre, sem precisar instalar nada

Cenário 2: o caminho inverso

O autor responde no GitHub e reage ao comentário por lá

A reação e a resposta aparecem no Cursor em segundos, sem alguém ter que dar F5 na vida

O efeito prático é esse: a conversa continua sendo UMA, mesmo com o time dividido em duas interfaces

E pra quem gosta de plugar ferramenta própria no fluxo, o Origin tem uma API REST pública que permite a apps e ferramentas trabalhar com repositórios, commits, checks, pull requests e instalações de apps

Dá pra pensar em automação de checagem, painel interno, bot de triagem, por aí vai

Se a sua dúvida é mais lá atrás, no "qual ferramenta eu coloco na cadeira do dev", esse comparativo entre Claude Code e Cursor ajuda a montar o combo antes de mexer no fluxo de revisão

O que NÃO sincroniza entre Cursor e GitHub

Essa é a parte que costuma quebrar expectativa, então vou no formato sintoma, causa e o que fazer

Sintoma: você espelhou o repositório, abriu o Origin e as issues sumiram

Causa: issues permanecem no GitHub quando o repositório é espelhado

O que fazer: mantenha o backlog no GitHub e trate o Origin como o lugar do código e do PR, não do planejamento

Sintoma: o pipeline não roda depois de mexer no repositório espelhado

Causa: a configuração de CI continua no GitHub, e workflows do GitHub Actions e secrets não são sincronizados para o Origin

O que fazer: siga configurando CI e segredos no GitHub, sem tentar recriar nada do lado do Origin

Sintoma: você instalou um app do Origin e ele age como se o repositório não existisse

Causa: apps do Origin não alcançam repositório espelhado do GitHub. O Origin deixa esses repositórios de fora de instalações, de tokens de acesso de instalação e de entregas de webhook

O que fazer: automação que depende de webhook e de token de instalação continua morando no GitHub, e o Origin fica com a parte de leitura e revisão

Resumindo o mapa:

Tome cuidado com o combinado do time: definir ANTES de espelhar o que continua no GitHub evita aquela reunião longa pra descobrir por que o bot parou de comentar 😛

Como parar de sincronizar com o GitHub

Toda ferramenta nova merece um plano de saída, e aqui ele existe

A documentação do Cursor descreve o caminho assim:

1. Abra Settings > General
2. Vá até a Danger Zone
3. Selecione Detach from GitHub

Agora a parte que você precisa ler duas vezes: isso encerra a sincronização e converte a cópia do Origin em repositório independente

O Origin vira a fonte da verdade e os pushes deixam de fluir para o GitHub

Erro comum deste passo: tratar o detach como uma pausa reversível, tipo desligar e ligar de novo

O efeito é troca de fonte da verdade, não um botão de soneca… então essa decisão é de time, não de impulso

Conclusão

A revisão não fica partida em dois lugares, e é isso que a sincronização entre Cursor e GitHub resolve na prática

Os dois lados escrevem no mesmo PR: comentário do Cursor vai pro GitHub, reação e resposta do GitHub voltam pro Cursor em segundos, e o GitHub segue como fonte da verdade no repositório sincronizado

O que não atravessa também está claro: issues, GitHub Actions e secrets continuam do lado de lá

Próximo passo? Espelha um repositório de baixo risco pela aba Codebase e roda UMA revisão de teste com metade do time em cada ferramenta

Se a conversa chegar inteira nos dois lados, aí sim você move o fluxo principal pro Origin, com o combinado do que fica no GitHub já fechado antes

Essa é a única forma honesta de saber se o Origin cabe no seu time: testando com PR de verdade, não no achismo 🙂

até o próximo post! 😀