Segurança do GitHub Copilot: riscos, controlos e boas práticas

O que é o GitHub Copilot e porque é que muda o modelo de segurança?

O GitHub Copilot é o assistente de código de IA do GitHub. A maioria das pessoas conhece-o como completação inline no VS Code, no Visual Studio ou num IDE da JetBrains, onde sugere as próximas linhas à medida que escreve. Mas o Copilot é agora uma família de superfícies: sugestões inline, o Copilot Chat (faça perguntas sobre um ficheiro, um repositório ou um erro), o modo de agente no IDE (lê, edita e corre por todo o workspace), o Copilot CLI, a revisão de código do Copilot em pull requests, e o agente de código do Copilot no GitHub.com, que pega numa issue atribuída e a trabalha autonomamente até um pull request.

Essa progressão é exatamente o que quebra o velho modelo de segurança. Uma completação inline é um rascunho: um humano lê o texto cinzento e carrega em Tab ou ignora-o, e o raio de impacto de uma sugestão má é um bloco de código que um programador ainda teve de aceitar. As superfícies mais recentes executam ações. O Copilot Chat puxa conteúdo do repositório e contexto externo para responder. O modo de agente edita ficheiros e corre comandos. O agente de código lê uma issue (que um estranho pode ter criado), reúne contexto, escreve código e abre um pull request, tudo sem um humano a ler cada passo. A superfície de ataque já não é apenas "que código sugeriu o modelo". É "o que pode este assistente ler, escrever e sobre o que pode agir, e quem consegue influenciar as suas instruções".

“

Uma completação é um rascunho que um humano escolhe aceitar. Uma ação de agente é algo que já aconteceu. O modelo de segurança tem de passar de rever rascunhos para restringir ações.

Há uma segunda mudança, e tem que ver com a velocidade. O pull request tornou-se a casa da segurança de aplicações porque assentava na cadência humana: uma pessoa abrandava, lia o diff e só depois fazia o merge. O Copilot, sobretudo em modo de agente e de agente de código, não corre à cadência humana. Pode entregar mais código numa tarde do que um revisor lê numa semana, e uma parte significativa do código novo é agora assistida por IA. Quando isso acontece, o diff deixa de ser um ponto de controlo e torna-se um registo de decisões já tomadas. Qualquer controlo que só atue no pull request está a rever o histórico, não a preveni-lo.

Para a maioria das equipas, a pergunta prática não é se o Copilot tem proteções nativas. Tem-nas, e o tier empresarial em particular está bem pensado. A pergunta é se essas proteções chegam para o uso do dia a dia. A resposta honesta é não, não por si só. Os controlos reduzem o risco; a adoção segura continua a depender de configuração, higiene de segredos, disciplina de dependências, revisão humana e um controlo que alcança o agente enquanto ele escreve.

Como funciona o modelo de segurança do GitHub Copilot

O modelo de segurança do Copilot assenta em quatro ideias: manter ficheiros sensíveis fora do contexto do modelo, apanhar as coisas perigosas que ele possa emitir (segredos, correspondências com código público), verificar o código que gera, e deixar as organizações definir a política centralmente. Na prática, isso surge como um punhado de controlos, a maioria mais forte nos planos Business e Enterprise.

É uma base genuinamente boa, e vários destes controlos (exclusões de conteúdo, proteção de push, indemnização de PI) são coisas que nenhum assistente de IDE oferecia uma geração atrás. A armadilha é lê-los como uma fronteira de segurança acabada. As exclusões de conteúdo só cobrem as superfícies que as suportam, e as superfícies agênticas são exatamente as que elas saltam. O filtro de código público apanha correspondências literais, não código conceptualmente semelhante. A análise de segredos apanha padrões conhecidos e genéricos, não todos os formatos personalizados ou ofuscados. A análise de código é assistiva, não a decisora final. Cada controlo desta lista tem um limite documentado, e a próxima secção é sobre o que acontece quando se apoia demasiado neles.

Os 6 principais riscos de segurança no GitHub Copilot

Os riscos abaixo não são teóricos. Correspondem a investigação publicada, avisos documentados e ao OWASP Top 10 para Aplicações LLM. Os números que os enquadram são os mesmos que todas as equipas de AppSec citam agora.

~40%

dos programas completados pelo Copilot eram vulneráveis no estudo 'Asleep at the Keyboard' da Cornell / NYU

