Codex CLI ou Cloud: configure a nuvem e acompanhe pelo celular

Antes de sair da mesa, passe um teste que está falhando para o Codex e deixe a tarefa seguir com o notebook desligado. Na escolha entre Codex CLI e Codex Cloud, a nuvem oferece um ambiente reutilizável para o projeto, com acesso pela web e pelo celular para acompanhar o trabalho, orientar os próximos passos e revisar o resultado.

O que mudou em 30 de setembro?

Com o relançamento, ficou mais fácil repetir tarefas na nuvem: o repositório, as dependências, os scripts e as configurações podem estar prontos antes de começar a próxima tarefa. Você pode acompanhar o andamento e orientar o Codex pelo celular ou por outro computador. A experiência já conhecida do aplicativo para desktop também chega à web e ao celular. Essas são as mudanças do anúncio da OpenAI de 30 de setembro de 2026.

Pense no ambiente como uma oficina preparada. As ferramentas e os materiais ficam prontos; cada tarefa recebe sua própria bancada. Uma dependência é um pacote de software de que o projeto precisa. O repositório é o conjunto de arquivos de código com controle de versão.

Na prática, você deixa de depender de manter sua máquina ligada para o trabalho de programação continuar. O Codex Cloud roda em computadores gerenciados pela OpenAI. Crie e publique o ambiente no aplicativo para desktop ou na web e depois use-o nos dispositivos compatíveis. Cada tarefa tem seus próprios arquivos de trabalho. O guia de ajuda da OpenAI sobre o Cloud explica essa separação.

Minha recomendação: comece com uma tarefa pequena cujo resultado você consiga verificar. Um agente em segundo plano ajuda mais quando você já definiu o que precisa acontecer para considerar o trabalho correto.

Quais planos dão acesso ao Codex Cloud?

O acesso à nuvem exige uma conta elegível dos planos Plus, Pro, Business, Enterprise, Healthcare ou Education, conforme a liberação do recurso e as configurações do workspace. Free e Go incluem acesso ao Codex, mas não ao Codex Cloud. Quem tem acesso Guest ou K-12, ou uma licença Enterprise apenas para visualização, não pode criar ambientes na nuvem. A disponibilidade por plano informada pela OpenAI é a fonte dessas diferenças.

Os preços acima vêm da página atual de preços do Codex, consultada em 7 de outubro de 2026. A elegibilidade para a nuvem não significa que todos os membros possam usar todos os controles.

Como as tarefas na nuvem consomem os limites do plano?

No lançamento, os ambientes padrão não têm uma cobrança separada pela máquina virtual. Máquina virtual é o computador remoto que executa a tarefa. O uso do modelo continua consumindo os limites normais do Codex e os créditos ou a cobrança aplicáveis. Planos com saldo compartilhado podem dividir o consumo entre Codex, ChatGPT Work, ChatGPT for Excel e Workspace Agents, quando disponíveis; contratos Enterprise baseados em tokens cobram em USD, em vez de créditos. As regras de uso da OpenAI detalham essa contabilização.

Mensagens locais e conversas na nuvem compartilham os limites do seu plano, e também pode haver limites semanais. Tarefas na nuvem podem consumir mais do que mensagens locais. As estimativas de mensagens da página de preços se referem ao uso local; elas não garantem uma quantidade de tarefas na nuvem. Usuários elegíveis de Plus e Pro podem comprar créditos extras sem mudar de plano. Consulte o painel de uso para ver os limites atuais e quando eles são renovados. A documentação de preços e uso do Codex explica as variáveis.

Se você já paga por um plano elegível, teste uma tarefa com escopo definido antes de comprar mais capacidade. A conta para o negócio é tempo de trabalho manual poupado menos o tempo gasto com manutenção da configuração, orientação e revisão, contabilizando à parte os créditos adicionais. Tirar a tarefa do notebook só compensa se esse saldo melhorar.

Para uma comparação mais ampla entre assinatura e API, veja Preços do Codex em 2026. O Cloud exige login com o ChatGPT; uma sessão local da CLI com chave de API segue a cobrança separada da API. As opções de autenticação explicam a diferença.

