Como usar o Codex Cloud com GitHub e revisar um pull request

Para usar o Codex Cloud com GitHub, conecte o repositório, prepare e publique um ambiente e só então inicie uma tarefa. Depois, revise as alterações e os testes antes de aprovar o pull request. O acesso depende do plano e das permissões do workspace.

Antes de conectar o GitHub

A OpenAI lista o Codex Cloud nos planos Plus, Pro, Business e Enterprise/Education, mas não para acesso por chave de API. As permissões do workspace também se aplicam. Conversas na nuvem e mensagens locais compartilham a franquia de uso do plano; tarefas na nuvem podem consumir mais, conforme o modelo e a tarefa. A tabela de recursos e uso da OpenAI reúne essas condições.

Separe o repositório que pretende usar e confirme que você tem acesso a ele e ao workspace. Ao criar o ambiente, conecte o GitHub se o Codex solicitar.

Prepare e publique o ambiente

1. Selecione o repositório. No fluxo documentado, acesse Work in → Cloud → Select environment → Create environment, escolha os repositórios do GitHub e selecione Get started. O Codex inspeciona o projeto e prepara dependências, ferramentas e testes.
2. Revise a configuração. Confira o relatório de preparação, os comandos, as versões de runtime e as dependências. Resolva informações ou acessos pendentes antes de publicar. A documentação de ambientes na nuvem da OpenAI descreve esse processo.
3. Publique o ambiente. A publicação cria um ponto de partida reutilizável para novas tarefas; não implanta a aplicação. Cada tarefa nova começa em um workspace isolado baseado nesse ambiente. Se mudar a configuração, edite-a, teste-a e publique-a de novo. Tarefas já abertas mantêm seus próprios arquivos e alterações, inclusive as que ainda não foram commitadas.

Peça uma mudança que possa ser revisada

Comece solicitando uma explicação do repositório; depois, descreva a mudança e o resultado esperado. No exemplo de JavaScript de proflead, a tarefa tratava de limites em buscas. Para um vetor de três itens, por exemplo, os índices válidos são 0, 1 e 2. O autor recomenda especificar casos de regressão, comandos de teste e limites para evitar mudanças não relacionadas ou novas dependências. O passo a passo de proflead atribui essas observações ao exemplo dele.

Uma solicitação delimitada dá ao revisor algo concreto para conferir: o comportamento esperado, os arquivos alterados e os testes pertinentes.

Revise o diff e o pull request

Inspecione os arquivos alterados e o diff, e confira tanto as entradas dos testes quanto os resultados. Abra o link do pull request no GitHub e verifique a branch de origem, a branch de destino, a descrição e os resultados da integração contínua (CI). Reexecute os testes relevantes do projeto antes de aceitar as mudanças. A ausência de conflitos com a branch-base não dispensa a revisão do comportamento.

Faça checkout da branch localmente

Se quiser continuar a revisão no seu computador, confira primeiro se há trabalho local não commitado. proflead recomenda verificar o estado e o remoto, buscar as referências e então acompanhar a branch do pull request:

git status
git remote -v
git fetch origin
git switch --track origin/your-task-branch

Substitua your-task-branch pelo nome da branch do pull request e rode os testes no checkout local. A sequência de comandos e o cuidado com alterações locais fazem parte do fluxo descrito por proflead.

Recursos da VM e estado da tarefa

A OpenAI especifica recursos padrão diferentes conforme o grupo de planos. Isso ajuda a avaliar se o ambiente atende às necessidades do projeto; para comparar execuções, mantenha iguais a configuração da VM e as condições do teste. Os recursos padrão e as regras de estado da tarefa constam na documentação da OpenAI.

O estado salvo da VM pode ser recuperado por até sete dias após o início do último turno da tarefa ou a retomada dela. Esse estado não substitui o controle de versão: mantenha o código e as mudanças importantes no Git.

Credenciais e acesso à rede

A documentação da OpenAI distingue variáveis de ambiente, entregues diretamente aos programas, de segredos de rede, para os quais o programa recebe um marcador e um proxy substitui a credencial real.

Permitir um destino não fornece credenciais nem concede acesso ao serviço. Configure a autenticação separadamente. Se a tarefa precisar de uma rede privada, a conexão VPN do notebook não é herdada automaticamente: a OpenAI documenta uma opção configurada à parte com suporte a Tailscale, que exige coordenar as regras de acesso da VPN com as configurações de rede do ambiente. A documentação da OpenAI explica os segredos de rede e a VPN.

Os ambientes na nuvem não oferecem uso de navegador ou computador e não suportam GitLab nem GitHub Enterprise Server auto-hospedado. Se a tarefa depender dessas funções ou de serviços privados, considere esses requisitos ao escolher o fluxo.