+40%

mais segredos vazados em repositórios que usam Copilot do que em repositórios públicos típicos (GitGuardian)

#1

injeção de prompt, o principal risco LLM pelo 3.º ano consecutivo (OWASP LLM01)

1. Sugestões de código inseguro

O Copilot aprende com código público, e código público está cheio de padrões inseguros, por isso reproduz-nos. O estudo marcante "Asleep at the Keyboard?" de investigadores da Cornell e da NYU gerou 1 689 programas em cenários extraídos do Top 25 CWE do MITRE e concluiu que cerca de 40% deles eram vulneráveis. As falhas eram as suspeitas do costume: desserialização insegura, validação de input fraca ou ausente, autenticação e autorização impróprias, SQL construído a partir de concatenação de strings.

Este é o risco lento e estrutural. Nenhuma sugestão isolada parece alarmante, e cada uma compila e passa o teste do caminho feliz. Mas um assistente que gera milhares de linhas por dia reproduz fraquezas subtis mais depressa do que elas surgem por si próprias, e um programador a mover-se à velocidade do Copilot é menos provável que escrutine código que parece plausível do que código que escreveu à mão. O quadro mais amplo é consistente: estudos independentes continuam a concluir que uma grande fatia do código gerado por IA é insegura. O Copilot não é unicamente mau aqui, é representativo da categoria.

2. Fuga de segredos

O Copilot agrava o problema dos segredos em duas direções. Primeiro, vaza mais: a investigação da GitGuardian concluiu que os repositórios que usam Copilot vazam cerca de 40% mais segredos do que os repositórios públicos típicos, em parte porque produção de código mais rápida significa commits acidentais mais rápidos. Segundo, propaga: se um segredo estiver no contexto que o modelo consegue ver (um ficheiro .env, um bloco de config, uma credencial hard-coded num ficheiro próximo), o Copilot pode reutilizar ou expor esse valor numa sugestão, numa resposta de Chat ou em código gerado.

A análise de segredos e a proteção de push são os recursos de reserva previstos, e ajudam, mas são baseadas em padrões. Apanham de forma fiável formatos de token bem conhecidos (uma chave de cloud reconhecível, um token de API de fornecedor) e bem menos de forma fiável formatos de segredo personalizados, internos ou ofuscados. Uma chave de assinatura caseira ou um token de serviço interno que não corresponda a um padrão conhecido pode passar diretamente, ser sugerido pelo Copilot num novo ficheiro, e aterrar no repositório antes de alguém reparar.

3. Alucinação de pacotes e cadeia de suprimentos (slopsquatting)

Como todo o assistente baseado em LLM, o Copilot pode sugerir com confiança um pacote que não existe. Inventa um nome plausível (o tipo de nome que uma biblioteca real teria), recomenda instalá-lo e escreve um import para ele. Por si só, isto é apenas um build avariado. O perigo é a reviravolta adversarial que a indústria chama slopsquatting: os atacantes vigiam estes nomes alucinados, registam-nos no registo público com payloads maliciosos, e esperam. O próximo programador cujo Copilot alucina o mesmo nome instala malware funcional.

O fluxo de trabalho de desenvolvimento torna-se o vetor de ataque. Um confiante "instala isto e importa-o" transforma um passo de configuração rotineiro em roubo de credenciais ou numa backdoor, e a sugestão carrega a mesma autoridade que todas as sugestões corretas que a precederam. As dependências reais também não são seguras por omissão: o Copilot vai de bom grado buscar uma versão desatualizada ou vulnerável de uma biblioteca genuína se for isso que viu mais no treino.

4. Privacidade de dados, PI e licenciamento

Duas preocupações relacionadas residem aqui. A preocupação de privacidade é o que acontece ao código que o Copilot vê: consoante o plano e as definições, os prompts e as sugestões podem ou não ser retidos ou usados para melhorar os modelos, razão pela qual existem planos Business e Enterprise com compromissos mais estritos de tratamento de dados, e por que as exclusões de conteúdo importam para ficheiros sensíveis. A preocupação de PI é a inversa: como o Copilot treinou em código público (muitas vezes licenciado), uma sugestão pode assemelhar-se a material protegido por direitos de autor, e usá-la pode expô-lo a uma reivindicação de licença ou de direitos de autor.

