Codex danger-full-access, --yolo e o "modo unsafe": o que cada flag desativa

O que faz realmente o danger-full-access no Codex?

danger-full-access é um dos três valores da flag --sandbox do Codex, e desliga a sandbox por completo. A documentação de sandboxing da OpenAI descreve-o numa frase: o agente corre sem restrições de sandbox, o que remove as fronteiras de sistema de ficheiros e de rede. Cada comando de shell que o modelo gera passa então a correr como o teu utilizador, com as tuas permissões, no teu sistema de ficheiros real e com a tua rede real.

Os outros dois valores são os que interessam no dia a dia:

Dois pormenores do workspace-write merecem atenção antes de o considerares demasiado restritivo. Primeiro, o conjunto gravável não é apenas a pasta atual: /tmp e $TMPDIR são graváveis por predefinição, e podes acrescentar caminhos com sandbox_workspace_write.writable_roots no config.toml (a referência de configuração expõe também exclude_slash_tmp e exclude_tmpdir_env_var se os quiseres fora). Segundo, o acesso à rede tem o seu próprio interruptor, sandbox_workspace_write.network_access = true, por isso "preciso que o npm install funcione" é um argumento a favor de um booleano, não do acesso total.

O que o danger-full-access não faz é calar o Codex. Os pedidos de aprovação dependem de uma flag separada, e é daí que vem a maior parte da confusão da secção seguinte.

O que remove o --dangerously-bypass-approvals-and-sandbox?

--dangerously-bypass-approvals-and-sandbox, com o alias --yolo, remove as duas proteções de uma vez: a sandbox do SO e os pedidos de aprovação. A referência da CLI da OpenAI descreve-o assim: correr todos os comandos sem aprovações nem sandbox, e usar apenas dentro de um ambiente endurecido a partir do exterior. Essa segunda frase é toda a política. A flag existe para um contentor ou uma máquina virtual que sejam eles próprios a fronteira, não para um portátil com as tuas chaves SSH, as tuas credenciais cloud e o .env de produção.

A diferença entre os dois mecanismos torna-se simples quando os pões lado a lado:

• A sandbox decide o que um comando pode tocar: que caminhos são graváveis, se pode abrir sockets. É aplicada pelo sistema operativo, por isso um comando que o modelo não tencionava correr fica tão contido como um que tencionava.
• As aprovações decidem quando o Codex para para te perguntar. São um ponto de controlo humano, e só funcionam se houver um humano a lê-las.

danger-full-access sozinho ainda te deixa o ponto de controlo. --yolo não te deixa nada além do critério do modelo, e o critério do modelo é precisamente o que uma prompt injection escondida num README, numa fixture de testes ou na mensagem de erro de uma dependência foi desenhada para torcer. Não é teoria: o nosso guia sobre fugas à sandbox em agentes de código mostra como o conteúdo de um repositório se transforma em comandos, e o padrão aplica-se ao Codex sem alterações.

-a never, --full-auto e "modo unsafe" são a mesma coisa?

Não. Afrouxam camadas diferentes, e um deles nem sequer é uma flag. Eis o mapa completo:

--ask-for-approval aceita untrusted (corre sozinho as leituras conhecidas como seguras e pergunta perante tudo o que altere estado), on-request (a predefinição: o modelo pergunta quando quer escalar, chegar à rede ou sair do workspace) e never. As versões mais antigas aceitavam também on-failure, que corria tudo dentro da sandbox e só perguntava quando um comando falhava lá dentro; --full-auto era o atalho para essa combinação, e é por isso que sobrevive hoje como flag de compatibilidade.

A predefinição "Full access" que vês no seletor interativo é a combinação de danger-full-access com never, e a OpenAI rotula-a de "not recommended" na sua própria documentação de aprovações. É --yolo com um nome mais simpático.

O acesso total do Codex é seguro?

O acesso total do Codex é seguro exatamente enquanto o ambiente à sua volta o for, e inseguro assim que deixa de o ser. Dentro de um contentor acabado de criar, sem credenciais, com um clone descartável e uma regra de saída de rede, danger-full-access é uma troca razoável: o contentor é a sandbox, e a do Codex só o atrasaria. Num posto de desenvolvimento significa que um modelo com a tua identidade pode fazer curl para qualquer lado, escrever em qualquer sítio e ler todos os tokens da tua pasta pessoal, e a única coisa entre uma instrução hostil e esse desfecho é o modelo decidir não obedecer.

