OpenAI reforça proteções de segurança do Codex para prevenir ações destrutivas com limpeza e controles de permissão mais seguros

A OpenAI reforçou a proteção de segurança do Codex, adicionando mecanismos de limpeza e controle de permissões para evitar operações destrutivas

Após investigar vários relatos de operações destrutivas que excederam a intenção do usuário, a OpenAI atualizou os mecanismos de controle de segurança do Codex.

O problema não está no fato de o agente de programação com IA poder executar comandos — esse é justamente o valor central do Codex. O risco aparece quando um agente com permissões amplas executa operações de limpeza ou gerenciamento de arquivos e interpreta erroneamente o caminho de destino.

Segundo Thibault "Tibo" Sottiaux, engenheiro responsável pelo Codex na OpenAI, a empresa investigou alguns casos em que o GPT-5.6 executou operações destrutivas no Codex fora do escopo solicitado. Um dos padrões recorrentes envolvia a limpeza de diretórios temporários, especialmente ao executar sessões com amplo acesso e menos proteção de sandbox.

As medidas mais recentes da OpenAI atuam em múltiplas camadas simultaneamente:

• Validar o alvo da exclusão antes de operações destrutivas;
• Usar diretórios temporários dedicados, em vez de reutilizar variáveis de ambiente sensíveis;
• Reforçar a detecção e a revisão de comandos de alto risco;
• Tornar o modo "acesso total" mais difícil de ser ativado acidentalmente;
• Melhorar a revisão automática para identificar operações destrutivas de forma mais confiável;
• Adicionar novas avaliações e tarefas de treinamento com base nos casos de falha observados pela equipe.

A mudança fundamental não é uma lista única de proibições. A OpenAI está ao mesmo tempo reforçando as instruções do modelo e o ambiente de execução ao seu redor.

Investigação focada na limpeza de diretórios temporários

A investigação da OpenAI descobriu que parte das falhas destrutivas estava relacionada à lógica de limpeza de diretórios de trabalho temporários.

Agentes de programação frequentemente criam locais temporários durante o trabalho. As tarefas podem envolver descompactar arquivos, gerar arquivos intermediários, executar testes, preparar patches ou criar artefatos de build descartáveis. Limpar esses arquivos depois geralmente é seguro.

O perigo surge quando variáveis que identificam diretórios temporários são ambíguas, reutilizadas, formatadas incorretamente ou apontam acidentalmente para locais importantes.

Sottiaux descreveu um padrão de falha: o modelo reutiliza variáveis de ambiente do sistema, como $HOME, como diretório de trabalho temporário. Se um comando de limpeza subsequente interpretar erroneamente essa variável, um comando destinado a excluir o diretório temporário pode apontar para o diretório pessoal real do usuário.

Essa cadeia de falhas pode ser compreendida em alto nível:

Criar ou identificar área de trabalho temporária
↓
Reutilizar variável ampla do sistema
↓
Construir comando de limpeza
↓
Resolver caminho de destino incorreto
↓
Executar operação destrutiva com permissões amplas
↓
Excluir arquivos além do escopo pretendido

Em sessões sem restrições, esse risco é especialmente grave.

Em ambientes de sandbox estritamente limitados, o sistema operacional pode impedir que comandos incorretos afetem diretórios não relacionados. Já no modo de acesso total, essa fronteira é removida intencionalmente, portanto erros de resolução de caminho podem ter um impacto muito maior.

A documentação atual do Codex da OpenAI deixa clara essa distinção: o modo normal workspace-write restringe as edições cotidianas ao diretório de trabalho atual,

enquanto o danger-full-access remove as fronteiras de sandbox do sistema de arquivos e da rede.

O Codex agora verifica mais explicitamente os alvos destrutivos

A primeira medida principal de mitigação é uma validação mais forte do alvo antes de exclusões ou operações destrutivas semelhantes.

O Codex não trata mais a limpeza como uma etapa final rotineira; ele é explicitamente instruído a confirmar se o caminho de destino é exatamente aquele que pretende modificar.

