Mantenha os segredos fora do ambiente de trabalho e negue o acesso aos arquivos sensíveis. Comece combinando essas duas medidas.
O modo somente leitura, as aprovações e a opção de não participar do treinamento têm objetivos diferentes. Verifique cada controle separadamente para saber se ele pode impedir o acesso a arquivos secretos.
Verifique leitura, execução e transmissão separadamente
Remova os segredos desnecessários do ambiente de trabalho. Considere uma regra de leitura deny para os arquivos sensíveis.
Verifique quem analisa as aprovações. Evite ampliar os limites com Full access ou autorização para executar fora do sandbox.
Verifique separadamente a rede dos comandos, a transmissão ao modelo e o acesso do navegador ou de MCP.
A documentação da OpenAI sobre Permissions, Sandbox, aprovações, segurança e configuração foi revisada em 8 de outubro de 2026. Este guia se concentra em comandos dentro de um sandbox local. A configuração de exemplo não foi aplicada nem teve sua eficácia verificada em um computador real. Nenhuma configuração do dispositivo ou da conta foi alterada.
Conteúdo
- 1. Somente leitura, aprovações e configurações de treinamento
- 2. Manter os segredos fora do ambiente de trabalho
- 3. Exemplo de configuração para negar leituras
- 4. Padrões .env e lacunas a verificar
- 5. O que desativar a rede dos comandos bloqueia ou não
- 6. Variáveis de ambiente, sistemas operacionais e Cloud
- 7. Verificar com arquivos fictícios
- Perguntas frequentes
1. Somente leitura, aprovações e configurações de treinamento
Impedir alterações em arquivos é diferente de impedir sua leitura.
Modo que restringe a escrita. Não oculta como segredos o conteúdo dos arquivos que podem ser lidos.
Define onde a edição é permitida. Não necessariamente limita a leitura aos mesmos locais.
| Controle | O que controla principalmente | O que não garante por si só |
|---|---|---|
| Modo somente leitura | Se os arquivos podem ser alterados | Que arquivos secretos acessíveis não serão lidos |
| Política de aprovação | Quem analisa ações que ultrapassam um limite | Uma análise humana de cada leitura dentro do escopo permitido |
| Regras de negação de arquivos | Recusa de leituras e escritas nos caminhos especificados | Remover conteúdo já colado ou impedir o acesso por outras ferramentas |
| Restrições de rede dos comandos | Destinos de rede dos comandos executados no sandbox | Bloquear todo o tráfego de modelos, autenticação, navegadores, MCP e outros serviços |
| Configurações de treinamento | Se os dados processados são usados para melhorar modelos | Que os dados não serão processados nem transmitidos |
Mesmo com on-request, os comandos dentro do escopo permitido podem ser executados sem aprovação adicional. Para análise humana, verifique tanto a política de aprovação quanto quem recebe a solicitação de análise.
Como a análise automática por IA é diferente
approvals_reviewer = "auto_review" encaminha a análise correspondente à IA. Não é uma análise humana e não passa a exigir análise para cada ação que já era permitida.
Fonte: OpenAI: aprovações e limites do sandbox. O treinamento é tratado separadamente em configurações de treinamento do ChatGPT e Codex e informações confidenciais.
2. Manter os segredos fora do ambiente de trabalho
Uma alteração de interface pode exigir apenas código-fonte e dados fictícios. Chaves de API de produção, dados de clientes e documentos familiares não precisam estar nesse mesmo ambiente.
Mover os arquivos para outra pasta não basta. Se permissões amplas de leitura forem mantidas, esses arquivos ainda poderão estar acessíveis.
Inclua apenas o necessário na cópia de trabalho
Use entradas pequenas que reproduzam o problema, em vez de dados de produção.
Exemplos de configuração devem conter apenas nomes de campos. Verifique também logs, backups e histórico.
Verifique se outras pastas, o diretório pessoal, o armazenamento compartilhado ou aplicativos conectados estão acessíveis.
As regras de exclusão do Git impedem a leitura?
.gitignore especifica os arquivos não rastreados que o Git deve ignorar. Não remove as permissões de leitura do sistema operacional. Mesmo que uma ferramenta de busca normalmente ignore um arquivo, isso não garante que a leitura pelo caminho explícito será negada. Adicionar uma regra de exclusão também não afeta os arquivos que o Git já rastreia. Documentação do Git: o alcance de gitignore.
Instruções versus negação efetiva de acesso
Escrever «não leia segredos» em AGENTS.md pode fornecer instruções úteis de trabalho. Isso não cria restrições de acesso do sistema operacional por si só. Combine instruções com negação efetiva de acesso. Veja cuidados ao inserir informações em ferramentas de IA para exemplos de anonimização de entradas.
3. Exemplo de configuração para negar leituras
Os perfis de permissões são um recurso beta. Verifique os ambientes compatíveis e a configuração selecionada na sessão atual antes de usá-los.
read: leituraPermissão para ler o destino
write: ediçãoPermissão para escrever no destino
deny: negaçãoNega tanto a leitura quanto a escrita no destino
Atenção a conflitos com as configurações antigas do sandbox
Os perfis de permissões podem não ser usados quando as configurações antigas continuam ativas.
Verifique configurações em conflito e controles do administrador
Não misture as configurações antigas: default_permissions e [permissions] não foram concebidos para serem combinados com as configurações antigas sandbox_mode ou [sandbox_workspace_write]. Normalmente, se a configuração carregada contém sandbox_mode ou a inicialização usa --sandbox, o mecanismo antigo é utilizado. Os controles do administrador por meio de allowed_permission_profiles são uma condição separada.
O trecho abaixo é uma proposta ilustrativa de configuração que acrescenta negação de arquivos secretos e aprovação humana ao exemplo oficial limitado ao espaço de trabalho. Não substitua toda a sua configuração existente por ela. Verifique a compatibilidade da versão, as restrições da organização e os caminhos de execução necessários; depois, teste em um ambiente fictício.
Onde configurar: configurações do usuário e do projeto
~/.codex/config.toml
.codex/config.toml
Elas diferem no escopo e nas condições de carregamento. A configuração do projeto só é carregada em projetos confiáveis.
default_permissions = "project-private"
approval_policy = "on-request"
approvals_reviewer = "user"
[permissions.project-private]
extends = ":workspace"
[permissions.project-private.filesystem]
":root" = "deny"
":minimal" = "read"
[permissions.project-private.filesystem.":workspace_roots"]
".env" = "deny"
".env.production" = "deny"
"secrets" = "deny"
[permissions.project-private.network]
enabled = falseQuais caminhos este exemplo cobre?
Aplicado ao espaço de trabalho atual e a cada espaço adicional
.envDestinado à negação.env.productionDestinado à negaçãosecrets/ e seu conteúdoDestinado à negaçãosubfolder/.envVerificar separadamenteSegredos renomeados ou cópias nos logsVerificar separadamente:root nega a leitura. As exceções incluem :minimal para execução e os diretórios temporários permitidos pelo perfil herdado.
Herda o acesso de edição de :workspace e nega os caminhos específicos indicados acima. Este exemplo não detecta segredos inseridos nas saídas.
Nomes de perfis, vários espaços de trabalho e arquivos temporários
project-private é o nome escolhido para este exemplo. :workspace_roots aplica-se ao espaço de trabalho atual e aos adicionais, atingindo os caminhos indicados diretamente dentro de cada raiz. secrets atinge um arquivo ou uma subárvore com esse nome.
Esta configuração não impede todas as leituras fora do espaço de trabalho. Também é preciso evitar copiar segredos para o armazenamento temporário.
Fonte: OpenAI: configuração, negação e escopo dos perfis de permissões. Este artigo não relata a aplicação do exemplo em um computador real nem a verificação do isolamento.
4. Padrões .env e lacunas a verificar
Nomes exatos são adequados para segredos armazenados em locais conhecidos. Ao usar padrões, lembre-se de que *.env e .env.* são diferentes. Não presuma que o exemplo oficial **/*.env também nega .env.production sob as mesmas condições.
| Regra de exemplo | Destino pretendido | Verificar separadamente |
|---|---|---|
.env | Um arquivo com esse nome diretamente na raiz do espaço de trabalho | Subpastas e nomes de arquivo com sufixo adicionado |
.env.production | O arquivo de configuração de produção na raiz | Configurações de produção com outros nomes ou cópias |
secrets | O caminho com esse nome na raiz e seu conteúdo | Cópias em outros locais, como logs ou backups |
**/*.env | Arquivos terminados em .env em diferentes níveis de diretório | Nomes com sufixo, profundidade da varredura e alterações após a inicialização |
Verifique a profundidade dos diretórios e os arquivos adicionados após a inicialização
No Linux, WSL e Windows nativo, padrões de negação com ** irrestrito podem exigir uma expansão limitada antes da inicialização. A documentação oficial descreve definir glob_scan_max_depth como pelo menos 1 ou indicar a profundidade explicitamente com padrões como *.env, */*.env e */*/*.env. Se você usa diretórios mais profundos, verifique a cobertura até essa profundidade.
Alguns mecanismos de aplicação coletam os caminhos correspondentes antes da inicialização. Verifique se os arquivos criados depois são negados no sistema operacional, na versão e no ambiente de execução que você utiliza. Não trate padrões de negação como uma regra universal que necessariamente protegerá todos os segredos futuros.
Qual regra prevalece quando as permissões se sobrepõem?
Uma regra de caminho mais específica pode substituir uma regra mais ampla. A negação prevalece para o mesmo caminho, mas também pode existir uma permissão restrita dentro de uma negação ampla. Verifique as camadas adicionais de configuração e a herança dos perfis superiores.
Fontes: OpenAI: negar leituras com caminhos e padrões, ordem de carregamento da configuração. O arquivo do projeto .codex/config.toml só é carregado em projetos confiáveis. Diferencie o que está escrito em um arquivo do que está ativo na sessão atual.
5. O que desativar a rede dos comandos bloqueia ou não
Desativar a rede dos comandos restringe o uso de rede dos programas executados dentro do sandbox correspondente. Porém, as solicitações de modelos e autenticação do cliente Codex são separadas dos controles de rede dos comandos. A rede dos comandos estar desativada não prova que o código lido pelo Codex não será transmitido como contexto do modelo.
O que as restrições de rede dos comandos cobrem
Atividade de rede dos comandos, scripts e seus processos filhos.
Modelos e autenticação, busca na web, aplicativos conectados, MCP, navegador e Computer Use e tarefas na nuvem.
Para permitir a rede e restringir os destinos, você precisa ativar o proxy de rede, além de definir regras de domínio. Listar domínios permitidos em um perfil não ativa essas regras por si só.
| Rede dos comandos | Proxy | Resultado |
|---|---|---|
| Desativada | Qualquer configuração | A rede dos comandos não é permitida |
| Ativada | Desativado | A conexão direta é possível; as regras de domínio do perfil não se aplicam |
| Ativada | Ativado | O proxy aplica as regras de domínio e nega destinos externos se nenhum for permitido |
Segredos ainda podem ser enviados a um destino permitido. Restringir domínios não é o mesmo que inspecionar o conteúdo enviado. Ao aprovar execução fora do sandbox, não presuma que as regras atuais de negação continuarão protegendo você sem mudanças. Verifique o que essa aprovação amplia. OpenAI: permissões de rede e requisitos do proxy.
6. Variáveis de ambiente, sistemas operacionais e Cloud
Segredos não se limitam a arquivos. Se o shell contém uma chave de API, um processo filho pode usar seu valor por meio de variáveis de ambiente herdadas, mesmo com acesso ao arquivo negado. A herança do ambiente é gerenciada separadamente com shell_environment_policy.
Exclusão automática de variáveis: true versus false
true | PadrãoNão aplica a exclusão automática de variáveis cujos nomes contêm KEY, SECRET ou TOKEN
falseAplica essa exclusão automática
ignore_default_excludes. É separada das regras de negação de arquivos e filtra pelo nome da variável; não detecta todos os segredos.Isso não protege variáveis com outros nomes nem valores que os programas obtêm de outros lugares. set é aplicado depois da exclusão e pode restaurar variáveis excluídas. OpenAI: herança do ambiente e precedência.
Windows: verifique também a implementação do sandbox
Os perfis de permissões locais estão documentados para macOS, Linux, WSL e Windows nativo, mas suas implementações diferem. No Windows, o sandbox elevado é descrito como a opção mais robusta. O sandbox não elevado oferece isolamento de rede mais fraco e não consegue aplicar algumas políticas de isolamento de leitura e escrita. Segundo a documentação, políticas não compatíveis fazem a execução ser recusada. Um erro não é motivo para mudar para Full access. OpenAI: aplicação por sistema operacional.
Cloud: não reutilize as configurações locais sem alterações
Verifique separadamente as configurações do ambiente específico do Codex Cloud. Não presuma que os perfis locais se aplicam automaticamente a todo o Cloud ou ao ambiente de nuvem do dot. Não reutilize a proposta de configuração local deste artigo sem alterações como configuração de nuvem. Veja Codex Remote, Cloud e requisitos de conexão do PC para entender as diferenças entre locais de execução.
7. Verificar com arquivos fictícios
«Pedi para não ler», «salvei a configuração» e «a leitura foi efetivamente negada» são evidências diferentes. Não é necessário testar fazendo o Codex ler segredos reais. O trecho abaixo é um plano de verificação para o usuário ou administrador, não um relato de testes neste dispositivo.
- Registre o ambiente: Anote a versão do Codex, o sistema operacional, o local de execução e as permissões selecionadas. Na CLI, verifique o escopo do espaço de trabalho com
/statuse as permissões selecionadas com/permissions. - Verifique conflitos de configuração: Revise as configurações do usuário, do projeto confiável, o perfil selecionado, os parâmetros de inicialização e as restrições do administrador. Não cole arquivos de configuração completos nem valores secretos na conversa para diagnóstico.
- Prepare arquivos fictícios: Em um espaço de trabalho separado e sem segredos, crie arquivos que devem ser permitidos e negados. Use marcadores fictícios como conteúdo.
- Verifique tanto a permissão quanto a negação: Pela mesma via de execução, confirme que os arquivos permitidos podem ser lidos e que leituras negadas geram erro. O Codex decidir voluntariamente não ler um arquivo não comprova uma negação efetiva.
- Teste locais diferentes: Verifique arquivos fictícios na raiz, em subpastas, com nomes que incluem sufixos e criados após a inicialização. Não aprove uma ação que contorne a negação. Se uma leitura inesperada funcionar, pare de usar esse ambiente e investigue.
- Verifique também as saídas: Verifique se testes ou builds imprimem segredos nos logs ou passam as mesmas informações a outras ferramentas MCP, navegadores ou aplicativos conectados.
As informações disponíveis variam conforme a versão da CLI e a interface; verifique a saída real, em vez de confiar nos nomes dos comandos. A CLI oficial também oferece verificações específicas por sistema operacional por meio de codex sandbox. Antes de considerá-las equivalentes, verifique se as configurações testadas com um comando auxiliar correspondem às ativas na sua sessão habitual de desktop ou IDE. OpenAI: testar o sandbox.
Adicionar regras de negação depois não desfaz o conteúdo já lido. Verifique separadamente o armazenamento de conversas anteriores, logs e arquivos, além das configurações de treinamento. Uma leitura bem-sucedida de um arquivo não comprova, por si só, divulgação a terceiros. Avalie separadamente o que foi lido, para onde foi e se as credenciais exigem atenção.
Usuários também solicitaram maneiras de excluir arquivos secretos em uma solicitação pública no Codex. Isso demonstra uma preocupação real, mas não prova que o recurso ainda seja incompatível hoje. As afirmações deste artigo sobre especificações se baseiam na documentação oficial atual de Permissions, e não em publicações antigas.
Perguntas frequentes
O modo somente leitura impede o envio de .env?
O modo somente leitura não oferece essa garantia: ele restringe alterações. Para impedir que conteúdo legível de .env se torne contexto do modelo, verifique separadamente a negação de leitura do arquivo e um ambiente de trabalho sem segredos.
.gitignore ou AGENTS.md são suficientes?
Eles não substituem a negação efetiva de leituras. Regras de exclusão do Git, instruções de trabalho e permissões impostas pelo sistema operacional são mecanismos separados. Verifique com arquivos fictícios se a negação funciona no ambiente de execução atual.
Desativar a rede faz o Codex funcionar inteiramente no dispositivo?
Não. As restrições de rede dos comandos não desativam a comunicação com modelos ou serviços de autenticação. As configurações de navegador, MCP, aplicativos conectados e nuvem também são separadas.
Este exemplo protege completamente os segredos no Windows?
A proteção completa não é garantida. É preciso verificar a compatibilidade do recurso beta, a implementação do sandbox do sistema operacional, as camadas de configuração reais, os caminhos e as ferramentas executadas. O exemplo deste artigo não foi aplicado nem testado em um computador real.