As mitigações do GitHub são reais mas delimitadas. O filtro de deteção de duplicados reduz as correspondências literais, e a indemnização de PI oferece proteção legal, mas a indemnização é condicional: aplica-se a planos pagos específicos, exige que o filtro de duplicados esteja ligado, e cobre a sugestão apenas se a usar sem modificações. No momento em que um programador edita uma sugestão (que é o fluxo de trabalho normal) ou corre com o filtro desligado, a proteção legal estreita-se. A FOSSA e outros recomendam tratar a saída do Copilot como necessitando da mesma revisão de licença e proveniência que aplicaria a qualquer código de terceiros.

5. Injeção de prompt no Copilot Chat e no agente de código

A injeção de prompt é o risco que define as ferramentas de código agênticas, e é o risco LLM número um da OWASP pelo terceiro ano consecutivo. Um atacante esconde instruções em algo que o assistente lê, e o assistente segue-as, anulando o comportamento previsto. A exposição do Copilot cresceu com as suas superfícies: o Chat lê conteúdo do repositório e contexto recuperado, e o agente de código lê issues e comentários que um contribuidor externo pode escrever.

A forma perigosa é indireta. Não cola um prompt malicioso; uma instrução escondida vive num ficheiro, numa issue, num comentário de pull request ou na saída de uma ferramenta. A própria documentação do GitHub sobre riscos e mitigações do agente de código é franca quanto a isto e descreve defesas: retira caracteres escondidos e conteúdo de comentários HTML antes de passar o input do utilizador ao agente, restringe o acesso à internet do agente para limitar a exfiltração de dados, e mantém cada commit do agente de código auditável e co-autorado pelo humano que o desencadeou. Ainda assim, investigadores demonstraram injeção através de conteúdo de repositório e de comentários contra o Copilot e os seus pares, e pelo menos um problema de injeção de prompt no Copilot (rastreado como CVE-2025-53773) atingiu severidade de execução remota de código antes da remediação. O padrão a recordar: um modelo de linguagem não consegue separar de forma fiável uma instrução de confiança de uma maliciosa escondida em dados.

6. Confiança excessiva sem revisão

O risco mais silencioso é cultural. As sugestões do Copilot são fluentes, bem formatadas e confiantes, e essa fluência convida as equipas a tratá-las como prontas para produção. Código que receberia escrutínio cuidadoso se um engenheiro júnior ou um terceiro desconhecido o submetesse é deixado passar porque "o Copilot escreveu-o". O agente de código intensifica isto: abre um pull request de aparência acabada, e um pull request de aparência acabada é psicologicamente mais difícil de rejeitar do que um rascunho tosco.

A confiança excessiva é o que transforma os outros cinco riscos de latentes em explorados. Uma sugestão insegura só é entregue se ninguém a rever. Um segredo vazado só persiste se ninguém apanhar o diff. Um pacote alucinado só executa se alguém correr a instalação sem verificar. O controlo de maior alavancagem para o Copilot é também o menos técnico: um humano que continua a ler código gerado por IA com o mesmo ceticismo que daria a qualquer outro contribuidor.

O que a segurança nativa do GitHub Copilot cobre, e o que não cobre

Os controlos nativos são reais, e ajuda ser preciso quanto à linha entre o que tratam e o que deixam para si.

Leia a coluna da direita como o verdadeiro trabalho. Os controlos nativos são o chão: impedem que um erro honesto se torne um desastre, e no tier empresarial são um chão forte. Não foram concebidos para travar um adversário determinado que controla os inputs do assistente, e o GitHub não afirma que foram. Tudo o que transforma "o Copilot está ativado" em "o Copilot está governado" vive nas práticas que se seguem.

Boas práticas para proteger o GitHub Copilot

Estas nove práticas fecham a lacuna entre a base nativa e uma postura de segurança real. Nenhuma é exótica; a disciplina está em aplicá-las de forma consistente numa equipa que se move depressa.

1. Configure as exclusões de conteúdo e o .copilotignore de forma deliberada. Exclua segredos, ficheiros de credenciais, configuração sensível e dados regulados ao nível do repositório e da organização, de modo que nunca informem completações, Chat ou revisão de código. Faça com que os programadores adicionem um .copilotignore para caminhos sensíveis locais no VS Code. De forma crítica, lembre-se da lacuna: as exclusões de conteúdo não cobrem o Copilot CLI, o agente de código nem o modo de agente no Chat, por isso não deixe um segredo em lado nenhum que essas superfícies possam ler só porque existe uma regra de exclusão.