Isso é importante porque comandos shell destrutivos geralmente só são seguros quando os argumentos estão corretos.

Por exemplo, a diferença entre excluir um diretório temporário dedicado e excluir o diretório de trabalho pai pode ser apenas uma expansão de variável incorreta, erro de aspas, problema de normalização de caminho ou argumento ausente.

A nova abordagem reduz a dependência de suposições implícitas.

Antes de executar operações de alto risco no sistema de arquivos, o sistema deve pensar com mais cuidado nas seguintes questões:

• Qual diretório este comando afetará exatamente?
• Esse diretório é um local temporário criado para esta tarefa?
• O caminho resolve dentro do diretório de trabalho esperado?
• O alvo está acidentalmente amplo demais?
• A exclusão é irreversível?
• O escopo é claro o suficiente para continuar sem precisar perguntar ao usuário?

Essa é uma melhoria de segurança no nível do comportamento do agente.

Ela não substitui a sandbox, mas reduz primeiramente a probabilidade de comandos perigosos chegarem à fronteira da sandbox.

Diretórios temporários dedicados substituem a reutilização arriscada de variáveis

A OpenAI também está mudando a forma como o Codex lida com o trabalho temporário.

O padrão mais seguro é criar um diretório temporário novo e específico, em vez de reutilizar variáveis de sistema que já possuem significado importante.

Variáveis como $HOME são especialmente sensíveis porque geralmente apontam para o diretório real do usuário, que contém arquivos de projeto, configurações, credenciais, estado de aplicativos e outros dados pessoais.

Usar um caminho temporário dedicado tem duas vantagens.

Primeiro, o alvo tem um significado semântico mais restrito: serve apenas para dados de tarefas descartáveis.

Segundo, a limpeza se torna mais fácil de validar, pois o sistema pode comparar o alvo da exclusão com o diretório temporário exato criado no início da tarefa.

Esse é um princípio de engenharia direto, mas se torna ainda mais importante quando agentes autônomos podem executar comandos shell em velocidade de máquina.

O padrão mais seguro é na prática:

Criar um novo diretório temporário
↓
Armazenar arquivos temporários específicos da tarefa ali
↓
Rastrear o caminho exato
↓
Validar esse mesmo caminho antes da limpeza
↓
Excluir apenas o diretório temporário verificado

O objetivo é evitar que um estado amplo do ambiente se torne alvo de limpeza.

Detecção e revisão de comandos perigosos estão sendo reforçadas

A validação de caminhos é apenas uma camada de defesa.

A OpenAI também está reforçando os mecanismos para identificar comandos de risco e encaminhá-los para revisão.

O changelog do Codex já registra uma detecção mais forte para operações forçadas de rm, bem como uma confirmação mais consistente do Full Access. A política atual de revisão automática também inclui explicitamente operações destrutivas com risco significativo de dano irreversível entre as categorias que visa bloquear.

Isso é importante porque um comando pode ser totalmente legal sintaticamente e ainda assim não ser seguro.

Um comando de exclusão pode estar perfeitamente de acordo com as regras de sintaxe do shell, mas ainda ser perigoso, pois pode:

• Ter um escopo de diretório amplo demais;
• Afetar dados fora do diretório de trabalho;
• Usar variáveis não resolvidas;
• Excluir recursivamente grandes árvores de diretórios;
• Destruir trabalho não commitado;
• Enfraquecer controles de segurança;
• Combinar várias operações perigosas em uma única chamada de shell.

Portanto, a proteção de segurança atualizada da OpenAI não apenas avalia se o comando pode ser executado.

Ela também avalia se o comando deve ser executado, dadas as permissões atuais e a autorização do usuário.

O acesso total ficou mais difícil de ser ativado acidentalmente

O texto original também destaca as mudanças na experiência do modo de acesso total do Codex.

O acesso total foi projetado deliberadamente para ser extremamente poderoso. A documentação atual de permissões da OpenAI afirma que, nesse modo, o Codex pode editar qualquer arquivo no computador e executar comandos com acesso à rede sem solicitar aprovação.