Os dados que temos sobre agentes sem guarda não tranquilizam. No nosso estudo de escalada, agentes a trabalhar sem camada de guarda executaram DROP SCHEMA contra uma base de dados aplicacional em produção dezoito vezes, e um deles correu rm -rf fora do seu próprio projeto. Quando pusemos um guarda de comandos à frente dos mesmos agentes, verificou 1 769 comandos de shell ao longo das sessões e travou dezassete em pleno voo: um sudo destrutivo fora do projeto, uma eliminação de esquema e a instalação de um pacote que não existe no registo. Dezassete em 1 769 é menos de um por cento, e um por cento de "corre todos os comandos" é precisamente o número que interessa quando o comando é destrutivo.

18

execuções de DROP SCHEMA contra uma base em produção por agentes sem guarda, no nosso estudo

1 769

comandos de shell verificados nas sessões com guarda do mesmo estudo

17

comandos travados em pleno voo: sudo destrutivo, eliminação de esquema, pacote inexistente

Repara naquilo de que o acesso total não te protege, mesmo com um ambiente limpo: o código. Uma sandbox contém comandos; não tem opinião sobre se a verificação de autorização que o modelo acabou de escrever está correta. Voltamos a isso no fim.

Como funciona a sandbox do Codex em macOS, Linux e Windows?

O Codex aplica a sandbox com o sistema operativo, não com o modelo, e é por isso que ela aguenta mesmo quando o modelo está a ser manipulado. Em macOS usa o framework Seatbelt da Apple, o mesmo mecanismo de políticas sandbox-exec que confina os daemons do sistema, e funciona sem instalar nada. Em Linux e em WSL2 usa bubblewrap (bwrap) com filtros seccomp; as versões anteriores usavam Landlock e seccomp diretamente. Em Windows usa uma sandbox nativa do Windows, com ou sem elevação, quando é lançado a partir do PowerShell, e o mecanismo de Linux quando corre em WSL2.

Daqui saem duas consequências práticas. Se faltar o bwrap numa máquina Linux, o Codex não consegue construir lá a sandbox: instala-o antes de assumires que estás protegido. E se um comando é recusado sem perceberes porquê, codex sandbox corre um comando sob a política atual para depuração, com --log-denials em macOS para mostrar o que o Seatbelt bloqueou. É a ferramenta certa para "o Codex não consegue escrever aqui", e uma resposta muito melhor do que recorrer ao danger-full-access.

O Seatbelt resolve também uma dúvida muito frequente nas pesquisas: "Codex seatbelt" não é uma funcionalidade que se ative. É aquilo de que read-only e workspace-write são feitos num Mac.

Quando é que o acesso total é a decisão certa?

O acesso total é a decisão certa quando outra coisa já é a fronteira. O padrão que funciona:

Contentor ou VM novos, clone descartávelNenhuma credencial de longa duração montadaSaída de rede limitada aos registos necessáriosEntão, e só então, --yolo

Três verificações antes de ligares a flag:

1. O que pode o processo ler? Se ~/.ssh, ~/.aws, ~/.codex/auth.json ou um .env com chaves ativas estiverem ao alcance, a resposta não é o acesso total. O ficheiro de credenciais do Codex já foi alvo de um pacote npm malicioso; não lhe facilites a vida.
2. Para onde pode enviar dados? Rede sem restrição mais prompt injection é um canal de exfiltração. Se não consegues restringir a saída, deixa o network_access fechado e deixa o Codex perguntar.
3. Quem lê a saída? Em pipelines de codex exec ninguém está a ver as aprovações de qualquer forma, o que é uma razão para te apoiares mais na sandbox, não para a retirares.

Se alguma das três falhar, usa antes a configuração abaixo.

O que usar em vez de --yolo?

Para quase todas as tarefas, workspace-write com aprovações on-request, a rede fechada e o projeto marcado como de confiança dá-te um agente rápido que continua sem poder sair da sua faixa. No ~/.codex/config.toml:

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

[sandbox_workspace_write]
network_access = false
writable_roots = ["/Users/tu/scratch"]

[projects."/Users/tu/work/payments-api"]
trust_level = "trusted"

