Codex demande sans cesse une approbation ? Stratégies d’approbation, bac à sable et « don’t ask again » expliqués
Codex demande une approbation quand une commande doit sortir de son bac à sable. La plupart des plaintes du type « il n’arrête pas de demander » viennent d’un bac à sable trop restrictif, d’un paramètre qui n’existe plus ou d’un « don’t ask again » qui n’a duré que le temps de la session.
RÉPONSE COURTE
Dans la version actuelle de Codex, approval_policy vaut on-request (la valeur par défaut : le modèle demande quand il en a besoin), never ou une table granular ; untrusted a été supprimé et on-failure n’est plus qu’un autre nom de on-request. Ce qui détermine la fréquence des demandes, c’est surtout le bac à sable : avec sandbox_mode = "workspace-write", Codex modifie les fichiers et exécute les commandes dans votre projet sans demander. Pour les commandes auxquelles vous faites toujours confiance, ajoutez une prefix_rule avec decision = "allow" dans ~/.codex/rules/default.rules. C’est aussi là que s’enregistre « don’t ask again for commands that start with … ».
D’abord : ce qui a changé dans Codex
Beaucoup de guides et de réponses sur les forums décrivent des paramètres qui ne fonctionnent plus. Avant de régler quoi que ce soit, comparez votre ~/.codex/config.toml à cette liste :
| Ancien paramètre | Aujourd’hui |
|---|---|
approval_policy = "untrusted" | Supprimé. Codex affiche « approval_policy = "untrusted" is no longer supported; remove this setting » (ce paramètre n’est plus pris en charge ; supprimez-le). La documentation recommande à la place sandbox_mode = "read-only" avec on-request. |
approval_policy = "on-failure" | Toujours accepté, mais uniquement comme alias de on-request. |
--full-auto | N’apparaît plus dans la référence de la CLI. L’option la plus proche est --approve-for-me (alias --not-so-yolo) : examen automatique des approbations avec on-request et le bac à sable workspace-write. |
[profiles.name] dans config.toml | Depuis Codex 0.134.0, --profile name lit $CODEX_HOME/name.config.toml à la place. Une clé profile = "x" restée en place provoque désormais une erreur. |
/approvals | Utilisez /permissions (« Set what Codex can do without asking first. ») |
La documentation de Codex a aussi déménagé : les anciennes pages developers.openai.com/codex redirigent désormais vers learn.chatgpt.com.
Comment Codex décide de demander
Deux paramètres fonctionnent ensemble. Le bac à sable limite ce qu’une commande peut toucher : les fichiers hors du projet, le réseau. La stratégie d’approbation décide de ce qui se passe quand une commande a besoin de plus que ce que le bac à sable autorise.
| sandbox_mode | Ce que Codex peut faire sans demander |
|---|---|
read-only (par défaut) | Lire des fichiers et exécuter des commandes dans un bac à sable en lecture seule |
workspace-write | Lire, modifier et exécuter des commandes dans le répertoire de travail automatiquement |
danger-full-access | Tout, sans bac à sable. Déconseillé |
| approval_policy | Comportement |
|---|---|
on-request (par défaut) | Le modèle décide quand demander. Les commandes autorisées par le bac à sable s’exécutent sans approbation |
never | Ne demande jamais. Tout ce qui échoue est renvoyé au modèle, sans vous être remonté |
{ granular = { … } } | Garde certaines catégories de demandes interactives et rejette automatiquement les autres (sandbox_approval, rules, skill_approval, request_permissions, mcp_elicitations) |
Si vous êtes en read-only, chaque modification nécessite donc un oui. C’est de loin la cause la plus fréquente de « Codex demande pour tout ». Même en workspace-write, .git, .codex, .agents et .aws restent en lecture seule, et l’accès réseau est désactivé tant que vous ne l’activez pas.
Voici l’exemple de configuration de la documentation d’OpenAI, avec les options de l’espace de travail expliquées :
Les versions récentes proposent aussi des profils d’autorisation (default_permissions avec les profils intégrés :read-only, :workspace et :danger-full-access). Utilisez soit les profils, soit sandbox_mode, pas les deux.
Les préréglages dans la CLI, l’extension IDE et l’application
Pas besoin de modifier du TOML. Dans la CLI, /permissions ouvre les préréglages ; dans l’application et l’extension IDE, un contrôle des autorisations se trouve sous la zone de saisie. Les préréglages de la CLI sont :
- Read Only : lit l’espace de travail ; une approbation est nécessaire pour modifier des fichiers ou accéder à Internet.
- Default : modifie les fichiers dans l’espace de travail ; une approbation est nécessaire pour accéder à Internet ou modifier d’autres fichiers.
- Full Access : modifie des fichiers hors de l’espace de travail et utilise Internet sans demander.
L’application et l’extension IDE présentent le même choix sous les noms Ask for approval, Approve for me et Full access. Sur les anciennes captures d’écran de l’IDE, ils s’appellent Chat, Agent et Agent (Full Access).
Autoriser des commandes précises avec des règles
Quand vous voulez que Codex exécute une commande hors du bac à sable sans demander (gh pr view, par exemple), écrivez une règle. Les règles sont expérimentales et se trouvent dans un fichier .rules d’un dossier rules/ placé à côté d’une couche de configuration, par exemple ~/.codex/rules/default.rules :
allow: s’exécute hors du bac à sable sans demander.prompt: demande avant chaque commande correspondante.forbidden: bloque sans demander.
Quand plusieurs règles correspondent, la plus restrictive l’emporte : forbidden l’emporte sur prompt, qui l’emporte sur allow. Testez une commande avec codex execpolicy check avant de vous fier à une règle.
Ce que « don’t ask again » enregistre vraiment
La demande d’approbation de la CLI Codex propose plusieurs sortes de « oui », et leur durée varie énormément :
| Option | Durée |
|---|---|
| Yes, proceed | Cette commande uniquement |
Yes, and don’t ask again for commands that start with <prefix> | De façon permanente (enregistrée comme règle dans ~/.codex/rules/default.rules) |
| Yes, and don’t ask again for this command in this session | Jusqu’à la fin de la session |
| Yes, and don’t ask again for these files | Modifications de fichiers, pour cette session |
Si vous choisissez toujours l’option de session, la question reviendra demain. Choisissez l’option par préfixe, ou écrivez la règle vous-même.
Codex sous Windows
C’est sous Windows que le problème « il demande pour tout » était le pire. Dans l’issue #10187, un membre de l’équipe OpenAI a expliqué pourquoi : « Without a sandboxing mechanism, all tool calls need to be manually approved on Windows. » (sans mécanisme de bac à sable, tous les appels d’outils doivent être approuvés manuellement sous Windows). Codex dispose désormais d’un bac à sable Windows natif et l’utilise par défaut :
mxc: le bac à sable recommandé sur les appareils Windows compatibles.elevated: la solution de repli privilégiée quand MXC n’est pas disponible.unelevated: une solution de repli héritée.
Lancez /setup-default-sandbox dans la CLI pour configurer le bac à sable elevated (ou codex sandbox setup --elevated côté service informatique). Windows 11 est recommandé ; Windows 10 1809 ou version ultérieure est pris en charge au mieux. Si vous travaillez dans WSL, Codex y utilise son bac à sable Linux, et WSL1 n’est plus pris en charge.
La configuration du projet n’est chargée que dans les projets approuvés
Un .codex/config.toml dans un dépôt n’est lu que si vous avez approuvé le projet. Si les paramètres de votre projet semblent ignorés, c’est pour cette raison. Une entrée d’approbation dans votre configuration utilisateur ressemble à ceci :
Les paramètres sont organisés en couches, de la priorité la plus haute à la plus basse : options de ligne de commande et surcharges -c, le .codex/config.toml du projet approuvé, le fichier --profile, votre ~/.codex/config.toml, puis les valeurs par défaut du système.
À propos de --yolo
--dangerously-bypass-approvals-and-sandbox (alias --yolo) exécute toutes les commandes sans approbation ni bac à sable. Le code source le décrit ainsi : « EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed. » (extrêmement dangereux, à réserver aux environnements isolés de l’extérieur). approval_policy = "never" avec danger-full-access fait la même chose depuis le fichier de configuration. Si vous voulez simplement moins de demandes, workspace-write et quelques règles allow suffisent, avec le bac à sable toujours actif.
Pour les demandes que vous gardez
Une fois que Codex ne demande plus que pour ce qui compte (le réseau, les fichiers hors du projet, un push), le problème restant est de remarquer la question. Pet Island affiche les approbations de commandes et de modifications de fichiers de Codex sur une petite île en haut de votre écran, avec la commande ou le diff, pour que vous puissiez les autoriser ou les refuser sans chercher le bon terminal. L’île indique quand Codex travaille et quand il a terminé, et les questions de Codex vous mènent à la bonne fenêtre en un clic. Elle fonctionne avec la CLI Codex et l’application Codex, et si l’île est fermée, Codex demande dans sa propre fenêtre comme d’habitude.
FAQ
Comment empêcher Codex de demander une approbation en permanence ?
Utilisez sandbox_mode = "workspace-write" pour que Codex puisse modifier des fichiers et exécuter des commandes dans votre projet, gardez approval_policy = "on-request" et ajoutez des entrées prefix_rule avec decision = "allow" dans ~/.codex/rules/default.rules pour les commandes auxquelles vous faites toujours confiance.
approval_policy = "untrusted" est-il toujours pris en charge ?
Non. La version actuelle de Codex le rejette avec « approval_policy = "untrusted" is no longer supported; remove this setting ». Utilisez à la place sandbox_mode = "read-only" avec approval_policy = "on-request".
Qu’est devenu --full-auto ?
Il n’apparaît plus dans la référence de la CLI Codex. L’option la plus proche est --approve-for-me (alias --not-so-yolo), qui utilise l’examen automatique des approbations avec on-request et le bac à sable workspace-write.
Pourquoi « don’t ask again » ne tient-il pas ?
« Don’t ask again for this command in this session » ne dure que le temps de la session. Choisissez « don’t ask again for commands that start with … », qui enregistre une règle dans ~/.codex/rules/default.rules.
Pourquoi Codex demande-t-il davantage sous Windows ?
Sans bac à sable, chaque appel d’outil doit être approuvé. Codex utilise désormais par défaut un bac à sable Windows natif ; lancez /setup-default-sandbox s’il n’est pas configuré.
Pourquoi le .codex/config.toml de mon projet est-il ignoré ?
Codex ne charge la configuration du projet que pour les projets approuvés.
Sources
Chaque paramètre et chaque comportement décrits sur cette page ont été vérifiés dans ces pages le 26 octobre 2026. Les agents évoluent vite : si quelque chose ne correspond plus, c’est la page officielle qui fait foi.
- OpenAI : Codex agent approvals and security
- OpenAI : Codex permission modes
- OpenAI : Codex config basics
- OpenAI : Codex sample config
- OpenAI : Codex rules
- OpenAI : Codex Windows sandbox
- OpenAI : Codex CLI reference
- OpenAI : Codex slash commands
- Code source openai/codex (demande d’approbation, erreurs de configuration)
- Issue #10187 : Codex redemande sans cesse l’approbation des commandes
- Issue #5131 : obligation d’approuver chaque modification de fichier
- Issue #29406 : la demande d’approbation persiste malgré « don’t ask again »