2. Mantenha os segredos fora do contexto e ligue a proteção de push. Use um gestor de segredos e injete em tempo de execução, de modo que credenciais em texto simples nunca vivam em ficheiros que o Copilot consegue ver. Ative a análise de segredos com proteção de push em toda a organização, e adicione padrões personalizados para os seus formatos de segredo internos e caseiros, porque os detetores por omissão vão falhá-los. Se um segredo alguma vez aparecer numa sugestão ou num registo, rode-o de imediato e investigue como entrou no contexto.

3. Mantenha um humano no circuito de cada sugestão. Trate a saída do Copilot como um rascunho de um contribuidor desconhecido, não uma implementação acabada. Encaminhe todo o código gerado, incluindo os pull requests do agente de código, através de revisão humana obrigatória e testes automatizados, com escrutínio extra na autenticação, validação de input, desserialização e caminhos privilegiados. Resista ao apelo do pull request de aparência acabada: reveja-o como se um estranho o tivesse aberto.

4. Corra SAST e análise de código como um gate, não uma sugestão. Ative a análise de código (CodeQL) e use o Copilot Autofix para acelerar a remediação, mas trate as descobertas de segurança como um gate de merge, não conselho opcional. Um SAST independente no CI apanha os padrões inseguros que o Copilot reproduz (desserialização insegura, injeção, autenticação fraca) antes de chegarem a uma branch de release.

5. Governe dependências e defenda-se contra a alucinação de pacotes. Restrinja as instalações a registos de confiança ou mirrors internos, exija aprovação para novas dependências e analise tudo com análise de composição de software. Antes de adicionar qualquer pacote que o Copilot sugira, verifique que existe de facto e é a biblioteca genuína e mantida, não um nome plausível que um atacante possa ter registado. Fixe as versões e vigie o Copilot a ir buscar versões desatualizadas e vulneráveis de pacotes reais.

6. Mantenha o filtro de código público ligado e reveja a proveniência. Ative o filtro de deteção de duplicados em toda a organização, de modo que as sugestões que correspondem a código público sejam bloqueadas, o que é também uma pré-condição para a indemnização de PI. Para qualquer bloco substancial que o Copilot produza, aplique a mesma revisão de licença e proveniência que daria a código de terceiros, e documente essa revisão para código que é entregue num produto.

7. Trate todo o conteúdo de repositório e issue como input não confiável. Como o Chat e o agente de código leem ficheiros, issues e comentários que estranhos podem escrever, assuma que qualquer deles pode conter uma instrução injetada. Limite quem pode atribuir trabalho ao agente de código, delimite o seu acesso a repositório e ferramentas ao mínimo, mantenha em vigor o seu acesso restringido à internet, e reveja a sua saída sabendo que pode ter sido orientada. Não dê a um agente que lê issues não confiáveis acesso a credenciais de produção.

8. Use os controlos empresariais de dados e política. Nos planos Business ou Enterprise, defina o tratamento de dados para que os prompts e as sugestões não sejam retidos nem usados para treino onde a sua política o exija, imponha SSO, e ligue os registos de auditoria. Use a política ao nível da organização para padronizar que funcionalidades do Copilot estão ativadas, quem pode usar o agente de código, e que repositórios estão no âmbito, de modo que a postura de segurança não dependa das definições locais de cada programador.

9. Defina a política por repositório e sensibilidade do ambiente. Classifique os repositórios (público, interno, regulado, produção) e aplique controlos mais estritos aos sensíveis: exclusões de conteúdo mais amplas, revisão obrigatória, sem acesso do agente de código, regras de dependências mais apertadas. Para sistemas críticos, mantenha o Copilot longe de qualquer caminho direto para credenciais de produção, e documente a política para que os programadores saibam onde a assistência de IA é permitida e sob que restrições.

Onde os controlos nativos param: proteger o agente no momento do prompt