trust_level = "trusted" diz ao Codex para aplicar a configuração .codex/ própria do projeto; os projetos não confiáveis saltam essas camadas locais, que é exatamente o que queres para um repositório que acabaste de clonar de um desconhecido. Se o incómodo forem os pedidos, aperta o que os dispara em vez de os desligar: as versões recentes expõem uma approval_policy granular e uma opção approvals_reviewer = "auto_review" que encaminha as aprovações para um revisor automático. Trata o auto-review como uma comodidade, não como uma fronteira: é um modelo a julgar outro modelo.

Para CI e codex exec, mantém a sandbox e retira apenas os pedidos: --sandbox workspace-write -a never num runner sem credenciais de produção é uma postura coerente. --yolo no mesmo runner não é, porque a sandbox não te custava nada.

A brecha que nenhuma flag fecha

Todas as flags deste artigo governam o que o Codex pode executar. Nenhuma governa o que o Codex escreve, e é no código que vive agora a maior parte do risco. Uma sandbox workspace-write deixa alegremente o agente fazer commit de um endpoint sem verificação de autorização, de um handler de reembolsos sem limite ou de uma query construída por concatenação de strings, porque nenhum deles é um comando. São diffs.

É essa a camada que o VibeDefend acrescenta em agent-time. Coloca-se no ciclo do Codex, confronta o diff que o agente está prestes a escrever com as tuas próprias regras, reescreve a versão insegura antes de ela aterrar, e vigia os comandos de shell com a mesma política que produziu os dezassete bloqueios acima. No nosso estudo, os agentes com a camada seguiram as regras de segurança em 89 % dos tickets, contra 12 % para agentes com apenas um ficheiro de regras no repositório. A sandbox mantém o Codex fora da tua máquina; o guarda mantém o código dele fora da tua fila de incidentes.

Se corres o Codex em --yolo de propósito, num contentor, com um guarda sobre o diff, tens uma configuração defensável. Se o corres em --yolo no teu portátil porque os pedidos irritavam, lê o guia completo de segurança do Codex e depois fala connosco: a correção demora cerca de um minuto.

Perguntas frequentes

danger-full-access e --yolo são a mesma coisa?

Não. --sandbox danger-full-access retira a sandbox do SO e mantém os pedidos de aprovação. --dangerously-bypass-approvals-and-sandbox (--yolo) retira a sandbox e os pedidos. A predefinição "Full access" do seletor corresponde ao segundo.

O que faz ao certo o codex --yolo?

Executa de imediato todos os comandos que o modelo gera, com as permissões do teu utilizador, no teu sistema de ficheiros real, com rede sem restrição, e nunca pergunta nada. A referência da OpenAI reserva-o a um ambiente endurecido a partir do exterior, isto é, um contentor ou uma VM que sejam eles próprios a fronteira.

O -a never é perigoso por si só?

Menos do que se costuma pensar, desde que a sandbox continue ativa. --ask-for-approval never retira o ponto de controlo humano, mas workspace-write continua a confinar as escritas e a rede fica fechada salvo se a tiveres aberto. Torna-se perigoso no momento em que o combinas com danger-full-access.

O que é o "modo unsafe" do Codex?

Não existe nenhuma flag com esse nome. "Modo unsafe", "modo perigoso" e "run dangerously" são usados para falar de danger-full-access, de --yolo ou de -a never, que são três coisas diferentes. Confirma a que se refere realmente um tutorial antes de copiares o comando.

Como deixo o Codex usar a rede sem acesso total?

Define network_access = true em [sandbox_workspace_write] no config.toml, ou passa -c sandbox_workspace_write.network_access=true para uma única execução. As escritas continuam confinadas ao workspace; só a rede se abre.

A sandbox do Codex funciona em Windows?

Sim. A partir do PowerShell usa uma sandbox nativa do Windows, com ou sem elevação; em WSL2 usa o mecanismo de Linux (bubblewrap e seccomp). Os valores de --sandbox e as chaves do config.toml são os mesmos em todas as plataformas.

A sandbox trava a prompt injection?

Contém o que um comando injetado pode tocar; não trava a injeção. Um README malicioso pode continuar a empurrar o modelo para escrever código inseguro, ou para pedir uma escalada que um humano cansado aprova. Mantém a sandbox ativa e acrescenta uma camada que verifica o código e os comandos, não apenas os caminhos de ficheiros.