Codex abandonne la politique untrusted : que modifier

Codex CLI v0.149.0 (stable, 20 août 2026) a abandonné la politique d’approbation untrusted dans la PR #39630, « Retire the untrusted approval policy » (abandon de la politique d’approbation untrusted).¹ La PR supprime untrusted « from the CLI, configuration schema, and MCP tool interface » (de la CLI, du schéma de configuration et de l’interface d’outils MCP), et un approval_policy = "untrusted" explicite échoue désormais « with an actionable error » (avec une erreur exploitable).⁴ Reproduit sur la 0.149.1 le 25 août 2026 : le lancement d’une session s’arrête sur Error: approval_policy = "untrusted" is no longer supported; remove this setting, que la valeur se trouve dans config.toml, dans un fichier de profil ou dans une surcharge -c, et le binaire codex rejette -a untrusted dès l’analyse des arguments.⁵ Remplacez la valeur par on-request et ne touchez pas au mode sandbox ; pour la configuration la plus prudente, associez --sandbox read-only à on-request.³ Le jeu de politiques actuel se compose de on-request, de never et de la forme granulaire en table.² À jour pour la v0.149.1 (24 août 2026, UTC), le latest npm.¹ {.answer-block}

TL;DR

• Le changement : le changelog complet de la v0.149.0 liste la PR #39630, « Retire the untrusted approval policy ». Les notes de version ne fournissent aucun texte de migration au-delà de ce titre ;¹ la description de la PR, elle, le fait : untrusted disparaît de la CLI, du schéma de configuration et de l’interface d’outils MCP, et les réglages explicites « now fail with an actionable error » (échouent désormais avec une erreur exploitable).⁴
• Qui doit agir : toute personne ayant approval_policy = "untrusted" dans ~/.codex/config.toml ou dans un profil, et toute personne passant --ask-for-approval untrusted (ou -a untrusted) dans des scripts, des alias ou la CI.
• Le remplacement : on-request, sans modifier le mode sandbox. read-only plus on-request forme la paire « Safe read-only browsing » (navigation sûre en lecture seule) de la documentation.² L’ancienne combinaison workspace-write plus untrusted n’a pas de successeur direct ; la demande de confirmation commande par commande relève désormais des règles d’exec policy.⁴⁸
• Le jeu actuel : on-request, never ou approval_policy = { granular = { ... } } pour un contrôle par catégorie. Les modes sandbox restent read-only, workspace-write et danger-full-access.²
• Échec immédiat, pas silencieux : un approval_policy = "untrusted" oublié arrête la session avec Error: approval_policy = "untrusted" is no longer supported; remove this setting, qu’il soit dans config.toml, dans un fichier de profil ou dans une surcharge -c. codex doctor signale seulement que la config n’a pas pu être chargée, sans nommer la clé.⁵

Qu’a changé Codex 0.149 ?

Les éléments phares sont de nouvelles surfaces, parmi lesquelles le tableau de bord codex agents, codex queue et un codex doctor élargi ; le changement d’approbation figure plus bas, dans le changelog complet.¹ La description de la PR #39630 porte le détail que les notes de version omettent. Deux de ses trois points comptent ici : « Remove untrusted from the CLI, configuration schema, and MCP tool interface. Explicit approval_policy = "untrusted" settings now fail with an actionable error. » et « Remove the known-safe command allowlist. Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it. » (suppression de la liste d’autorisation des commandes réputées sûres ; les projets marqués untrusted demandent désormais une confirmation pour chaque commande, sauf si une règle d’exec policy explicite l’autorise).⁴ Un correctif de la même version concerne les mêmes lecteurs : « Resumed and forked threads now restore their active permission profile instead of silently falling back to current defaults. » (les threads repris ou dupliqués restaurent désormais leur profil de permissions actif au lieu de retomber silencieusement sur les valeurs par défaut courantes).¹

Chaque ligne cite les notes de version de la v0.149.0.¹

Qui doit modifier quelque chose ?

Quatre emplacements portent la valeur. Trouvez-les tous d’abord, car un profil ou un alias shell réimpose l’ancienne politique après la correction du fichier principal.

L’échec de la table héritée est bruyant. Sur la 0.149.1, codex exec --profile safe "hi" avec une table [profiles.safe] encore présente dans config.toml s’arrête sur 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 ..., si bien que le --profile safe d’un collègue échoue avant même que Codex lise la valeur d’approbation.⁵

Un grep par côté :

# 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

Le premier grep cible la clé plutôt que le mot seul, et pour une bonne raison. trust_level = "untrusted" est un réglage différent ; laissez-le. La référence de configuration définit projects.<path>.trust_level comme la clé qui marque « a project or worktree as trusted or untrusted » (un projet ou un worktree comme fiable ou non fiable), et les projets non fiables « skip project-scoped .codex/ layers, including project-local config, hooks, and rules » (ignorent les couches .codex/ propres au projet, y compris la config, les hooks et les règles locaux au projet).⁷ La PR #39630 change ce qu’un projet non fiable fait des commandes, pas la clé : « Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it. »⁴ Un rechercher-remplacer aveugle de untrusted corrompt cette clé.