Percorra de novo os riscos e surge um padrão. As exclusões de conteúdo, a análise de segredos, a análise de código e a revisão atuam todas sobre o que o assistente já produziu, ou sobre inputs e saídas nas margens do ciclo. Concentram-se em torno do pull request, porque é aí que a AppSec sempre viveu. Mas o PR só foi alguma vez um ponto de controlo porque um humano o lia, e à cadência do agente ninguém o lê de ponta a ponta.

O lugar para impor uma regra já não é o diff; é o prompt, antes de a linha insegura ser escrita. Qualquer regra que queira que o assistente siga, o seu helper de autenticação, o seu tipo de dinheiro, a sua política de validação de input, tem de estar nas suas mãos no momento em que escreve, não à espera num scanner que chega quando o código já está em disco e o Copilot já passou para a sugestão seguinte.

É essa a camada que o VibeDefend acrescenta. É uma CLI npm gratuita que instala em cerca de cinco segundos e liga o VS Code Copilot (mais o Claude Code, o Cursor, o OpenAI Codex e o Windsurf) a camadas de governação que correm dentro do ciclo do agente.

npx -y @cybedefend/vibedefend@latest installEscolher EU ou US, confirmar VS Code CopilotColocar .cybedefend/config.json no repositórioO próximo prompt está governado

Regras de Negócio As convenções no seu repositório que nunca foram escritas (usar Decimal128 para dinheiro, a autorização passa por requireOwner). O VibeDefend extrai-as da forma como a sua equipa já programa e carrega-as no contexto do Copilot antes de cada edição. Regras de Segurança OWASP Top 10, SOC 2, RGPD e ISO 27001, carregadas no dia em que instala. O assistente lê o lembrete aplicável antes de escrever, de modo que o requisito do framework se torna parte do código em vez de uma caixa a marcar no momento da auditoria. Action Guard Chamadas destrutivas (um sudo rm -rf, uma leitura crua de uma variável de ambiente com forma de segredo, um psql ad-hoc contra um host de produção) são intercetadas antes de dispararem. Avisar ou bloquear conforme a regra, com cada interceção no registo de auditoria. Live Findings Cada resultado dos seus scanners (SAST com alcançabilidade, SCA, segredos, IaC e CI/CD) está ao vivo no contexto do agente, de modo que ele não só escreve código seguro, como tria e corrige as vulnerabilidades que já tem.

Uma ressalva honesta especificamente para o Copilot: o VS Code Copilot recebe as camadas de MCP e de regras (as Regras de Negócio e as Regras de Segurança chegam ao contexto do agente no momento do prompt), mas os Action Guards estão ainda pendentes do lado do GitHub, por isso a interceção de chamadas destrutivas ainda não está disponível para o Copilot da forma como está para os agentes em estilo CLI. As camadas de regras, que é onde está a maior parte da alavancagem de segurança, funcionam hoje.

Crucialmente, nada do seu código atravessa a rede. As decisões acontecem localmente, ao lado do agente; apenas metadados de governação estruturados (a regra que disparou, o caminho do ficheiro, a severidade, um timestamp) chegam ao backend. Os tenants da EU e dos US são fisicamente separados, e a região é escolhida no momento da instalação. É esse modelo de privacidade que permite a um controlo estar tão perto do código sem se tornar, ele próprio, um risco de exfiltração de dados.

Isto não é um substituto das práticas acima. É a camada em falta que elas assumem existir: a que coloca as suas regras nas mãos do assistente no momento do prompt, de modo que a linha insegura seja reescrita antes de alguma vez ser sugerida, em vez de apanhada três fases depois por um scanner que lê um diff que ninguém teve tempo de ler. As exclusões de conteúdo decidem o que o Copilot pode ler; o VibeDefend molda o que ele escreve, em primeiro lugar.

Perguntas frequentes

O GitHub Copilot é seguro?

O GitHub Copilot é razoavelmente seguro quando os seus controlos estão configurados, e arriscado quando são assumidos. Nos planos Business e Enterprise, as exclusões de conteúdo, a análise de segredos com proteção de push, o filtro de código público, a indemnização de PI e a análise de código com Autofix previnem uma grande classe de acidentes. O risco residual vem do código que sugere (cerca de 40% das completações do Copilot eram vulneráveis no estudo da Cornell e da NYU), dos inputs (injeção de prompt através de repositórios, issues e comentários) e da cultura (confiar em excesso em saída fluente). Trate-o como um assistente capaz que precisa de configuração, revisão humana e um controlo no momento do prompt, não como uma ferramenta que é segura logo à partida.

