No DevDay de 29 de setembro, a OpenAI afirmou que os desenvolvedores “podem executar o Codex onde precisarem: no computador, remotamente a partir do celular ou na nuvem em qualquer dispositivo”. A frase no resumo do DevDay que mais importa para as equipes vem logo em seguida: ambientes de desenvolvimento reutilizáveis “ajudam as tarefas a começarem rapidamente e oferecem à sua equipe uma configuração compartilhada com definições e permissões aprovadas”. O Codex na nuvem está disponível nos planos Plus, Pro, Business, Healthcare, Education e Enterprise.
Para um desenvolvedor individual, isso resolve a questão. Mas para uma equipe que já roda o Claude Code em uma estação de trabalho, o Codex em um servidor de build e o Gemini no notebook de alguém, isso adiciona mais um destino. O trabalho agora pode começar na nuvem da OpenAI, no seu próprio hardware ou no celular enquanto você está no trem — e cada local mantém sua própria lista do que foi executado. Saber qual agente está cuidando do quê, o que já foi concluído e o que está aguardando revisão ganha mais um lugar para conferir. Portanto, a pergunta mais importante não é “nuvem ou local?”, mas sim que tipo de trabalho pertence a cada lugar e onde fica registrado o histórico de tudo isso.
TL;DR
O Codex na nuvem é a melhor opção para tarefas do Codex que precisam começar rápido, continuar rodando enquanto o notebook está suspenso ou ser iniciadas pelo celular, além de atender equipes que buscam uma única configuração homologada em vez de cada membro preparar seu próprio ambiente. Já os seus próprios Computers se destacam quando uma tarefa precisa do Claude Code ou de outro Runtime diferente do Codex, de hardware superior à VM padrão do seu plano ou de recursos que a documentação de ambientes na nuvem da OpenAI ainda aponta como não suportados hoje: repositórios do GitLab, uso de navegador ou serviços privados acessados via SSH ou protocolo de banco de dados. Nenhuma dessas opções define quem atribuiu a tarefa ou quem aprova a entrega. Isso continua sob responsabilidade da equipe, centralizado em uma Task.
O que o ambiente em nuvem do Codex oferece
Um ambiente na nuvem, segundo a documentação da OpenAI, “é a configuração reutilizável que as tarefas utilizam: repositórios, dependências, ferramentas e configurações de acesso”. Você seleciona repositórios do GitHub, e o Codex os analisa, instala dependências e ferramentas, testa o fluxo de trabalho e solicita qualquer informação que não consiga inferir sozinho. Depois de revisar o relatório de configuração, você publica o ambiente. A partir daí, cada nova tarefa começa com base nesse sistema de arquivos publicado em seu próprio espaço de trabalho isolado, e as tarefas “podem continuar rodando enquanto o seu computador está suspenso”.
O modelo de acesso é bem mais criterioso do que um simples script de inicialização com um token embutido. Variáveis de ambiente são repassadas diretamente aos programas. Já os segredos de rede nunca chegam ao processo: as aplicações recebem um valor substituto (placeholder), e um proxy insere a credencial real exclusivamente para destinos HTTPS autorizados. O acesso à internet é uma configuração que você ativa e pode restringir usando padrões de gerenciadores de pacotes ou uma lista de domínios personalizados. Serviços privados podem ser acessados por meio de uma VPN — com o Tailscale como provedor suportado atualmente —, e espaços de trabalho Enterprise podem solicitar conexões OIDC para obter credenciais temporárias na nuvem.
Iniciar um trabalho é igualmente flexível. A visão geral do Codex Cloud menciona a web, o aplicativo para desktop, dispositivos móveis e a CLI do Codex, e espaços de trabalho Enterprise com delegação de nuvem podem iniciar tarefas mencionando @ChatGPT no Slack ou Microsoft Teams. Um ambiente Enterprise pode ser compartilhado com todo o workspace, permitindo que um novo colega de equipe comece direto da configuração aprovada em vez de ter que recriar tudo do zero. Para fluxos de trabalho com o Codex, isso elimina de vez as divergências de configuração (setup drift).
O próprio portfólio da OpenAI trata o local de execução como uma escolha por carga de trabalho, e não como uma resposta única. Cada um dos Dots recebe seu próprio computador na nuvem, e a API de Agents aceita tanto ambientes hospedados pela OpenAI quanto auto-hospedados (self-hosted), conforme abordamos no artigo sobre quem executa os agentes. Agora, o Codex também pode ser executado em ambos os lugares.
O que um Sharkly Computer oferece
Um Computer é um dispositivo conectado, servidor ou contêiner onde um Agent pode executar tarefas. Conforme a documentação do Sharkly Computers, ele “fornece o sistema operacional, arquivos, credenciais, acesso à rede e ferramentas necessárias para um Agent”. Um serviço local leve faz o registro da máquina, detecta os Runtimes instalados nela, recebe as execuções enfileiradas e transmite o progresso de volta em tempo real. Como o serviço estabelece uma conexão de saída, uma configuração comum não precisa de nenhuma porta de entrada aberta.
Três características são fundamentais para essa comparação. Primeiro: um único Computer pode disponibilizar múltiplos Runtimes. O Sharkly oferece suporte nativo a Claude Code, Codex, Gemini, OpenCode, OpenClaw e Hermes; um ACP Runtime personalizado pode cobrir qualquer ferramenta não detectada pelo serviço local; e uma mesma máquina pode atender a diversos Agents. Segundo: o isolamento é feito por Task. No modo Temporary, cada Task recebe um diretório isolado, e execuções vinculadas a repositórios podem usar uma nova worktree — é assim que agentes paralelos evitam conflitos de merge. Já no modo Specified, a execução reaproveita um diretório local configurado com suas dependências, caches e serviços locais já preparados, uma execução por vez. Terceiro: as credenciais pertencem a você. Um Agent gerencia variáveis de ambiente normais e secretas, cada execução recebe estritamente o ambiente e as credenciais autorizadas, e um Computer com visibilidade Personal permanece acessível unicamente ao seu proprietário.
A contrapartida direta é que a manutenção do host fica por sua conta. Se um Computer ficar offline, as novas execuções ficarão aguardando a reconexão. O aplicativo para desktop pode impedir a suspensão do sistema e, no macOS, continuar em execução mesmo com a tampa fechada quando o sistema permitir. Contudo, execuções longas e autônomas devem rodar em um servidor sob seu controle, como argumentamos no artigo sobre execução remota de agentes de código. O modelo de custos não muda: Computers e Runtimes não consomem assentos nos planos do Sharkly, o Sharkly não comercializa tokens e um Codex Agent utiliza o plano do ChatGPT ou a chave de API com a qual a sua Codex CLI estiver autenticada.
Codex na nuvem ou seu próprio Computer: tabela de decisão
Todas as informações sobre o Codex na nuvem apresentadas a seguir foram extraídas da documentação de ambientes na nuvem da OpenAI referente a 30 de setembro. As informações sobre Computers vêm da documentação do Sharkly.
| Requisitos do trabalho | Melhor escolha | Motivo |
|---|---|---|
| Uma correção iniciada pelo celular, com o notebook fechado | Codex na nuvem | As tarefas começam no celular e continuam em execução enquanto o computador está suspenso |
| Uma configuração aprovada para toda a equipe | Codex na nuvem (compartilhado em um workspace Enterprise) | Um único ambiente publicado; cada tarefa continua recebendo seu próprio espaço de trabalho isolado |
| Nenhum host para manter | Codex na nuvem | O Codex prepara, testa e executa o ambiente |
| Claude Code, Gemini, OpenCode ou outro Runtime não pertencente à OpenAI | Seu próprio Computer | Um Computer pode hospedar vários Runtimes lado a lado |
| Uso de computador ou de navegador durante a tarefa | Seu próprio Computer | A documentação lista o uso de computador e de navegador como recursos ainda não suportados em ambientes na nuvem |
| Um repositório no GitLab ou no GitHub Enterprise Server | Seu próprio Computer | Também citado como uma limitação atual da versão na nuvem |
| SSH, protocolo nativo de banco de dados ou DNS privado | Um Computer dentro dessa rede | A VPN na nuvem gerencia tráfego HTTP e HTTPS sobre IPv4, sem suporte a DNS privado, SSH ou protocolos nativos de banco de dados |
| Hardware específico ou capacidade superior à da VM padrão | Seu próprio Computer ou mediante solicitação Enterprise | Os padrões são 2 vCPUs, 8 GiB de memória e 8 GiB de disco no Plus; 4 vCPUs, 16 GiB e 32 GiB no Pro, Business e Enterprise. Configurações maiores ou personalizadas precisam ser solicitadas à equipe de contas da OpenAI |
| Um repositório muito extenso com estado local pesado | Um Computer local em modo Specified | Reutiliza o diretório existente em vez de preparar uma cópia do zero |
| Skills configuradas exclusivamente no seu notebook | Seu próprio Computer | Skills locais pessoais não são sincronizadas com ambientes na nuvem; apenas as skills do repositório são sincronizadas |
Encare essa comparação como uma matriz de decisão simples: utilize o Codex na nuvem quando a tarefa envolver o Codex, as dependências forem públicas ou acessíveis por HTTPS liberado em lista de permissões e a pessoa que a iniciar não estiver necessariamente à mesa de trabalho. Já os seus próprios Computers devem ser usados quando a tarefa exigir um Runtime, hardware ou infraestrutura de rede específicos escolhidos de forma deliberada.
Uma linha foi omitida de propósito: “dados que não podem sair da nossa rede”. Executar no seu próprio Computer mantém o repositório, os caches e os segredos no hardware que você controla. No entanto, isso não impede que os prompts cheguem ao provedor do modelo, já que tudo o que o Runtime envia para o modelo continua saindo da sua rede. A própria OpenAI estabelece essa mesma distinção para o seu produto: a documentação da API de Agents destaca que “escolher um sandbox auto-hospedado não torna a API de Agents elegível para ZDR (Zero Data Retention)”. O local de execução define onde residem o código e as credenciais. Já a retenção de dados é um acordo contratual à parte com o seu provedor de IA.
É na execução mista que o painel mostra seu valor
A maioria das equipes usará ambos. Correções rápidas com o Codex são disparadas pelo celular em um ambiente na nuvem, enquanto a migração que precisa do banco de homologação é executada por um Agent em um Computer interno da rede. Essa divisão faz todo o sentido, mas acaba gerando duas listas de trabalho separadas.
O Codex na nuvem mantém as tarefas isoladas por padrão: ter acesso a uma configuração compartilhada, segundo a documentação, “não concede acesso à tarefa de outra pessoa”. Esse é o padrão correto em termos de privacidade. Por outro lado, isso significa que a configuração é compartilhada, mas o trabalho não. Sendo assim, a pergunta “o que os agentes da equipe estão fazendo agora?”, englobando tanto as tarefas na nuvem quanto nos Computers locais, precisa ser respondida em outro lugar. Defina a regra de roteamento primeiro:
Where does this Task run?
1. Needs a non-Codex Runtime -> Agent on a Computer
2. Needs SSH, a database protocol, or private DNS -> Computer inside that network
3. Needs GitLab, GitHub Enterprise Server, or browser use -> Computer
4. Codex work, allowlisted HTTPS, started away from a desk -> Codex cloud
5. Someone must accept the result -> a Task with an Assignee and a reviewer, wherever it ran
A regra número cinco é o que torna essa divisão gerenciável. No Sharkly, a Task é a fonte central de registro: o progresso, os logs de execução, os impedimentos e o resultado final convergem para ela, e qualquer execução que dependa de revisão humana cai diretamente na Inbox do responsável. Um Codex Agent e um Claude Code Agent no mesmo Computer reportam suas atividades para o mesmo painel, cada qual utilizando o modelo configurado em seu respectivo Runtime. Já para os trabalhos executados no Codex na nuvem, o elo de ligação é o pull request: ao incluir o Task ID no nome da branch ou no título do PR, a integração do Sharkly com o GitHub vincula o PR de volta à Task, garantindo que a aprovação continue centralizada em um só lugar. Nosso artigo sobre execuções de agentes que ultrapassam o expediente de trabalho detalha como gerenciar a revisão dessas tarefas longas e autônomas.
Os agentes pesquisam, executam, testam e reportam. As pessoas definem a direção, concedem autorizações e aprovam o resultado final. Esse contrato não muda, independentemente de onde a tarefa foi executada.
O que isso significa para o seu setup
O Codex na nuvem é uma excelente resposta para “onde o Codex deve rodar?”. Ele não foi projetado, contudo, para responder “em que cada um dos nossos agentes, em diferentes Runtimes, está trabalhando e quem aprovou cada entrega?”. Mantenha um Computer para as tarefas que exigem os seus Runtimes, hardware ou rede interna; deixe o Codex na nuvem cuidar das demandas iniciadas pelo celular ou com o notebook fechado; e mantenha um único registro unificado de ambos.
Se você deseja continuar usando múltiplos agentes de código em vez de ficar preso a um único ecossistema, esse é exatamente o problema que o Sharkly foi criado para resolver.