Les fichiers de profil sont le mécanisme de préréglage documenté (~/.codex/<name>.config.toml, sélectionné avec codex --profile <name>), si bien que le profil d’un collègue peut réintroduire la valeur abandonnée quoi que dise la config principale.²

Quel est le jeu actuel de politiques d’approbation ?

La sécurité de Codex repose sur deux couches : le mode sandbox décide ce que Codex peut techniquement faire, et la politique d’approbation décide quand Codex doit s’arrêter et demander.² L’abandon ne touche que la seconde.

La forme granulaire couvre cinq catégories de demandes : sandbox_approval, rules (demandes d’execpolicy), mcp_elicitations, request_permissions et skill_approval.² Aucune ne reproduit untrusted, qui était une règle de classification des commandes (exécuter automatiquement les lectures réputées sûres, demander pour tout ce qui pourrait modifier l’état) plutôt qu’un filtre par catégorie de demande.²

workspace-write plus untrusted, la ligne « Automatically edit but ask for approval to run untrusted commands » (modifier automatiquement, mais demander une confirmation pour exécuter des commandes non fiables) de la documentation, n’a pas de successeur direct.² workspace-write plus on-request cesse de demander pour les commandes qui s’exécutent dans le sandbox ; read-only plus on-request demande pour les modifications comme pour les commandes.² La PR #39630 a supprimé « the known-safe command allowlist » (la liste d’autorisation des commandes réputées sûres) et nomme le mécanisme survivant pour la demande commande par commande : « Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it. »⁴ Les règles d’exec policy sont le mécanisme qui se trouve derrière la catégorie rules de la table granulaire, les « execpolicy-rule prompts » que liste la page des approbations.² Les responsables sécurité qui s’appuyaient sur untrusted pour un espace de travail inscriptible devraient écrire ces règles. La documentation des règles les limite aux commandes qui s’exécutent hors du sandbox ; une prefix_rule avec decision = "prompt" demande une confirmation « before each matching invocation » (avant chaque invocation correspondante) :⁸

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

Le sandbox en lecture seule reste l’alternative brute qui bloque purement et simplement toute mutation.³

Quelles sont les modifications exactes ?

La correspondance tient en une ligne : untrusted devient on-request, et le mode sandbox reste ce qu’il était.³

Config principale (un fichier de profil reçoit exactement la même modification) :

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

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

Un script :

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

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

La paire -a/--ask-for-approval appartient au binaire TUI codex. codex exec n’a pas ce drapeau : sur la 0.149.1, codex exec --ask-for-approval untrusted "hi" échoue avec error: unexpected argument '--ask-for-approval' found.⁵ Pour codex exec, définissez la politique dans la config ou passez-la en ligne :

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

Deux arbitrages suivent. D’abord, là où personne ne peut répondre à une demande, le binaire interactif codex sous on-request se bloque à la première approbation ; la paire non interactive documentée est --sandbox read-only --ask-for-approval never, et codex exec --sandbox workspace-write est le point d’entrée non interactif documenté.² Ensuite, si vous associiez untrusted à danger-full-access pour obtenir « toute la puissance, mais une demande à chaque fois », cette propriété ne survit pas à l’échange. Les deux exemples de demande on-request que donne la documentation sont la sortie du sandbox et l’utilisation du réseau, et danger-full-access supprime ces deux déclencheurs.² Les demandes des quatre autres catégories de la table granulaire se déclenchent toujours en accès complet : règles d’exec policy avec decision = "prompt", élicitations MCP, approbations de skills et demandes request_permissions.²⁸ Le réglage facultatif approvals_reviewer = "auto_review" achemine les demandes éligibles vers un agent relecteur ; il ne s’applique qu’aux politiques interactives, il reste donc disponible après la migration.²

Comment vérifier que le changement a bien pris ?

1. Lancez codex doctor. Avec la valeur abandonnée encore en config, sa ligne config commence par ✗ config config could not be loaded et la ligne de détail indique · failed to load Codex config ; doctor ne nomme pas la clé fautive. L’erreur nommée vient du lancement de codex ou de codex exec. Une ligne doctor propre signifie que la valeur a disparu ; une ligne en échec signifie qu’il faut encore lancer une session pour voir quelle clé est en cause.⁵ L’erreur de lancement est identique, que la valeur se trouve dans config.toml, dans un fichier de profil sélectionné avec --profile ou dans une surcharge -c approval_policy=untrusted.⁵ La forme drapeau échoue plus tôt, à l’analyse des arguments : codex -a untrusted --version affiche error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>' suivi de [possible values: on-request, never].⁵
2. Démarrez une session jetable dans un répertoire temporaire et lancez /status. Sa ligne Permissions affiche la politique active, et on-request s’y affiche sous le libellé « Ask for approval » (demander une confirmation).⁵ /permissions ouvre le menu des préréglages au lieu de rapporter le mode actif ; lisez donc /status à la place.⁵ /status liste aussi les répertoires de l’espace de travail.²
3. Reprenez un thread plus ancien. La PR #39153, « Restore permission profiles when resuming threads », restaure désormais « the latest persisted approval policy, approvals reviewer, and active permission-profile ID when resuming or forking a thread » (la dernière politique d’approbation persistée, le relecteur d’approbations et l’identifiant du profil de permissions actif lors de la reprise ou de la duplication d’un thread).⁶ Un thread repris dont la politique persistée est untrusted n’a pas été testé ; considérez ce cas comme inconnu tant que vous n’en avez pas ouvert un.