Isso é útil em máquinas virtuais temporárias, ambientes de desenvolvimento dedicados ou outros sistemas estritamente controlados, onde o operador deseja intencionalmente uma automação sem restrições.

No entanto, em uma estação de trabalho comum, esse modo aumenta significativamente as consequências de um erro.

A OpenAI agora elevou o limite para ativar esse modo.

A documentação atual do Codex estabelece que o acesso total deve ser explicitamente habilitado nas configurações do aplicativo de desktop antes de aparecer como um modo de permissão opcional. A interface também exibe avisos mais fortes sobre possível perda de dados, vazamentos e comportamento inesperado.

Para modelos aprovados de alto risco em segurança, a OpenAI afirma que o aplicativo de desktop exibirá um aviso adicional específico para esse modelo antes de o acesso total ser habilitado, além de recomendar o modo mais seguro de "aprovar por mim".

Descrição dos principais modos de permissão

O ponto-chave é: revisão automática e acesso total não são a mesma coisa.

A revisão automática mantém os mecanismos de sandbox. O que muda é quem avalia as solicitações que cruzam a fronteira da sandbox.

O acesso total remove diretamente a própria fronteira da sandbox.

A revisão automática agora identifica operações destrutivas com mais rigor

A OpenAI também atualizou as regras de revisão automática para identificar melhor operações destrutivas.

A revisão automática é um agente de revisão independente que avalia solicitações qualificadas quando o agente principal do Codex deseja cruzar os limites da sandbox.

O fluxo normal é o seguinte:

O agente principal do Codex trabalha dentro da sandbox
↓
Alguma operação requer permissões adicionais
↓
O Codex cria uma solicitação de aprovação
↓
A revisão automática avalia a solicitação
↓
Aprovada → continua a execução
Rejeitada → o Codex deve procurar um caminho mais seguro ou perguntar ao usuário

A documentação da OpenAI mostra que a revisão automática pode avaliar solicitações envolvendo:

• privilégios elevados de shell ou execução;
• acesso de rede bloqueado;
• modificações fora do diretório raiz gravável;
• chamadas externas de MCP ou ferramentas de aplicativo com efeitos colaterais;
• acesso de uso do computador a novos sites ou domínios.

Suas políticas visam rejeitar ou limitar ações destrutivas, incluindo sondagem de credenciais, exfiltração de dados, enfraquecimento contínuo de controles de segurança e comportamentos com risco significativo de danos irreversíveis.

Isso torna a revisão automática uma camada de segurança importante para o usuário, reduzindo a intervenção manual sem dar ao agente principal de codificação acesso ilimitado.

No entanto, a OpenAI afirma explicitamente que a revisão automática não substitui o mecanismo de sandbox.

Se o usuário escolher acesso total e remover a sandbox, o revisor automático não pode recriar um limite que não existe mais.

A OpenAI está reproduzindo falhas em novas avaliações

Os esforços de mitigação também estão sendo realimentados nos testes de modelos.

Sotio afirmou que a OpenAI construiu avaliações direcionadas que reproduzem vários tipos de falhas descobertas durante a investigação. A empresa também está adicionando tarefas de aprendizado por reforço e pontuadores para esses riscos.

Isso é importante porque, se erros destrutivos raros forem avaliados apenas como casos isolados, é difícil melhorá-los.

Transformar falhas reais em testes reproduzíveis permite que a equipe faça as seguintes perguntas:

• O modelo consegue identificar alvos de exclusão acidentalmente grandes demais?
• Ele evita reutilizar variáveis de ambiente sensíveis?
• Ele interrompe a operação quando o escopo não está claro?
• Ele prioriza operações recuperáveis quando possível?
• A revisão automática promove ou rejeita corretamente a operação?
• Modelos futuros repetirão a mesma falha?

Em outras palavras, o incidente está sendo convertido em cobertura de testes de regressão.

O objetivo de segurança não é apenas corrigir um padrão de comando, mas tornar menos provável que versões futuras do Codex reproduzam categorias mais amplas de falhas.