Como usar o Codex com um ambiente reutilizável na nuvem

Prepare um projeto cujos testes rodem de forma confiável antes de delegar uma mudança maior. Siga a configuração atual de ambientes na nuvem, em vez do fluxo antigo, legado.

1. Conecte o repositório. Na web ou no aplicativo para desktop, escolha Work in > Cloud > Select environment > Create environment. Selecione os repositórios do GitHub e conecte o GitHub, se solicitado.
2. Prepare o projeto. Selecione Get started. Deixe o Codex inspecionar, instalar e testar. Informe o que estiver faltando e as versões necessárias.
3. Revise o script de configuração. Install script registra a preparação das dependências; Start skill registra a inicialização dos serviços e a verificação de que estão prontos. Ajuste a configuração pela conversa.
4. Configure os valores. Selecione Manage ao lado das variáveis de ambiente ou dos segredos de rede. Para um segredo de rede, informe a chave, o valor e os domínios permitidos.
5. Defina o acesso à internet. Ative Allow Codex to access internet, se necessário. Escolha Package managers ou Custom domains only e adicione os hosts necessários. All (unrestricted) permite acesso mais amplo.
6. Publique e comece. Revise os arquivos, as configurações e as verificações. Salve e selecione Publish. Depois de Environment published, inicie uma nova tarefa. Para mudar a configuração mais tarde, use Edit e Republish.

Na conversa de preparação, informe ao Codex os comandos reais de instalação e teste do projeto, a versão necessária do runtime e os serviços usados. Peça que ele relate o que passou e o que não conseguiu verificar. Essas são sugestões de instruções, não um script universal de configuração.

No primeiro experimento, eu usaria dados de teste sintéticos e o acesso mais restrito aos serviços que ainda permita reproduzir a tarefa. Se o download de um pacote falhar, investigue separadamente o hostname e a autenticação antes de ampliar o acesso à internet.

Três boas tarefas para começar

Escolha uma tarefa com ponto de partida claro, escopo pequeno e evidências que você possa conferir depois. Os exemplos abaixo são sugestões de instruções que você pode adaptar ao seu repositório.

Corrigir um teste que está falhando

Se uma falha reproduzível está impedindo um fundador de lançar uma versão, vale delegar a investigação e uma correção pontual. Forneça o comando que falha e sua saída. Peça ao Codex que preserve o comportamento esperado, explique a causa e informe as verificações que executou.

Uma instrução útil:

Reproduza este teste que está falhando com o comando documentado no projeto. Encontre a causa e faça a menor correção adequada. Não torne a asserção menos rigorosa só para fazer o teste passar. Execute o teste específico e os testes relacionados que forem relevantes. Resuma os arquivos alterados, os resultados e as incertezas que restaram.

Essa é minha primeira escolha porque oferece uma condição visível de antes e depois. Mesmo que o teste passe, é preciso revisar o diff: a mudança deve corrigir o comportamento, e não apenas esconder a falha.

Escrever uma migração

Para um desenvolvedor backend que está mudando o esquema do banco de dados, peça o arquivo de migração, uma análise de compatibilidade e testes com dados descartáveis. Uma migração é uma mudança versionada na estrutura do banco ou nos dados armazenados.

Uma instrução útil:

Escreva uma versão preliminar da migração para esta mudança de esquema, seguindo as convenções existentes no repositório. Explique a compatibilidade com a aplicação atual, as opções de rollback e os riscos de perda de dados. Teste com fixtures descartáveis quando possível. Não execute em produção nem faça o deploy.

O ganho é ter uma implementação que possa ser revisada e um plano de implantação mais claro. Escrever a migração não resolve questões como bloqueios em produção, duração do backfill ou convivência entre a versão antiga e a nova da aplicação. Deixe essas decisões com a pessoa responsável pela implantação.

Revisar um pull request

Para quem mantém um projeto e aguarda as mudanças de um colega, identifique a branch ou os commits do PR e sua branch de base. Peça apontamentos com evidências, mantendo os arquivos de trabalho sem alterações.

Uma instrução útil:

Analise este pull request em relação à branch de base. Foque em correção, autorização, compatibilidade e testes ausentes. Para cada apontamento, indique o local no arquivo, um cenário concreto de falha e as evidências que o sustentam. Não altere arquivos nem faça o merge do PR.

Se quiser a revisão integrada ao GitHub, a OpenAI documenta o uso de um repositório conectado e de um comentário @codex review no PR. A configuração da revisão no GitHub cobre esse fluxo. Code Review, Security Review e as integrações existentes com GitHub e Linear continuam usando Codex Cloud (Legacy) durante a transição. A página de ajuda do Cloud confirma essa diferença.

Pedir uma revisão dentro da nova tarefa na nuvem e usar a revisão automática do GitHub são fluxos separados.

Mais três tarefas que vale delegar

Depois da correção de um teste, eu colocaria estas tarefas na sequência, pela facilidade de delimitar o escopo e verificar o resultado. Cada uma é uma proposta de fluxo de trabalho, não um resultado já observado.

Inclua na instrução a condição para aceitar o resultado. “Melhore esta base de código” deixa decisões demais em aberto para funcionar como primeira tarefa.

Acompanhe e oriente o trabalho pelo celular

Volte à mesma tarefa quando quiser continuar o trabalho. Abrir uma nova tarefa cria um espaço de trabalho separado e não recupera as alterações sem commit da primeira. Faça commit do que for importante. Por padrão, a janela para recuperar a máquina virtual salva é de até sete dias após o início da última interação ou a retomada da tarefa; isso não é uma regra de retenção do histórico da conversa. As orientações da OpenAI sobre o estado das tarefas explicam o que fica salvo.

No celular, abra o Codex e escolha o ambiente publicado. Reabra a tarefa para acompanhar o andamento e enviar correções. A visão geral do Cloud descreve o fluxo entre dispositivos.

Boas mensagens de orientação resolvem uma decisão:

• “Mantenha a correção no parser e preserve a estrutura da resposta pública.”
• “Use uma fixture de banco de dados descartável no teste da migração.”
• “Pare depois da correção e do relatório de testes; deixe a implantação para revisão.”

Eu usaria o celular para resolver questões de escopo e conferir o andamento, depois revisaria um diff maior em uma tela grande. O acesso remoto a uma tarefa que roda no seu notebook ainda depende desse computador; ele não oferece a execução com o notebook desligado que o Cloud permite. A página de ajuda da OpenAI diferencia os dois casos.

Codex CLI ou Cloud: qual faz mais sentido?

Use a nuvem quando uma tarefa com escopo bem definido precisar continuar de forma independente. Use a CLI local quando o trabalho depender dos arquivos e das ferramentas de desenvolvimento que já estão na sua máquina.

A CLI pode inspecionar um repositório local, editar arquivos e executar ferramentas instaladas. Abra o diretório do projeto, execute codex e entre com o ChatGPT. Ela também pode delegar tarefas por codex cloud, então a interface em que você começa não determina onde o trabalho será executado. O guia da CLI explica as duas opções.

As escolhas abaixo são minhas recomendações.

Os ambientes atuais do Cloud não oferecem suporte ao uso de computador ou navegador, ao GitLab nem ao GitHub Enterprise Server hospedado em infraestrutura própria. As skills locais pessoais não são sincronizadas. As limitações atuais pesam mais na escolha do que uma preferência genérica pela nuvem.

Restrinja o acesso e revise o diff

Saiba o que o ambiente consegue acessar. Os domínios permitidos controlam os destinos de rede da máquina virtual; eles não concedem permissões nos serviços. Os segredos de rede do próprio ambiente também permitem acesso aos seus domínios. Os requisitos de Agent Security para Enterprise se aplicam junto com as configurações do ambiente. A configuração de rede e o Agent Security descrevem esses controles.

Escolha como fornecer as credenciais. Variáveis de ambiente diretas ficam disponíveis para os programas. Segredos de rede usam valores substitutos no proxy para destinos HTTPS aprovados na porta 443, durante a configuração e as tarefas, mantendo as credenciais reais fora dos processos e arquivos locais. A documentação de tratamento de segredos explica o mecanismo.