Une réserve sur la documentation elle-même. La page officielle « Agent approvals & security », telle que capturée le 24 août et revérifiée le 25 août 2026, montre encore --ask-for-approval untrusted dans sa table des combinaisons, contient encore le paragraphe qui commence par « With --ask-for-approval untrusted, Codex runs only known-safe read operations automatically » et utilise encore approval_policy = "untrusted" dans son exemple config.toml.² L’entrée approval_policy de la référence de configuration liste untrusted en premier dans son union de types, tandis que sa description marque une autre valeur comme obsolète : « on-failure is deprecated; use on-request for interactive runs or never for non-interactive runs. »⁷ La PR et le binaire font foi ; la documentation est en retard sur eux. Ne copiez pas le bloc d’exemple de la documentation dans une installation 0.149 fraîche sans en échanger la valeur.

FAQ

Qu’est-ce qui remplace approval_policy = "untrusted" dans Codex ?

approval_policy = "on-request", avec votre sandbox_mode existant inchangé. Pour la combinaison la plus prudente, définissez sandbox_mode = "read-only" à côté.³

Quelle version de Codex a abandonné la politique untrusted ?

La v0.149.0, stable depuis le 20 août 2026, via la PR #39630 dans le changelog complet. La v0.149.1 (24 août 2026, UTC) est le latest npm actuel.¹

Que se passe-t-il si je laisse untrusted dans config.toml ?

Codex refuse de démarrer la session. Sur la 0.149.1, codex exec s’arrête sur Error: approval_policy = "untrusted" is no longer supported; remove this setting, la même erreur apparaît pour un fichier de profil et pour -c approval_policy=untrusted, et codex doctor signale seulement que la config n’a pas pu être chargée.⁵ La PR #39630 décrit ce comportement comme un échec « with an actionable error ».⁴

on-request est-il moins sûr que ne l’était untrusted ?

Dans workspace-write, oui : untrusted demandait avant toute commande susceptible de modifier l’état, et on-request exécute les commandes internes au sandbox sans demander.² La couche sandbox récupère une partie de la marge : read-only bloque les écritures quelle que soit la politique, et on-request demande toujours avant toute escalade.³ Pour une demande commande par commande sur un espace de travail inscriptible, écrivez des règles d’exec policy, le mécanisme que nomme la PR #39630.⁴⁸

Dois-je aussi changer mon mode sandbox ?

Non. L’abandon ne concerne que la politique d’approbation ; conservez read-only, workspace-write ou danger-full-access tel que vous l’aviez.³

Points clés

Pour les développeurs individuels : - Cherchez approval_policy = "untrusted" (pas le mot seul) dans ~/.codex/*.toml avec grep, remplacez chaque occurrence par on-request, et laissez sandbox_mode et tout trust_level = "untrusted" tranquilles. - Lancez codex doctor, puis /status dans une session temporaire, et reprenez un ancien thread pour voir ce que la 0.149 restaure.

Pour les équipes qui maintiennent des profils et des scripts partagés : - Corrigez les fichiers de profil et les surcharges en ligne dans le même commit que config.toml ; une table [profiles.<name>] héritée bloque entièrement --profile tant que vous ne l’avez pas déplacée vers ~/.codex/<name>.config.toml.⁵ - Convertissez les tâches sans surveillance en --sandbox read-only --ask-for-approval never sur le binaire codex, ou en codex exec --sandbox workspace-write -c approval_policy=never ; le binaire interactif codex sous on-request se bloque sur une demande à laquelle personne ne répondra, et codex exec n’a pas de drapeau --ask-for-approval.⁵

Pour les responsables sécurité : - Le classificateur untrusted (exécution automatique des lectures sûres, demande à la mutation) n’a pas d’équivalent granulaire ; la PR #39630 renvoie aux règles d’exec policy (« unless an explicit exec policy rule allows it ») pour la demande commande par commande,⁴ écrites sous forme de prefix_rule avec decision = "prompt" dans ~/.codex/rules/default.rules,⁸ et le sandbox en lecture seule bloque purement et simplement la mutation. - Envisagez approvals_reviewer = "auto_review" là où un agent relecteur peut remplacer un humain sur les demandes éligibles.

Références