Quem busca “OpenAI Codex” encontra, na maior parte dos resultados, um tutorial: o que é, como instalar, qual plano assinar. Serve a quem vai usar sozinho, no próprio computador. Não responde a pergunta de quem tem um time inteiro pedindo acesso: o que acontece quando o agente trabalha fora da máquina do desenvolvedor, num computador da OpenAI, com o código da empresa dentro?
A própria documentação do Codex responde boa parte disso, e a resposta começa por um detalhe que quase ninguém comenta: na nuvem, a internet do agente vem desligada. Este artigo cobre o básico (o que é, onde roda, quanto custa) e depois vai à decisão que cabe à empresa: por que a rede vem fechada, o ataque que a OpenAI usa como exemplo, as opções de liberação e o que fica fora do ambiente antes do primeiro pedido.
O que é o OpenAI Codex e para que serve?
O Codex é o agente de programação da OpenAI. “Agente” quer dizer que ele não só sugere a próxima linha: recebe uma tarefa em linguagem natural (“corrija o teste que está falhando”, “adicione paginação nesta listagem”), lê os arquivos do repositório, edita, roda comandos no terminal para conferir o próprio trabalho e devolve um conjunto de mudanças para alguém revisar.
Ele aparece em várias superfícies: no aplicativo de desktop do ChatGPT, na linha de comando (CLI), na extensão para editores de código, na web e no celular. A página oficial de preços resume o uso pago assim: Codex na web, na CLI, na extensão de IDE e no iOS, mais integrações na nuvem como revisão automática de código e Slack.
Em empresa, os usos mais comuns se parecem com os de qualquer agente de programação: investigar um bug, escrever testes, fazer uma mudança repetitiva em muitos arquivos e preparar um pull request. O que muda no Codex é que ele pode fazer isso sem o computador do desenvolvedor ligado, e é aí que começa a conversa sobre rede.
O Codex funciona na nuvem ou só no computador?
Funciona nos dois. No modo local (desktop, CLI e extensão), o agente roda na máquina de quem usa, dentro de uma sandbox do sistema operacional. A documentação de segurança diz que, por padrão, essa sandbox limita a escrita à pasta de trabalho e mantém o acesso à rede desligado, a menos que a configuração o ligue.
No modo nuvem, o Codex Cloud, a tarefa roda numa máquina virtual da OpenAI. Segundo a documentação de ambientes na nuvem do Codex, cada tarefa ganha um espaço de trabalho isolado a partir de um “ambiente” publicado: os repositórios, as dependências, as ferramentas e as regras de acesso. É por isso que a tarefa continua enquanto o computador dorme, e é por isso que o ambiente vira o lugar onde a empresa decide o que o agente alcança.
Há um detalhe de calendário que o gestor precisa conhecer. A OpenAI mantém hoje duas experiências de nuvem. A antiga, chamada Codex Cloud (Legacy), continua sustentando a revisão de código e as integrações com GitHub e Linear, e a empresa diz que planeja descontinuá-la. A atual, em que o próprio Codex prepara e testa o ambiente, é a que aparece para quem começa hoje. As regras de rede das duas são parecidas no espírito e diferentes nos nomes, e as duas aparecem ao longo deste texto.
Quanto custa o OpenAI Codex e quais planos incluem?
O Codex não é vendido à parte. Ele vem incluído nos planos do ChatGPT e divide os limites de uso com o restante do plano. Preço muda, então a referência é sempre a página oficial de preços do Codex. Na consulta feita em 12 de outubro de 2026, o quadro era este:
| Plano | Preço na página oficial (out/2026) | O que importa para a empresa |
|---|---|---|
| Free | US$ 0 | Uso no app de desktop, em liberação gradual; conta pessoal |
| Go | US$ 8/mês | Tarefas leves no app de desktop; conta pessoal |
| Plus | US$ 20/mês | Web, CLI, IDE e iOS, com recursos de nuvem; conta pessoal |
| Pro | A partir de US$ 100/mês (planos de 100, 200 ou 500) | Uso individual intenso; conta pessoal |
| Business | US$ 20 por usuário/mês no anual (2 ou mais usuários); US$ 25 no mensal | Espaço de trabalho da empresa, SAML SSO, MFA e sem treino com os dados do negócio por padrão |
| Enterprise e Edu | Sob consulta | SCIM, RBAC, logs de auditoria pela Compliance API, retenção e residência de dados |
| Chave de API | Por consumo, a preço de API | CLI, SDK e IDE para automação; sem os recursos de nuvem |
Elaborado pela Alliance Comunicação a partir da página de preços do Codex (OpenAI), consultada em 12 de outubro de 2026. Valores em dólar, sem impostos; confira antes de contratar.
Dois pontos dessa tabela pesam mais do que o preço. O primeiro: quem usa o Codex pela chave de API não tem os recursos de nuvem, então a discussão deste artigo vale para quem entra com conta do ChatGPT. O segundo: no Plus e no Pro, a conta é da pessoa, não da empresa. Um desenvolvedor usando o plano pessoal com o repositório da empresa é um uso que a empresa não administra e não consegue desligar quando ele sai do time.
A mesma página traz outro dado útil para dimensionar: no Business, a máquina virtual de cada tarefa na nuvem é maior do que no Plus. A documentação de ambientes lista 4 vCPUs, 16 GiB de memória e 32 GiB de disco para Pro, Business e Enterprise, contra 2 vCPUs e 8 GiB para o Plus.
Por que a internet do agente vem desligada na nuvem?
Porque o agente lê texto que ninguém da empresa escreveu, e texto pode conter ordens. A regra está documentada para os ambientes do Codex Cloud (Legacy) e divide cada tarefa em duas fases. Na primeira, o script de setup (escrito por quem configura o ambiente) roda com internet para instalar dependências. Na segunda, o agente trabalha, e é nessa que a rede fica fechada.
A lógica é simples. Na fase de setup, quem decide o que roda é a empresa, num script conhecido. Na fase do agente, quem decide é o modelo, a partir do pedido e de tudo o que ele lê pelo caminho: o código, a issue, o README de uma dependência, uma página da web. Fechar a rede nessa fase reduz o estrago de qualquer instrução maliciosa que tenha entrado pela leitura.
O mesmo vale fora da nuvem. A página de aprovações e segurança do Codex abre com a frase de que, por padrão, o agente roda com o acesso à rede desligado, e mostra que no modo local é preciso ligar explicitamente a rede na configuração da sandbox para os comandos alcançarem a internet.
O que pode dar errado quando a empresa libera tudo?
A documentação não trata o risco em abstrato. Ela lista quatro consequências de ligar a internet do agente e, logo depois, mostra um ataque funcionando.
O exemplo é o que mais ensina. Alguém pede ao Codex para corrigir uma issue do GitHub e cola o link. A descrição da issue diz que um “script” dá erro 404 e pede para rodá-lo e mostrar a saída. O script é uma linha que pega o último commit (git show HEAD) e envia por POST, com curl, para um serviço externo de testes. Se o agente seguir a instrução, o conteúdo do commit sai do ambiente para um servidor que o atacante controla.
O registro reproduzido na página mostra mais do que o vazamento. O agente roda o comando, recebe a resposta do servidor externo com o commit dentro e, no resumo da tarefa, apresenta como melhoria um script novo para “facilitar” o envio do commit. Quem aprovar aquele pull request sem ler o registro coloca o mecanismo de vazamento dentro do repositório.
A ordem perigosa não veio de quem pediu a tarefa. Veio de um texto que o agente leu no caminho.
Repare que nada disso exige um funcionário mal-intencionado. Exige só um agente com rede aberta e alguém que confie no texto de uma issue pública, de um README ou de uma página da web. É por isso que a recomendação da OpenAI é apontar o Codex apenas para recursos confiáveis e manter o acesso à internet o mais limitado possível.
Quais são as opções de acesso à internet do Codex?
Ligar a rede não é um interruptor de tudo ou nada. Nas duas experiências de nuvem, a empresa escolhe um ponto de partida e ajusta a partir dele.
| Decisão | Codex Cloud (Legacy) | Codex Cloud atual | Quando faz sentido |
|---|---|---|---|
| Rede do agente | Desligada por padrão; liga por ambiente | Chave “Allow Codex to access internet” no ambiente | Desligada sempre que a tarefa não precisa buscar nada |
| Lista de domínios | Nenhum, Dependências comuns ou Todos (irrestrito) | Package managers, só domínios próprios ou Todos (irrestrito) | Começar pela menor lista que deixa os testes rodarem |
| Domínios extras | Somam-se a Nenhum ou Dependências comuns | Campo de domínios adicionais | Registro privado de pacotes, API interna de teste |
| Métodos HTTP | Opção de permitir só GET, HEAD e OPTIONS | A página atual não descreve a opção | Bloquear envio (POST, PUT, PATCH, DELETE) quando a tarefa só baixa |
| Credenciais | Segredos só no setup, removidos antes do agente | Segredos de rede trocados pelo proxy, por domínio | Nunca credencial de produção no ambiente do agente |
Elaborado pela Alliance Comunicação a partir das páginas “Agent internet access”, “Codex Cloud (Legacy)” e “Cloud environments” da documentação do Codex (OpenAI), consultadas em 12/10/2026.
Vale olhar o que está dentro dos atalhos. A lista de dependências comuns do modo Legacy inclui domínios largos como github.com, githubusercontent.com, google.com e microsoft.com. A predefinição de gerenciadores de pacotes da experiência atual é mais estreita, com endereços específicos de registros (npm, PyPI, crates, Maven, repositórios do Ubuntu e do Debian), mas também traz github.com. Em outras palavras: o atalho já inclui o lugar de onde vêm as issues, que foi justamente a porta de entrada do exemplo de ataque.
Por isso o bloqueio de métodos importa. Com a rede limitada a GET, HEAD e OPTIONS, o agente consegue baixar um pacote, mas não consegue enviar dados por POST, nem para um domínio que esteja na lista. Na página de ambientes atuais, essa opção não aparece descrita; quem usa a experiência nova precisa compensar com uma lista mais curta e com revisão do registro de comandos.
Dois avisos da documentação atual completam o quadro. Liberar um domínio não entrega credencial nem permissão naquele serviço. E, para serviços que filtram conexão por IP de origem, a OpenAI publica a lista de IPs de saída dos agentes, mas avisa que essas faixas são compartilhadas entre clientes. Liberar o IP não substitui a autenticação do serviço.
Onde ficam os segredos da empresa quando o agente roda na nuvem?
Este é o ponto em que as duas experiências mais divergem, e em que a configuração errada custa mais. No modo Legacy, a página do Codex Cloud (Legacy) separa variáveis de ambiente de segredos. As variáveis valem a tarefa inteira, inclusive na fase do agente. Os segredos ficam com uma camada extra de criptografia, só existem para o script de setup e são removidos antes de o agente começar.
Na experiência atual, a separação é outra. Uma variável de ambiente é entregue diretamente aos programas, ou seja, o agente consegue ler. Um segredo de rede nunca chega cru ao processo: o programa recebe um marcador, e o proxy troca pelo valor real só nas requisições HTTPS, na porta 443, para os domínios permitidos daquele segredo. Salvar um segredo de rede também libera os domínios dele, o que é cômodo e merece atenção.
A regra prática para a empresa sai daí: token de registro privado de pacotes vai como segredo de rede; chave de banco de produção, de gateway de pagamento ou de nuvem com poder de escrita não vai para o ambiente do agente, nem como variável, nem como segredo. Para acesso a recursos de nuvem, a documentação descreve a opção de credenciais de curta duração via OIDC, disponível por solicitação no Enterprise, em que as permissões são da identidade configurada, e não da pessoa.
Mais um detalhe de compartilhamento. No Business e no Enterprise, um ambiente pode ser compartilhado com o espaço de trabalho, e no modo Legacy o cache do contêiner é comum a todos que usam aquele ambiente. Antes de compartilhar, a documentação pede para revisar os arquivos preparados e as credenciais que pertencem ao ambiente.
Como montar a política de rede do Codex na prática?
A sequência abaixo cabe numa reunião entre quem cuida de tecnologia e quem cuida de segurança, antes de abrir o Codex Cloud para o time.
1. Defina de quem é a conta
Uso com código da empresa sai do plano pessoal e vai para um espaço de trabalho Business ou Enterprise, com SSO. É o que permite administrar quem usa, desligar acessos e, no Enterprise, auditar.
2. Separe os repositórios por sensibilidade
Nem todo repositório precisa ir para a nuvem. Comece pelos que não guardam regra de negócio sensível nem dado pessoal, e deixe os críticos no modo local, com a sandbox padrão.
3. Comece com a rede do agente desligada
Deixe o setup instalar o que precisa e veja quantas tarefas fecham sem rede nenhuma. Ligue só quando uma tarefa real falhar por falta de acesso, e registre o motivo.
4. Libere o mínimo, domínio por domínio
Parta de “nenhum” ou da predefinição mais estreita e acrescente os domínios que o teste pediu. Evite “Todos (irrestrito)” em ambiente compartilhado. Onde a opção existir, restrinja os métodos a GET, HEAD e OPTIONS.
5. Tire os segredos do alcance do agente
Credencial que só o setup usa fica no setup. Credencial que a tarefa precisa usa o mecanismo de segredo de rede, com domínio permitido explícito. Credencial de produção não entra.
6. Torne a revisão humana obrigatória
O Codex devolve o diff e o registro dos comandos. A regra do time é ler os dois antes de abrir ou aprovar o pull request, com atenção especial a arquivos novos de script e a qualquer comando que fale com endereço externo.
Quais os erros mais comuns ao liberar o Codex para o time?
- Ligar a rede “para não dar problema”. O conforto de não ver erro de download troca um incômodo pequeno por um risco grande e silencioso.
- Tratar a predefinição como lista segura. Os atalhos incluem domínios largos, inclusive o GitHub, de onde vêm as issues.
- Guardar credencial como variável de ambiente. Na experiência atual, variável é lida pelo programa; o lugar de credencial de serviço é o segredo de rede, e o de credencial de produção é fora do ambiente.
- Compartilhar o ambiente sem revisar. O que o ambiente carrega vai junto para todo o espaço de trabalho.
- Aprovar o PR pelo resumo. No exemplo da OpenAI, o resumo da tarefa apresentava o script de vazamento como melhoria.
- Usar conta pessoal com código da empresa. A empresa perde a administração e a auditoria do uso.
Há ainda uma limitação que costuma aparecer tarde: a documentação atual lista que GitLab e GitHub Enterprise Server auto-hospedado ainda não são suportados nos ambientes de nuvem. Empresa que hospeda o próprio Git precisa saber disso antes de planejar o uso na nuvem.
OpenAI Codex, Claude Code ou GitHub Copilot: o que muda na decisão?
Os três disputam o mesmo orçamento e fazem trabalho parecido no dia a dia. A diferença que pesa para a empresa está menos no que o agente escreve e mais em onde ele roda e em quem controla esse lugar. No Codex, a parte de nuvem é central, e por isso a política de rede do ambiente é a primeira decisão.
No Claude Code, da Anthropic, o centro da conversa são os modos de permissão na máquina do desenvolvedor e as configurações que a empresa trava; tratamos disso em Claude Code e as permissões que a empresa define. No GitHub Copilot, o ponto é outro: o que o assento contratado cobre e o que fica de fora, assunto de GitHub Copilot e o que o assento não cobre. E, se a dúvida for o editor, o guia do Cursor para empresa mostra o que ligar antes de liberar.
Em qualquer um dos três, a pergunta de fundo é a mesma: o que o agente consegue fazer sem uma pessoa olhando, e o que acontece se ele obedecer a um texto errado. A ferramenta muda; a disciplina de rede, segredo e revisão é a mesma.
O que muda por tipo de empresa?
O tamanho do time muda a forma, não o princípio. Uma empresa pequena com um ou dois desenvolvedores pode começar no Business, com um ambiente por repositório e rede desligada. Uma empresa com dados regulados, como saúde, finanças ou varejo com base grande de clientes, tende a precisar dos controles do Enterprise (auditoria, retenção e residência de dados) e a manter os repositórios mais sensíveis no modo local.
Agências e empresas que entregam software para terceiros têm uma camada extra: o código não é só delas. Antes de colocar repositório de cliente num ambiente de nuvem, vale conferir o contrato e a política de dados do cliente. É o tipo de decisão que entra no desenho de um projeto de desenvolvimento com IA, junto com a escolha da ferramenta e das regras de revisão.
Por onde começar hoje?
- Liste quem já usa o Codex na empresa e com qual conta (pessoal ou do espaço de trabalho).
- Abra cada ambiente de nuvem existente e anote a configuração de internet, a lista de domínios e as variáveis guardadas.
- Desligue a rede dos ambientes que não têm motivo registrado para estar ligada.
- Mova credenciais para segredos de rede ou para fora do ambiente, conforme o caso.
- Escreva a regra de revisão: ninguém aprova PR do agente sem ler o diff e o registro de comandos.
- Reveja a política a cada mudança relevante na documentação do Codex, que hoje convive com duas experiências de nuvem.
Se a empresa ainda está decidindo onde a IA entra no desenvolvimento, e não só qual agente usar, o diagnóstico gratuito da Alliance ajuda a enxergar em que ponto a tecnologia está madura e em que ponto ela ainda depende de processo. A ferramenta escolhida importa menos do que a regra que vem antes dela.