O GitHub Copilot vaza segredos?

Pode, de duas formas. A GitGuardian concluiu que os repositórios que usam Copilot vazam cerca de 40% mais segredos do que os repositórios públicos típicos, em grande parte porque produção de código mais rápida significa commits acidentais mais rápidos. O Copilot também pode propagar um segredo que já está no contexto que consegue ver, expondo-o numa sugestão ou numa resposta de Chat. A análise de segredos e a proteção de push são os recursos de reserva e apanham formatos de token bem conhecidos de forma fiável, mas segredos personalizados, internos ou ofuscados podem escapar. Mantenha os segredos fora do contexto com um cofre, ative a proteção de push, adicione padrões de deteção personalizados, e rode tudo o que apareça num registo.

O Copilot treina com o meu código ou armazena-o?

Depende do seu plano e definições. Os planos Business e Enterprise do GitHub oferecem compromissos mais estritos de tratamento de dados, incluindo opções para não reter prompts e sugestões nem usá-los para melhorar modelos, razão pela qual esses tiers existem para organizações com requisitos de confidencialidade. Os planos individuais tiveram historicamente valores por omissão diferentes. Para código sensível, escolha um plano e uma configuração que correspondam à sua política de tratamento de dados, use exclusões de conteúdo para manter ficheiros específicos totalmente fora do contexto, e reveja os termos atuais de retenção e treino do GitHub antes de adotar o Copilot em trabalho regulado.

O que são as exclusões de conteúdo e o .copilotignore?

As exclusões de conteúdo são uma definição do lado do servidor, configurável por administradores de repositório, donos de organização e donos de empresa, que dizem ao Copilot para ignorar ficheiros nomeados, de modo que não informem completações, Chat ou revisão de código. O .copilotignore é um mecanismo separado, do lado do cliente, no VS Code, que permite a um programador individual excluir ficheiros localmente. Ambos são úteis para manter segredos e caminhos sensíveis fora do contexto do modelo. A ressalva importante é a cobertura: as exclusões de conteúdo não se aplicam ao Copilot CLI, ao agente de código nem ao modo de agente no Chat dentro dos IDEs, por isso não assuma que uma regra de exclusão o protege nas superfícies agênticas.

O Copilot gera código inseguro?

Sim, com frequência suficiente para importar. O estudo "Asleep at the Keyboard?" da Cornell e da NYU gerou 1 689 programas em cenários extraídos do Top 25 CWE do MITRE e concluiu que cerca de 40% eram vulneráveis, com falhas como desserialização insegura, validação de input fraca e autenticação imprópria. O Copilot reproduz os padrões inseguros comuns no código público com que aprendeu. A mitigação é revisão independente e SAST como um gate, mais um controlo no momento do prompt que carrega as suas regras de segurança antes de a sugestão ser escrita.

A indemnização de PI do Copilot chega para cobrir o risco legal?

Ajuda, mas é condicional, não uma garantia geral. A indemnização de PI da Microsoft defende os clientes contra reivindicações de direitos de autor decorrentes de uma sugestão não modificada do Copilot, mas apenas em planos pagos qualificados, apenas quando o filtro de deteção de duplicados está ativado, e apenas para sugestões usadas sem modificações. O fluxo de trabalho normal do programador (editar uma sugestão antes de a comprometer) e correr com o filtro desligado estreitam ambos essa cobertura. Trate a indemnização como um recurso de reserva, mantenha o filtro de código público ligado, e aplique a mesma revisão de licença e proveniência a saída substancial do Copilot que daria a qualquer código de terceiros.

Em que é que a segurança do Copilot difere da do Claude Code, Cursor ou Codex?

Os fundamentos são partilhados (privilégio mínimo, higiene de segredos, revisão humana, análise de dependências), mas as superfícies de destaque diferem. Os problemas distintivos do Copilot são sugestões inseguras e fuga de segredos em escala, mais a nova superfície de injeção do seu Chat e agente de código. A superfície distintiva do Claude Code é a integração profunda com MCP e shell; a do Cursor tem sido o Workspace Trust desativado por omissão; a do Codex tem sido injeção de comandos e incidentes de cadeia de suprimentos. Cobrimos cada agente no seu próprio guia: Claude Code, Cursor e OpenAI Codex.