OpenAI alerta que acesso total do Codex pode resultar em perda de dados

Introdução

O agente de codificação Codex da OpenAI é capaz de ler arquivos, editar repositórios de código, executar comandos e interagir com ferramentas de desenvolvimento na máquina do usuário. Essas funcionalidades o tornam adequado para trabalhos de engenharia de longo prazo, mas também significam que sua segurança depende em grande parte das permissões escolhidas pelo usuário e dos limites da sandbox.

A AIBase noticiou que a OpenAI investigou alguns casos em que o Codex excluiu arquivos do diretório pessoal do usuário. De acordo com a reportagem, as sessões afetadas foram executadas com acesso total ativado e sem proteção de sandbox.

A explicação técnica específica da reportagem da AIBase envolve uma interação incorreta entre a lógica de diretórios temporários e a variável de ambiente $HOME. A OpenAI ainda não publicou uma análise pública pós-incidente que confirme esse processo exato.

O que a OpenAI confirmou publicamente é mais abrangente e igualmente importante: sua documentação oficial do Codex alerta que o acesso total remove os limites do diretório do projeto, podendo levar a operações destrutivas inesperadas e, consequentemente, à perda de dados.

Portanto, a recomendação direta é: a menos que o acesso irrestrito seja realmente necessário e esteja protegido por outra camada de isolamento, o Codex deve ser restrito a um espaço de trabalho em sandbox.

O que envolve o problema relatado de exclusão de arquivos

O relatório fornecido pela AIBase descreve o problema como ocorrendo sob uma combinação específica de configurações:

1. O Codex recebeu acesso total à máquina local.
2. Os limites da sandbox foram desativados.
3. Mecanismos de proteção, como aprovação ou revisão automática, não foram ativados.
4. A tarefa tentou criar ou usar um diretório de trabalho temporário.
5. Um erro envolvendo a variável de ambiente $HOME supostamente fez com que o diretório pessoal do usuário fosse considerado um alvo de exclusão.

No macOS e Linux, $HOME geralmente aponta para o diretório pessoal do usuário atual. Esse diretório pode conter:

• Pastas de Área de Trabalho e Documentos.
• Repositórios de código-fonte.
• Configuração e chaves SSH.
• Configurações de aplicativos.
• Arquivos de perfil do shell.
• Bancos de dados locais.
• Arquivos pessoais.
• Pastas de sincronização em nuvem.

Portanto, uma exclusão recursiva com base em um caminho incorreto poderia afetar uma área muito maior do que apenas o projeto ativo atual.

O que o alerta oficial da OpenAI contém

A documentação atual da OpenAI sobre o sandbox no Windows afirma que executar o Codex com acesso total significa que o agente não está mais limitado ao diretório do projeto. Ele pode executar operações destrutivas inesperadas que resultam em perda de dados.

A documentação de permissões da OpenAI define três perfis de permissão integrados:

Perfil de Permissão	Comportamento do Sistema de Arquivos	Cenário de Uso
:read-only	A execução de comandos locais permanece somente leitura	Inspeção de repositório, planejamento e revisão
:workspace	Permite gravação apenas na raiz do espaço de trabalho ativo e no diretório temporário do sistema	Codificação regular e manutenção de repositório
:danger-full-access	Remove os limites locais da sandbox	Apenas quando o acesso irrestrito é intencional e isolado separadamente

A documentação oficial também descreve que o seguinte padrão é de alto risco:

codex --dangerously-bypass-approvals-and-sandbox

O mesmo comportamento pode ser alcançado através de um alias:

codex --yolo

Esses comandos desabilitam simultaneamente a sandbox e os prompts de aprovação. Eles estão listados aqui para que os usuários identifiquem e evitem essa configuração perigosa, e não para recomendação de uso.

A OpenAI classifica esse modo como sem sandbox e sem aprovação, afirmando que não é recomendado para uso normal.

Por que o acesso total altera drasticamente o nível de risco

Agentes de codificação não apenas sugerem comandos. No modo de agente local, eles podem executar esses comandos diretamente.

Ao usar a sandbox do espaço de trabalho, o sistema operacional e as políticas do Codex restringem o escopo de gravação dos comandos. Um comando errôneo ainda pode danificar o projeto atual, mas não deve modificar diretórios não relacionados arbitrariamente.

Já com o acesso total ativado, os limites técnicos deixam de existir. O modelo e seus comandos de shell podem ter acesso a:

• Todo o diretório pessoal.
• Outros repositórios de código.
• Discos montados.
• Pastas de sincronização em nuvem.
• Arquivos de credenciais.
• Configurações do gerenciador de pacotes.
• Dados de aplicativos locais.
• Ferramentas externas acessíveis pela conta do usuário.

É por isso que apenas a formulação do prompt não é suficiente como medida de controle. Dizer ao agente "edite apenas esta pasta" é uma instrução comportamental, enquanto a sandbox é o limite imposto.

A OpenAI considera a sandbox e a aprovação como controles complementares:

• Sandbox determina o que o agente pode acessar tecnicamente.
• Política de aprovação determina quando o agente deve parar e solicitar permissão.

Remover ambos os controles constitui a configuração de maior risco.

Prompts de aprovação e revisão automática não substituem a sandbox

Os prompts de aprovação podem capturar riscos antes da execução de operações perigosas, mas não substituem o isolamento do sistema de arquivos.

O usuário pode aprovar comandos incorretos. O revisor automático só pode avaliar as operações encaminhadas através do sistema de aprovação.

A documentação da OpenAI explica que a revisão automática realiza análises de risco em solicitações de aprovação qualificadas, incluindo operações destrutivas, acesso a credenciais, roubo de dados e enfraquecimento persistente da segurança.

Uma configuração típica de revisão automática é:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Isso reduz o cansaço de aprovação enquanto mantém uma camada de revisão.

No entanto, quando o Codex é iniciado no modo que ignora aprovação e sandbox, o revisor pode não ter limites de autoridade para impor.

Um modo mais seguro é:

1. Manter a sandbox do espaço de trabalho ativada.
2. Usar aprovação sob demanda ou revisão automática.
3. Adicionar exceções de escopo restrito apenas quando necessário.
4. Evitar acesso irrestrito na máquina host.

Modo padrão recomendado pela OpenAI

A OpenAI recomenda configurações padrão diferentes com base no fato de o diretório de trabalho estar sob controle de versão:

• Pasta com controle de versão: Gravação no espaço de trabalho + aprovação sob demanda.
• Pasta sem controle de versão: Modo somente leitura.

Para repositórios regulares, o comando CLI explícito é:

codex --sandbox workspace-write --ask-for-approval on-request

Para apenas inspecionar sem editar arquivos:

codex --sandbox read-only --ask-for-approval

### Aprovação sob demanda

Essas configurações limitam o Codex a limites de execução definidos, ao mesmo tempo que permitem que o usuário aprove operações especiais.

A OpenAI também documentou soluções de compromisso para tarefas não supervisionadas. É possível desabilitar os prompts de aprovação enquanto a sandbox permanece ativa:

```bash
codex --sandbox workspace-write --ask-for-approval never

Nesse modo, o Codex executa as tarefas da melhor forma possível dentro dos limites do espaço de trabalho, sem solicitar permissão para operações fora do escopo. Isso é muito mais seguro do que desabilitar tanto a aprovação quanto a sandbox.

Como desabilitar o acesso total no Codex

No aplicativo de desktop ChatGPT, no Codex CLI e nas integrações de IDE, os controles específicos variam ligeiramente, mas o princípio é o mesmo.

Passo 1: Abrir o controle de permissões

Na interface do desktop ou IDE, abra o seletor de permissões próximo ao compositor de prompts.

Selecione o modo de restrição do espaço de trabalho ou o modo de sandbox padrão, em vez de acesso total.

Passo 2: Usar acesso ao espaço de trabalho para codificação normal

Selecione o modo que permite ao Codex gravar apenas no projeto ativo ou na raiz do espaço de trabalho.

No CLI, use:

codex --sandbox workspace-write --ask-for-approval on-request

Passo 3: Usar modo somente leitura para revisão inicial

Ao abrir um repositório desconhecido, use primeiro:

codex --sandbox read-only --ask-for-approval on-request

Deixe o Codex revisar o código e propor soluções antes de conceder permissão de gravação.

Passo 4: Confirmar os limites atuais

No Codex

No meio, use a interface de status ou permissões para confirmar quais diretórios são considerados diretórios raiz de espaço de trabalho graváveis.

Não presuma que as pastas exibidas no editor são os únicos diretórios acessíveis ao agente.

Etapa 5: Mantenha a aprovação habilitada para operações fora dos limites

Use aprovação sob demanda para comandos que exigem acesso adicional.

Para reduzir o atrito no fluxo de trabalho, considere a revisão automática, em vez de remover completamente a aprovação.

Etapa 6: Reinicie sessões existentes com acesso total

Alterações no arquivo de configuração podem não restringir retroativamente processos em execução.

Após alterar as configurações:

1. Interrompa a sessão atual do Codex.
2. Confirme a configuração.
3. Reinicie o Codex a partir do diretório do projeto esperado.
4. Verifique novamente as permissões atuais antes de continuar.

Configurações mais seguras do config.toml

O Codex suporta configuração através do seguinte caminho:

~/.codex/config.toml

Para sistemas de sandbox já configurados, as configurações padrão mais seguras são:

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

Uma configuração de revisão mais rigorosa é:

approval_policy = "on-request"
sandbox_mode = "read-only"

É possível adicionar revisão automática sem remover a sandbox:

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

A OpenAI também documenta o sistema de perfis de permissão como um sistema de configuração beta mais novo. Uma configuração simples de espaço de trabalho é:

default_permissions = ":workspace"

Uma configuração padrão somente leitura é:

default_permissions = ":read-only"

Aviso de configuração: A OpenAI observa que o sistema mais novo de perfis de permissão é incompatível com a configuração antiga sandbox_mode. Configure apenas um dos sistemas.

Além disso; nunca coloque ambos os métodos na mesma configuração ativa esperando que eles se combinem automaticamente.

Exemplo: Restringir gravação ao espaço de trabalho e proibir arquivos .env

Para usuários testando o sistema beta de perfis de permissão, a OpenAI oferece políticas personalizadas que estendem os limites do espaço de trabalho integrado.

Um arquivo de configuração de edição de projeto pode proibir o acesso a arquivos de ambiente enquanto mantém o espaço de trabalho gravável:

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = false

Esta política:

• Mantém arquivos comuns do projeto graváveis.
• Preserva os mecanismos de proteção do espaço de trabalho integrado.
• Proíbe o acesso a arquivos .env correspondentes.
• Desabilita o acesso à rede para comandos.

Para muitas tarefas locais de codificação, isso é um ponto de partida melhor do que conceder amplo acesso a toda a máquina.

Medidas de controle empresarial para bloquear acesso total

As organizações podem usar requisitos gerenciados para impedir que usuários escolham o modo de sandbox irrestrito.

A OpenAI demonstra uma lista de permissões como a seguinte:

allowed_sandbox_modes = ["read-only", "workspace-write"]

Isso impede que o acesso total seja uma opção de sandbox disponível em ambientes gerenciados.

O sistema mais novo de perfis de permissão também pode ser centralmente restrito. Administradores podem definir perfis aprovados e omitir :danger-full-access do conjunto permitido.

Isso é útil porque as políticas de segurança não devem depender inteiramente de cada desenvolvedor lembrar de selecionar o modo correto.

Fluxo de trabalho diário mais seguro para operações de código

Um fluxo de trabalho prático mantém a maior parte da velocidade do Codex sem expor todo o sistema host.

1. Trabalhe em repositórios dedicados

Inicie o Codex a partir do diretório do projeto (não do diretório inicial ou de uma pasta pai que contenha projetos não relacionados).

Evite caminhos amplos, como:

~

ou:

/

como espaço de trabalho ativo.

2. Use controle de versão antes de delegar

A OpenAI recomenda usar branches de funcionalidade e manter git status limpo antes de entregar trabalho ao Codex.

Um fluxo de preparação simples é:

git status
git switch -c codex/nome_da_tarefa
git add -A
git commit -m "Ponto de verificação antes da tarefa do Codex"

Ajuste o nome do branch e a mensagem de commit conforme o projeto.

3. Faça commits frequentes

Commits pequenos facilitam a revisão e reversão de alterações individuais.

Não espere até o final de uma sessão autônoma longa para criar o primeiro ponto de verificação recuperável.

4. Revise comandos e diferenças

Trate a saída do Codex como uma solicitação de pull:

• Verifique os comandos propostos.
• Revise as diferenças nos arquivos.
• Execute testes.
• Confirme os caminhos de modificação.
• Verifique exclusões acidentais.
• Registre decisões importantes.

5. Use árvores de trabalho ou contêineres para tarefas arriscadas

Para grandes refatorações, experimentos de dependência, alterações no sistema de build ou tarefas de limpeza, isole ainda mais o agente.

As opções incluem:

• Árvores de trabalho Git.
• Máquinas virtuais descartáveis.
• Contêineres de desenvolvimento.
• Contêineres Docker.
• Contas de desenvolvimento temporárias com permissões limitadas.

A OpenAI fornece um exemplo de contêiner de desenvolvimento seguro para cenários onde o contêiner é projetado...

Limites de isolamento externo.

6. Mantenha backups em locais inacessíveis ao agente

O controle de versão protege arquivos de repositório rastreados, mas não protege todos os arquivos no computador.

Use sistemas de backup que o Codex não possa modificar através da mesma conta de usuário ou sistema de arquivos montado. Exemplos incluem backups offline, snapshots imutáveis ou serviços de backup remoto com suporte a histórico de versões.

Medidas após exclusão acidental

Quando um arquivo é excluído recentemente, operações de gravação subsequentes podem sobrescrever blocos de disco recuperáveis.

Tome as seguintes precauções:

1. Interrompa imediatamente a sessão do Codex.
2. Pare ferramentas de build, gerenciadores de pacotes, clientes de sincronização e outros processos que gravam no disco afetado.
3. Não reinstale software no drive afetado.
4. Verifique histórico Git, árvores de trabalho, histórico local do editor, snapshots e histórico de versões na nuvem.
5. Priorize a recuperação a partir de backups íntegros e conhecidos.
6. Para dados insubstituíveis, considere serviços profissionais de recuperação de dados antes de tentar operações repetidas de recuperação "faça você mesmo".

Para código-fonte rastreado, comece com uma verificação não destrutiva:

git status
git diff
git log --oneline --all

Não execute comandos destrutivos de recuperação Git antes de confirmar quais arquivos e commits ainda estão disponíveis.

O que a OpenAI está melhorando

O AIBase relata que a OpenAI está atualizando o conteúdo de aviso para acesso total e fortalecendo as medidas de proteção, enquanto prepara relatórios mais detalhados de análise de incidentes.

A documentação pública atual da OpenAI já inclui avisos explícitos de que o acesso total pode levar à perda de dados, além de recomendar o uso de limites de sandbox, políticas de exceção rigorosas, fluxos de aprovação, perfis de permissão, pontos de verificação de controle de versão e ambientes de desenvolvimento isolados.

Até o momento da redação, não há nenhum relatório público oficial de análise post-mortem sobre o evento exato de exclusão do diretório $HOME.

Isso significa que os usuários devem confiar nos controles atualmente disponíveis, em vez de esperar por explicações futuras:

• Não habilite acesso total por padrão.
• Mantenha os limites do projeto intactos.
• Retenha aprovação para operações elevadas.
• Use controle de versão e backups.
• Isole automações de alto risco.

Distinções importantes

Erros de modelo não são o único risco

Comportamentos destrutivos podem surgir de várias camadas:

• O modelo selecionou um comando inseguro.
• Expansão de variável para um caminho inesperado.
• O shell analisou aspas incorretamente.

O script de limpeza apontava para o diretório errado.

• A ferramenta foi executada a partir de um diretório de trabalho inesperado.
• O usuário aprovou o comando sem verificar.
• A sandbox estava desativada.

Portanto, a segurança não pode depender apenas da precisão do modelo.

A maioria das tarefas de codificação não requer acesso total

Edições comuns, testes, pesquisas e execução de comandos locais geralmente podem ser realizados dentro dos limites do espaço de trabalho.

Quando uma tarefa precisar de acesso adicional a um diretório ou destino de rede específico, recomenda-se adicionar exceções precisas, em vez de expor todo o sistema.

A revisão automática reduz o atrito operacional, mas não altera as consequências

A revisão automática ajuda a categorizar as solicitações de aprovação, mas não torna a execução irrestrita inofensiva.

A sandbox continua sendo o mecanismo de controle local mais forte, pois limita as operações que um comando pode realizar, mesmo quando o próprio comando contém erros.

Perguntas frequentes

O Codex pode

excluir arquivos do meu computador?

Quando o Codex tem permissão de gravação, ele pode editar e excluir arquivos. No modo de espaço de trabalho, essas operações são limitadas ao diretório raiz gravável configurado; no modo de acesso total, as restrições da sandbox local são removidas, aumentando o impacto potencial de comandos errôneos.

A OpenAI confirmou a vulnerabilidade exata de exclusão do $HOME?

O relatório da AIBase atribui essa interpretação à investigação da OpenAI. A documentação pública da OpenAI confirma um risco mais amplo de perda de dados no modo de acesso total, mas, até 17 de julho de 2026, não há uma análise técnica pós-incidente pública que confirme o mecanismo exato do $HOME.

Qual é o modo de permissão mais seguro para o Codex?

Quando o Codex precisar apenas verificar o repositório, use o modo :read-only. Para codificação comum, os modos :workspace ou workspace-write, combinados com aprovação sob demanda, oferecem um equilíbrio prático entre produtividade e controle de segurança.

Usar --yolo é seguro?

--yolo é um alias que contorna a aprovação e a sandbox. A OpenAI o descreve como um modo de alto risco, sem sandbox e sem aprovação, portanto, não deve ser usado em máquinas normais que contenham arquivos importantes.

O Codex pode ser executado automaticamente sem solicitações de aprovação, mantendo a sandbox?

Sim. A documentação da OpenAI indica que --ask-for-approval never é compatível com o modo sandbox. Por exemplo, codex --sandbox workspace-write --ask-for-approval never mantém os limites do espaço de trabalho enquanto evita prompts interativos de aprovação.

O Git pode me proteger contra todos os tipos de perda de dados do Codex?

Não. O Git pode recuperar arquivos do repositório que foram rastreados e confirmados, mas não protege automaticamente arquivos não rastreados, credenciais, documentos pessoais, bancos de dados externos ou pastas não relacionadas. Para quaisquer dados que não estejam armazenados com segurança no controle de versão, use soluções de backup independentes.

A revisão automática pode substituir a sandbox?

Não. A revisão automática avalia solicitações de aprovação qualificadas, enquanto a sandbox impõe limites de sistema de arquivos e rede. Sempre que possível, mantenha ambos os controles, em vez de tratar um como substituto do outro.

Devo usar o modo de acesso total dentro de um contêiner?

Isso é razoável quando o contêiner ou a máquina virtual é projetado especificamente como um perímetro de segurança externo e não contém dados montados sensíveis. Revise cuidadosamente os pontos de montagem, credenciais, acesso à rede e integração com o host, pois o modo de acesso total ainda pode corromper ou vazar qualquer conteúdo acessível dentro desse ambiente.

Ferramentas relacionadas

• Codex CLI: Agente de codificação local de linha de comando da OpenAI para trabalho em repositórios e automação.
• Codex Permissions: Documentação oficial dos modos somente leitura, espaço de trabalho e acesso total.
• Codex Sandbox: Explica como impor limites de sistema de arquivos e rede.
• Repositório GitHub do Codex: Repositório oficial de código aberto do Codex CLI.
• Visual Studio Code Dev Containers: Execute fluxos de trabalho de desenvolvimento em ambientes de contêiner isolados.
• Git: Fornece histórico de versões, ramificações, diffs e reversões para arquivos de origem rastreados.

Links relacionados

Agent Approvals and Security: Guia oficial sobre modos de sandbox, políticas de aprovação, revisão automática e configurações perigosas.

• Codex Permissions: Referência oficial para perfis de privilégio mínimo.
• Codex Sandboxing: Explica os limites de projeto e o comportamento da sandbox em todas as plataformas do Codex.
• Windows Sandbox for Codex: Contém o aviso explícito da OpenAI de que o acesso total pode levar a operações destrutivas e perda de dados.
• Running Codex Safely at OpenAI: Descreve os mecanismos de controle usados internamente pela OpenAI para execução restrita e revisão.
• Codex CLI Documentation: Instruções oficiais de instalação e uso local.
• Repositório GitHub do OpenAI Codex: Código-fonte, relatórios de problemas, política de segurança e informações de versão.

Resumo

O incidente relatado de exclusão de arquivos pelo Codex ocorreu sob as condições de execução de maior risco: acesso total e sem limites de sandbox. A AIBase descreveu um caso suspeito de falha de limpeza relacionada ao $HOME, enquanto a documentação pública da OpenAI confirma um fato mais amplo: o acesso irrestrito pode causar operações destrutivas inesperadas e perda de dados.

Para a maioria dos desenvolvedores, o trabalho rotineiro em repositórios de código não exige acesso total. Gravação restrita ao espaço de trabalho, aprovação sob demanda, pontos de verificação de controle de versão e ambientes isolados oferecem modos de execução mais seguros sem comprometer as principais capacidades de codificação do Codex.

Ao executar tarefas não supervisionadas, os usuários podem desabilitar os prompts de aprovação enquanto mantêm a sandbox do espaço de trabalho. Isso é muito mais seguro do que contornar ambas as proteções.

A regra prática é simples: conceda ao Codex acesso apenas aos projetos necessários, não à máquina inteira.