Sandbox e permissões ainda são mais importantes do que apenas prompts

A investigação também reforçou um ponto mais amplo sobre a segurança de agentes de codificação.

Instruções em linguagem natural como "tenha cuidado ao manipular arquivos" não são limites de segurança robustos.

A sandbox de execução é.

As próprias diretrizes de implantação da OpenAI descrevem sandbox e aprovações como controles complementares:

• A sandbox determina onde o Codex pode gravar e quais recursos de rede pode acessar;
• A política de aprovação determina quando o Codex deve parar antes de cruzar esse limite.

Para a maioria dos trabalhos locais, a OpenAI atualmente recomenda configurações no escopo do workspace em vez de execução irrestrita.

Uma configuração mais segura e representativa é:

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

Usuários que desejam usar a revisão automática com promoção de nível podem manter a mesma sandbox enquanto alteram o revisor:

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

Essas configurações mantêm um limite de nível de sistema operacional em torno do workspace normal.

Em contraste, o acesso total remove intencionalmente essa proteção e só deve ser usado quando o próprio ambiente fornecer

o isolamento necessário.

O que esta atualização de segurança do Codex significa para os desenvolvedores

Para os desenvolvedores, esta atualização não significa que o Codex nunca mais cometerá erros destrutivos.

A própria documentação da OpenAI alerta que a revisão automatizada pode falhar, e nenhum mecanismo de segurança em nível de agente deve ser considerado um substituto para práticas de desenvolvimento recuperáveis.

A mudança real é a defesa em profundidade.

Operações de alto risco agora têm mais oportunidades de serem bloqueadas:

1. O modelo é instruído a verificar os alvos.
2. O trabalho temporário deve usar caminhos dedicados mais seguros.
3. Padrões de comandos de alto risco podem ser reconhecidos pela estrutura de execução.
4. Os limites da sandbox podem bloquear acesso fora do workspace.
5. Aprovações ou revisão automática podem avaliar solicitações que cruzam limites.
6. O acesso total requer uma ação do usuário mais clara e deliberada.
7. Casos de falha são adicionados a avaliações e treinamentos futuros.

Isso é mais robusto do que depender de qualquer medida de segurança única.

Para a codificação diária, a configuração padrão mais segura continua simples: mantenha o agente dentro do workspace, a menos que a tarefa realmente exija acesso mais amplo.

Perguntas frequentes

Por que o Codex às vezes exclui arquivos fora do diretório-alvo?

A investigação da OpenAI encontrou um modo de falha relacionado à limpeza de diretórios temporários. Em alguns casos, variáveis amplas do sistema, como $HOME, podem ser reutilizadas em trabalhos temporários, e caminhos de limpeza mal formatados podem apontar para dados reais do usuário em vez de diretórios descartáveis.

O que mudou no Codex após a investigação?

A OpenAI afirmou que o Codex agora verifica mais explicitamente os alvos de exclusão, usa padrões de diretórios temporários mais seguros, fortalece a detecção de operações destrutivas, melhora a revisão automática e torna o acesso total mais difícil de ser ativado acidentalmente. A empresa também criou avaliações direcionadas com base nas falhas observadas.

O que é o acesso total do Codex?

O acesso total remove as restrições normais da sandbox, permitindo que o Codex edite arquivos amplamente e execute comandos com acesso à rede sem os limites usuais de aprovação. A OpenAI alerta que isso aumenta significativamente o risco de perda de dados, vazamento e comportamento inesperado.

Revisão automática é o mesmo que acesso total?

Não. A revisão automática mantém a sandbox existente e envia solicitações de elevação qualificadas ao agente de revisão. O acesso total remove o limite da sandbox, portanto os dois modos oferecem níveis de proteção muito diferentes.

A revisão automática bloqueia comandos destrutivos?

A política atual da OpenAI afirma que a revisão automática foi projetada para identificar e bloquear operações destrutivas que apresentam risco de danos irreversíveis significativos, bem como riscos como sondagem de credenciais e roubo de dados. Ela revisa apenas operações que já exigem aprovação sob a sandbox e a política de aprovação atuais.

