Codex aposentou a política untrusted: o que mudar

O Codex CLI v0.149.0 (estável, 20 de agosto de 2026) aposentou a política de aprovação untrusted no PR #39630, “Retire the untrusted approval policy” (aposentar a política de aprovação untrusted).¹ O PR remove untrusted “from the CLI, configuration schema, and MCP tool interface” (da CLI, do schema de configuração e da interface de ferramentas MCP), e um approval_policy = "untrusted" explícito agora falha “with an actionable error” (com um erro acionável).⁴ Reproduzido no 0.149.1, em 25 de agosto de 2026: o lançamento de uma sessão é interrompido com Error: approval_policy = "untrusted" is no longer supported; remove this setting, esteja o valor no config.toml, em um arquivo de perfil ou em um override -c, e o binário codex rejeita -a untrusted já na análise dos argumentos.⁵ Troque o valor por on-request e deixe o modo de sandbox como está; para a configuração mais cautelosa, combine --sandbox read-only com on-request.³ O conjunto atual de políticas é on-request, never e a forma granular em tabela.² Atualizado até a v0.149.1 (24 de agosto de 2026, UTC), o latest do npm.¹ {.answer-block}

TL;DR

• A mudança: o changelog completo da v0.149.0 lista o PR #39630, “Retire the untrusted approval policy”. As notas de lançamento não trazem nenhum texto de migração além desse título;¹ a descrição do PR traz: untrusted saiu da CLI, do schema de configuração e da interface de ferramentas MCP, e configurações explícitas “now fail with an actionable error” (agora falham com um erro acionável).⁴
• Quem precisa agir: qualquer pessoa com approval_policy = "untrusted" em ~/.codex/config.toml ou em um perfil, e qualquer pessoa que passe --ask-for-approval untrusted (ou -a untrusted) em scripts, aliases ou CI.
• A substituição: on-request, com o modo de sandbox inalterado. read-only mais on-request é o par que a documentação chama de “Safe read-only browsing” (navegação segura somente leitura).² A antiga combinação workspace-write mais untrusted não tem sucessor direto; o prompt por comando agora vive nas regras de exec policy.⁴⁸
• O conjunto atual: on-request, never ou approval_policy = { granular = { ... } } para controle por categoria. Os modos de sandbox continuam sendo read-only, workspace-write e danger-full-access.²
• Falha rápida, não silenciosa: um approval_policy = "untrusted" esquecido interrompe a sessão com Error: approval_policy = "untrusted" is no longer supported; remove this setting, seja no config.toml, em um arquivo de perfil ou em um override -c. O codex doctor informa apenas que a configuração não pôde ser carregada, sem nomear a chave.⁵

O que mudou no Codex 0.149?

Os itens de destaque são novas superfícies, entre elas o painel codex agents, o codex queue e um codex doctor mais amplo; a mudança na aprovação fica mais abaixo, no changelog completo.¹ A descrição do PR #39630 traz o detalhe que as notas de lançamento omitem. Dois dos seus três tópicos importam aqui: “Remove untrusted from the CLI, configuration schema, and MCP tool interface. Explicit approval_policy = "untrusted" settings now fail with an actionable error.” (remover untrusted da CLI, do schema de configuração e da interface de ferramentas MCP; configurações explícitas de approval_policy = "untrusted" agora falham com um erro acionável) e “Remove the known-safe command allowlist. Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.” (remover a lista de comandos conhecidamente seguros; projetos marcados como untrusted agora pedem aprovação para todo comando, a menos que uma regra explícita de exec policy o permita).⁴ Uma correção de bug no mesmo lançamento importa para os mesmos leitores: “Resumed and forked threads now restore their active permission profile instead of silently falling back to current defaults.” (threads retomadas e bifurcadas agora restauram seu perfil de permissão ativo em vez de recair silenciosamente nos padrões atuais).¹

Cada linha cita as notas de lançamento da v0.149.0.¹

Quem precisa editar alguma coisa?