Eu deixaria credenciais de produção fora da primeira tarefa de programação e usaria acesso de desenvolvimento com escopo restrito. Antes do merge, leia o diff, confira a saída dos testes, inspecione as mudanças nas dependências e confirme se a correção corresponde ao pedido. Uma suíte de testes aprovada é uma evidência a avaliar, não um motivo para pular a revisão.

A elegibilidade de contas Healthcare não coloca o Cloud sob a cobertura do BAA da OpenAI, seu acordo para o tratamento de dados de saúde protegidos. A OpenAI orienta não processar informações de saúde protegidas no Codex Cloud. As restrições de dados do Cloud estabelecem esse limite.

Para os controles da equipe, veja Como configurar a segurança do Codex após o DevDay.

O que dá para criar a partir desse fluxo?

A oportunidade mais promissora é um kit de correção de falhas que bloqueiam releases para uma stack específica. Venda o fluxo repetível e a validação para equipes que perdem tempo com testes quebrados. A consulta do DataForSEO de 7 de outubro estima 1,600 buscas mensais no Google nos EUA por “automated software testing tools”. Isso mede o interesse na tarefa, não a demanda específica pelo Codex Cloud.

A menor versão útil poderia reunir instruções para o repositório, fixtures reproduzíveis, pedidos de correção com escopo definido e um guia de preparação do ambiente. Meça se as mudanças propostas preservam o comportamento esperado e reduzem o esforço de revisão. O desafio é a variedade de infraestruturas de teste: atender muitas stacks tornaria caro manter um kit pequeno.

Um pacote de verificação de migrações poderia atender equipes que usam um framework e um banco de dados específicos. O DataForSEO estima 1,300 buscas mensais nos EUA por “database migration tools”. Um MVP poderia oferecer modelos de migração, dados de teste descartáveis, verificações de compatibilidade e prompts de revisão que um desenvolvedor executa em um ambiente preparado. O desafio é o comportamento em produção: um pacote reutilizável não pode prometer que a implantação em um banco real será segura ou rápida.

Um pacote de evidências para revisão de PRs poderia ajudar quem mantém projetos a padronizar como pede e avalia os apontamentos. O DataForSEO estima 1,300 buscas mensais nos EUA por “ai code review”, e entre as perguntas reais de busca está “Can ChatGPT do a code review?”. Comece com orientações para o repositório, instruções de revisão e um formato para registrar as evidências de cada apontamento. O desafio é que já existe uma revisão nativa; o pacote precisa acrescentar avaliação específica do domínio e verificações úteis.

Os três são propostas de produtos baseadas na delegação de tarefas documentada. Os números de busca estimam interesse nas tarefas, não quantidade de clientes nem projeções de receita. Comece pelo kit de correção: sua condição de aceitação é mais fácil de medir do que a qualidade geral de uma revisão.

O ChatGPT consegue revisar código?

Sim. O Codex tem um fluxo documentado de revisão de PRs no GitHub, e você também pode pedir uma tarefa de análise. Informe a branch de base e os riscos que quer verificar. Mantenha a decisão de merge com uma pessoa.

Código gerado por IA é seguro?

Avalie a mudança concreta. Revise o comportamento alterado, a autorização, as dependências, os testes e as suposições que não foram verificadas. Nem uma explicação bem escrita nem testes passando demonstram que todos os casos importantes estão cobertos.

Vale a pena fazer revisão de código?

Use a revisão por agente quando uma análise adicional puder encontrar um erro caro. Acompanhe os apontamentos úteis e os falsos alarmes. Se ela gerar mais trabalho de revisão do que poupar, reduza o escopo.

Por onde começar na segunda-feira

Escolha um repositório com um comando de teste confiável. Prepare e publique o ambiente, delegue uma falha pequena e reproduzível e confira a tarefa pelo celular depois de sair da mesa. Revise a correção antes do merge. Registre o esforço de configuração, o esforço de revisão e o consumo do plano. Reutilize o ambiente se o experimento melhorar seu fluxo de trabalho.

Se quiser incorporar esse fluxo ao processo de entrega da sua equipe, crie um sistema de produção com IA.