Qual modo de permissão a maioria dos usuários do Codex deve escolher?

A OpenAI recomenda que a maioria dos trabalhos locais comece com um modo baseado em aprovação regular. Ele permite edições normais dentro do workspace, ao mesmo tempo que exige revisão antes que o Codex ultrapasse esse limite ou acesse recursos restritos.

Após essas alterações, o Codex ainda pode cometer erros?

Pode. Essas medidas reduzem o risco, mas não garantem zero comportamento errôneo. Controle de versão, backups, permissões estreitas de workspace

e aprovações intencionais para operações de alto risco continuam sendo muito importantes.

Onde posso verificar as configurações de permissão e sandbox do Codex?

No aplicativo de desktop do ChatGPT ou na extensão do IDE, use os controles de permissão associados à tarefa. No Codex CLI, /permissions exibe os modos disponíveis, e a documentação oficial de configuração descreve sandbox_mode, approval_policy e approvals_reviewer.

Ferramentas relacionadas

• OpenAI Codex: Documentação oficial do Codex para fluxos de trabalho locais, IDE, desktop e nuvem.
• Codex CLI: O agente de codificação de linha de comando de código aberto da OpenAI e seu histórico de versões.
• Permissões do Codex: Documentação oficial sobre "aprovação mediante solicitação", "revisão automática", "acesso total" e modos de permissão relacionados.
• Revisão automática do Codex: Documentação sobre a revisão automática de solicitações de aprovação nos limites da sandbox.
• Sandbox do Codex: Documentação sobre

Referência oficial para read-only, workspace-write e danger-full-access.

• Regras do Codex: controle de política de comandos para permitir, solicitar ou bloquear padrões de comandos selecionados.

Links relacionados

• Atualização de segurança do Codex por Thibault Sottiaux: atualização de engenharia do Codex da OpenAI descrevendo o processo de investigação e as novas mitigações publicadas.
• Executando o Codex com segurança na OpenAI: visão geral da OpenAI sobre sandboxing, aprovações, controles de rede, configuração hospedada e auditabilidade.
• Aprovações e segurança do agente: guia detalhado sobre limites de sandbox, políticas de aprovação, caminhos protegidos e revisão de aprovações automáticas.
• Revisão automática do Codex: documentação oficial cobrindo condições de acionamento, processo de revisão, políticas para operações destrutivas e comportamentos de falha.
• Permissões do Codex: descrição oficial dos modos de permissão voltados ao usuário e avisos de acesso total.
• Changelog do Codex: histórico de versões registrando detecção de rm forçado mais forte, confirmação de acesso total e melhorias de segurança relacionadas.
• Repositório GitHub do OpenAI Codex: código-fonte, problemas, notas de versão e implementação do Codex CLI de código aberto.

Resumo

Após investigar casos raros em que poucas operações de limpeza destrutivas afetaram arquivos fora do escopo pretendido pelo usuário, a OpenAI reforçou o Codex. Os principais modos de falha envolviam manipulação de diretórios temporários, variáveis de ambiente excessivamente amplas, validação insuficiente de alvos e sessões com permissões excessivamente amplas, nas quais comandos incorretos podiam causar danos significativos.

As novas medidas de segurança adicionaram verificações de caminho de destino, manipulação mais segura de diretórios temporários, revisão mais forte de comandos destrutivos, avisos mais claros de acesso total e políticas aprimoradas de revisão automática. A OpenAI também está convertendo as falhas observadas

em tarefas repetíveis de avaliação e treinamento.

Essas mudanças reduzem a probabilidade de um agente de codificação transformar erros de limpeza comuns em grandes incidentes no sistema de arquivos, mas não tornam a execução irrestrita isenta de riscos.

Para a maioria do desenvolvimento local, a abordagem mais segura continua sendo manter o Codex dentro do sandbox do workspace e elevar as permissões somente quando a tarefa realmente exigir.