Quatro lugares carregam o valor. Encontre todos primeiro, porque um perfil ou um alias do shell reafirma a política antiga depois que você corrige o arquivo principal.

A falha da tabela legada é barulhenta. No 0.149.1, codex exec --profile safe "hi" com uma tabela [profiles.safe] ainda no config.toml é interrompido com Error loading config.toml: --profile `safe` cannot be used while .../config.toml contains legacy `profile = "safe"` or `[profiles.safe]` config; move those settings into .../safe.config.toml ..., então o --profile safe de um colega falha antes de o Codex ler o valor de aprovação.⁵

Um grep para cada lado:

# Config and profiles: match the key, not the bare word
grep -rnE 'approval_policy\s*=\s*"untrusted"' ~/.codex/*.toml .codex/config.toml 2>/dev/null

# Scripts, aliases, CI
grep -rn --exclude-dir=node_modules \
  -e "ask-for-approval untrusted" -e "ask-for-approval=untrusted" \
  -e "-a untrusted" -e "approval_policy=untrusted" \
  ~/.zshrc ~/.bashrc . 2>/dev/null

# CI directories: read every bare hit, because YAML can split a flag from its value
grep -rn --exclude-dir=node_modules "untrusted" .github .gitlab-ci.yml .circleci 2>/dev/null

O primeiro grep casa com a chave, e não com a palavra solta, por um motivo. trust_level = "untrusted" é uma configuração diferente; deixe-a em paz. A referência de configuração define projects.<path>.trust_level como a chave que marca “a project or worktree as trusted or untrusted” (um projeto ou worktree como confiável ou não confiável), e projetos não confiáveis “skip project-scoped .codex/ layers, including project-local config, hooks, and rules” (pulam as camadas .codex/ com escopo de projeto, incluindo configuração local do projeto, hooks e regras).⁷ O PR #39630 muda o que um projeto não confiável faz com os comandos, não a chave: “Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ Um localizar-e-substituir cego de untrusted corrompe essa chave.

Arquivos de perfil são o mecanismo documentado de presets (~/.codex/<name>.config.toml, selecionado com codex --profile <name>), então o perfil de um colega pode reintroduzir o valor aposentado, não importa o que o config principal diga.²

Qual é o conjunto atual de políticas de aprovação?

A segurança do Codex vem de duas camadas: o modo de sandbox decide o que o Codex consegue fazer tecnicamente, e a política de aprovação decide quando o Codex precisa parar e perguntar.² A aposentadoria toca apenas a segunda.

A forma granular cobre cinco categorias de prompt: sandbox_approval, rules (prompts de execpolicy), mcp_elicitations, request_permissions e skill_approval.² Nenhuma delas reproduz untrusted, que era uma regra de classificação de comandos (executar automaticamente leituras conhecidamente seguras, perguntar antes de qualquer coisa que pudesse alterar estado), e não um filtro de categorias de prompt.²

workspace-write mais untrusted, a linha que a documentação chama de “Automatically edit but ask for approval to run untrusted commands” (editar automaticamente, mas pedir aprovação para executar comandos não confiáveis), não tem sucessor direto.² workspace-write mais on-request para de perguntar sobre comandos que rodam dentro do sandbox; read-only mais on-request pergunta tanto sobre edições quanto sobre comandos.² O PR #39630 removeu “the known-safe command allowlist” (a lista de comandos conhecidamente seguros) e nomeia o mecanismo sobrevivente para prompt por comando: “Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ Regras de exec policy são o mesmo mecanismo por trás da categoria rules da tabela granular, os “execpolicy-rule prompts” que a página de aprovações lista.² Responsáveis por segurança que dependiam de untrusted em um workspace gravável devem construir essas regras. A documentação de regras restringe o escopo delas a comandos que rodam fora do sandbox; uma prefix_rule com decision = "prompt" pergunta “before each matching invocation” (antes de cada invocação correspondente):⁸

# ~/.codex/rules/default.rules
prefix_rule(pattern = ["git", "push"], decision = "prompt")

O sandbox somente leitura continua sendo a alternativa bruta que bloqueia mutações de vez.³

Quais são as edições exatas?

O mapeamento é uma linha: untrusted vira on-request, e o modo de sandbox fica como estava.³

Config principal (um arquivo de perfil recebe a edição idêntica):

# ~/.codex/config.toml (before)
approval_policy = "untrusted"
sandbox_mode    = "read-only"

# ~/.codex/config.toml (after)
approval_policy = "on-request"
sandbox_mode    = "read-only"

Um script:

# before
codex --sandbox workspace-write --ask-for-approval untrusted "$@"

# after
codex --sandbox workspace-write --ask-for-approval on-request "$@"

O par -a/--ask-for-approval pertence ao binário TUI codex. O codex exec não tem essa flag: no 0.149.1, codex exec --ask-for-approval untrusted "hi" falha com error: unexpected argument '--ask-for-approval' found.⁵ Para o codex exec, defina a política na configuração ou passe-a inline:

# non-interactive run, policy set inline
codex exec --sandbox workspace-write -c approval_policy=never "$@"

Duas decisões de julgamento vêm a seguir. Primeiro, onde ninguém pode responder a um prompt, o binário interativo codex sob on-request trava na primeira aprovação; o par não interativo documentado é --sandbox read-only --ask-for-approval never, e codex exec --sandbox workspace-write é o ponto de entrada não interativo documentado.² Segundo, se você combinava untrusted com danger-full-access para ter “poder total, mas perguntando sempre”, essa propriedade não sobrevive à troca. Os dois exemplos de prompt de on-request na documentação são sair do sandbox e usar a rede, e danger-full-access remove os dois gatilhos.² Prompts das outras quatro categorias da tabela granular continuam disparando sob acesso total: regras de exec policy com decision = "prompt", elicitações MCP, aprovações de skills e prompts de request_permissions.²⁸ A configuração opcional approvals_reviewer = "auto_review" encaminha os prompts elegíveis por um agente revisor; ela se aplica apenas a políticas interativas, então continua disponível depois da migração.²

Como verificar se a mudança pegou?

1. Rode codex doctor. Com o valor aposentado ainda na configuração, sua linha de config começa com ✗ config config could not be loaded e a linha de detalhe diz · failed to load Codex config; o doctor não nomeia a chave problemática. O erro nomeado vem de lançar o codex ou o codex exec. Uma linha limpa no doctor significa que o valor sumiu; uma linha com falha significa que você ainda precisa lançar uma sessão para ver qual chave.⁵ O erro de lançamento é idêntico esteja o valor no config.toml, em um arquivo de perfil selecionado com --profile ou em um override -c approval_policy=untrusted.⁵ A forma de flag falha antes, na análise dos argumentos: codex -a untrusted --version imprime error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>' seguido de [possible values: on-request, never].⁵
2. Inicie uma sessão descartável em um diretório de rascunho e rode /status. A linha Permissions mostra a política ativa, e on-request aparece ali como “Ask for approval”.⁵ O /permissions abre o menu de presets em vez de informar o modo ativo, então leia o /status.⁵ O /status também lista os diretórios do workspace.²
3. Retome uma thread mais antiga. O PR #39153, “Restore permission profiles when resuming threads” (restaurar perfis de permissão ao retomar threads), agora restaura “the latest persisted approval policy, approvals reviewer, and active permission-profile ID when resuming or forking a thread” (a última política de aprovação persistida, o revisor de aprovações e o ID do perfil de permissão ativo ao retomar ou bifurcar uma thread).⁶ Uma thread retomada cuja política persistida é untrusted continua sem teste; trate esse caso como desconhecido até abrir uma.

Uma ressalva sobre a própria documentação. A página oficial “Agent approvals & security”, conforme capturada em 24 de agosto e reverificada em 25 de agosto de 2026, ainda mostra --ask-for-approval untrusted na sua tabela de combinações, ainda carrega o parágrafo em prosa que começa com “With --ask-for-approval untrusted, Codex runs only known-safe read operations automatically” (com --ask-for-approval untrusted, o Codex executa automaticamente apenas operações de leitura conhecidamente seguras) e ainda usa approval_policy = "untrusted" no seu exemplo de config.toml.² A entrada approval_policy da referência de configuração lista untrusted primeiro na sua união de tipos, enquanto a descrição marca um valor diferente como aposentado: “on-failure is deprecated; use on-request for interactive runs or never for non-interactive runs.” (on-failure está obsoleto; use on-request para execuções interativas ou never para execuções não interativas).⁷ O PR e o binário são o registro autoritativo; a documentação está atrasada em relação a eles. Não copie o bloco de exemplo da documentação para uma instalação nova do 0.149 sem trocar o valor.

FAQ

O que substitui approval_policy = "untrusted" no Codex?

approval_policy = "on-request", com o seu sandbox_mode atual inalterado. Para a combinação mais cautelosa, defina sandbox_mode = "read-only" junto.³

Qual versão do Codex aposentou a política untrusted?

A v0.149.0, estável em 20 de agosto de 2026, via PR #39630 no changelog completo. A v0.149.1 (24 de agosto de 2026, UTC) é o latest atual do npm.¹

O que acontece se eu deixar untrusted no config.toml?

O Codex se recusa a iniciar a sessão. No 0.149.1, o codex exec é interrompido com Error: approval_policy = "untrusted" is no longer supported; remove this setting, o mesmo erro aparece para um arquivo de perfil e para -c approval_policy=untrusted, e o codex doctor informa apenas que a configuração não pôde ser carregada.⁵ O PR #39630 descreve o comportamento como falhar “with an actionable error” (com um erro acionável).⁴

on-request é menos seguro do que untrusted era?

Dentro de workspace-write, sim: untrusted perguntava antes de qualquer comando que pudesse alterar estado, e on-request executa comandos dentro do sandbox sem perguntar.² A camada de sandbox recupera parte da margem: read-only bloqueia gravações independentemente da política, e on-request ainda pergunta antes de qualquer escalada.³ Para prompt por comando em um workspace gravável, escreva regras de exec policy, o mecanismo que o PR #39630 nomeia.⁴⁸

Preciso mudar meu modo de sandbox também?

Não. A aposentadoria afeta apenas a política de aprovação; mantenha read-only, workspace-write ou danger-full-access como você tinha.³

Principais conclusões

Para desenvolvedores individuais: - Faça grep em ~/.codex/*.toml por approval_policy = "untrusted" (não pela palavra solta), substitua cada ocorrência por on-request e deixe sandbox_mode e qualquer trust_level = "untrusted" em paz. - Rode codex doctor, depois /status em uma sessão de rascunho, e retome uma thread antiga para ver o que o 0.149 restaura.

Para equipes que mantêm perfis e scripts compartilhados: - Corrija arquivos de perfil e overrides inline no mesmo commit que o config.toml; uma tabela legada [profiles.<name>] bloqueia o --profile por completo até você movê-la para ~/.codex/<name>.config.toml.⁵ - Converta jobs sem supervisão para --sandbox read-only --ask-for-approval never no binário codex, ou codex exec --sandbox workspace-write -c approval_policy=never; o binário interativo codex sob on-request trava em um prompt que ninguém vai responder, e o codex exec não tem a flag --ask-for-approval.⁵

Para responsáveis por segurança: - O classificador untrusted (executar automaticamente leituras seguras, perguntar em mutações) não tem equivalente granular; o PR #39630 aponta para regras de exec policy (“unless an explicit exec policy rule allows it”) para prompt por comando,⁴ escritas como uma prefix_rule com decision = "prompt" em ~/.codex/rules/default.rules,⁸ e o sandbox somente leitura bloqueia mutações de vez. - Considere approvals_reviewer = "auto_review" onde um agente revisor possa substituir um humano em prompts elegíveis.

Referências