Vous voulez que Codex avance seul : modifier les fichiers, lancer les commandes et poursuivre son travail sans vous demander de valider chaque étape. Vous activez donc « Full access »… et il continue pourtant à poser des questions. Voici pourquoi, et comment obtenir un fonctionnement réellement autonome, testé avec Codex CLI v0.145.0.
La raison : le « mode automatique » n’est pas un interrupteur unique. Codex sépare deux réglages : le sandbox, qui définit ce qu’il peut toucher, et la politique d’approbation, qui détermine à quel moment il s’arrête pour demander votre accord. L’accès réseau constitue une troisième barrière indépendante. Assouplir l’un ne déverrouille pas les autres, et une mise à jour de Codex peut rétablir discrètement la politique par défaut de votre session.
Pour ne plus intervenir en CLI : --yolo est la seule option qui désactive toutes les barrières d’un coup. Si vous préférez conserver le sandbox, définissez explicitement les deux axes. Faites-le dès le lancement de la session et vérifiez à nouveau après chaque mise à jour.
# Totalement autonome — sans sandbox ni confirmation (environnement jetable uniquement) :
codex --yolo
# Plus prudent — modifie librement le projet, mais demande avant d’en sortir :
codex --sandbox workspace-write --ask-for-approval on-requestPour ne plus intervenir dans l’app : ouvrez le menu des approbations, choisissez Full access, puis sélectionnez-le de nouveau après chaque mise à jour : les upgrades réinitialisent ce mode.
Voilà pour la réponse courte. La suite détaille chaque mode, leur correspondance technique et le choix à faire selon le contexte.
Les trois modes Codex comparés
Le sandbox fixe le périmètre d’action de l’agent, notamment pour les fichiers et le réseau. La politique d’approbation décide, elle, quand il doit s’interrompre. Les modes automatiques ne sont que des combinaisons de ces deux paramètres, avec des intitulés différents entre l’application desktop et la CLI.
| Libellé dans l’app | Fonctionnement | Équivalent CLI |
|---|---|---|
| Ask for approval | Modifie les fichiers du workspace, exécute les commandes locales courantes et demande confirmation avant tout accès à Internet ou toute action hors du workspace | sandbox_mode = "workspace-write" + approval_policy = "on-request" |
| Approve for me (mode par défaut actuel de l’app) | Mêmes limites, mais les demandes d’approbation éligibles sont confiées à un relecteur IA plutôt qu’à vous : c’est Auto-review | ci-dessus + approvals_reviewer = "auto_review" |
| Full access | Ni sandbox ni demandes d’approbation, avec accès sans restriction aux fichiers et au réseau | sandbox_mode = "danger-full-access" + approval_policy = "never" |
En CLI, vous réglez directement ces paramètres avec --sandbox et --ask-for-approval, ou vous changez de préréglage en cours de session via le sélecteur /permissions. Si vous hésitez encore entre les clients, c’est un autre sujet : nous avons comparé Codex et Claude Code ici. Cet article porte sur les réglages eux-mêmes.
Pourquoi « Full access » demande encore une approbation
Trois explications peuvent se cumuler.
Sandbox et approbation sont deux réglages distincts. Avec workspace-write + on-request, Codex peut modifier librement votre projet, mais s’arrête à ses frontières : appel réseau, fichier hors du dépôt, sudo. Si vous assouplissez le sandbox tout en laissant les approbations sur demande, il continuera à vous solliciter à chaque limite.
Le réseau a sa propre barrière. Même avec Full Access, Internet peut être géré séparément du système de fichiers. Comme l’a relevé @mxcl le 16 juillet 2026, Codex « cannot use the Internet without full access, ending task until the user enables full access. » L’autorisation d’écrire des fichiers n’est donc pas l’autorisation d’accéder au réseau.
Les mises à jour réinitialisent le mode. Plusieurs utilisateurs l’ont constaté fin juillet 2026 : une mise à niveau de Codex replace silencieusement les sessions actives sur la politique par défaut. @s_rafcon, le 22 juillet, indique que les fils « switch their Full access flag to the default flag and [are] stuck asking for approval on every single edit. » Définissez le mode au début de chaque session et contrôlez-le après toute mise à jour.
CLI : --full-auto a disparu, voici quoi utiliser à la place
codex --full-auto était autrefois le raccourci pour « travailler dans mon projet sans demander » : approval_policy = "on-request" + sandbox_mode = "workspace-write". La commande interactive ne l’accepte plus. Testé sur v0.145.0 :
$ codex --full-auto
error: unexpected argument '--full-auto' foundDéfinissez désormais les deux axes explicitement : c’est exactement ce que faisait l’ancienne option.
# Le remplaçant actuel de --full-auto
codex --sandbox workspace-write --ask-for-approval on-request
# Ou, en non-interactif, sans confirmation tout en conservant le sandbox :
codex -a never -s workspace-write exec "your task"codex exec --full-auto accepte encore l’option dans les scripts ; seule la commande interactive renvoie une erreur. D’après codex --help, --ask-for-approval accepte untrusted / on-request / never, tandis que --sandbox accepte read-only / workspace-write / danger-full-access. Chaque « mode » de l’app correspond à une combinaison de ces deux réglages.
--yolo : le contournement total, à réserver au bon contexte
--yolo est l’alias court de --dangerously-bypass-approvals-and-sandbox. C’est le véritable bouton « laissez-le faire » : danger-full-access associé à never, sans limite sur le système de fichiers ni demande d’approbation. Il a survécu à la suppression de --full-auto précisément parce que son nom rend le risque évident : codex --yolo fonctionne sur v0.145.0, là où codex --full-auto échoue.
De nombreux utilisateurs expérimentés l’emploient par défaut et, pour les bonnes tâches, ils ont raison : utilisez-le lorsque l’environnement fait lui-même office de garde-fou. Considérez alors la machine comme jetable :
- Travaillez dans une VM ou un dev container éphémère, pas sur votre machine de travail quotidienne.
- Retirez d’abord les identifiants de production de l’environnement.
- Gardez un périmètre de tâche étroit, puis examinez
git diffavant de poursuivre.
Puisque --yolo supprime toutes les barrières, un rm -rf, un git push ou un DROP TABLE malencontreux sera exécuté sans confirmation : c’est le prix de la vitesse. (Configurer Codex sur un endpoint auto-hébergé ou compatible Anthropic via un fournisseur de modèle personnalisé ne change rien à ce point ; le sandbox ne se préoccupe pas du modèle qui se trouve derrière l’API.)
« Approve for me » / Auto-review : confier les validations à une IA
Le mode le plus récent, et le mode par défaut actuel de l’application, est Auto-review. Les escalades éligibles sont envoyées à un agent relecteur distinct — un petit Codex utilisant GPT-5.4 Thinking (low) — qui accepte ou refuse avec une justification. OpenAI le décrit comme « a reviewer swap, not a permission grant » : il n’élargit pas les répertoires accessibles en écriture et n’ouvre pas le réseau ; il change seulement qui donne son accord.
Selon l’évaluation publiée par OpenAI le 30 avril 2026, Auto-review interrompt un humain environ 200x moins souvent que l’approbation manuelle et accepte environ 99,1% des escalades qu’il examine, soit 99,93% de toutes les actions. Dans leur exemple illustratif de 10 000 actions, 9 280 se sont exécutées dans le sandbox sans intervention, 720 sont passées par le relecteur, et seules 7 ont été refusées.
Le système prévoit des garde-fous contre une succession de refus : le tour est interrompu après 3 refus consécutifs, ou après 10 refus dans une fenêtre glissante des 50 dernières revues. Lorsqu’il vous arrête, lancez /approve pour ouvrir le sélecteur Auto-review Denials et autoriser une action pour une nouvelle tentative.
Revers de la médaille : ces contrôles de sécurité peuvent bloquer les longues exécutions. Fin juillet 2026, des utilisateurs lançant des tâches /goal de plusieurs heures ont signalé que l’invite périodique « keep waiting? » cassait des workflows qui pouvaient auparavant tourner plusieurs jours sans surveillance. OpenAI précise aussi clairement qu’il « should not be treated as a guarantee of security » : le rappel de red team est élevé, mais imparfait (90,3% overreach, 99,3% prompt injection, 96,1% misaligned-model). Un bon réglage par défaut, mais pas un substitut au sandbox pour les travaux sensibles.
Pour l’activer dans la configuration plutôt que dans l’interface :
approvals_reviewer = "auto_review"
[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""Quel mode choisir en pratique ?
- Développement local au quotidien :
workspace-write+on-request(« Ask for approval »). Vous gardez le dernier mot sur tout ce qui sort du dépôt, là où se trouvent les vrais risques. - Exécutions longues sans surveillance : « Approve for me » (Auto-review). Gardez à l’esprit qu’il s’arrête toujours sur les actions qu’il signale : ce n’est donc pas totalement sans intervention.
- Tâches ponctuelles et peu délicates dans un environnement jetable :
--yolo. C’est le plus rapide et le plus dangereux ; il n’est sûr que si l’environnement ne peut pas subir de dommage. - Lecture ou revue d’une base de code :
read-only. Aucune écriture, aucune surprise.
Le bilan honnête est simple : aucun réglage n’est à la fois entièrement autonome et totalement sûr. Chaque pas vers le mode sans intervention remplace votre jugement par celui d’un classifieur. Le compromis est pertinent pour les tâches routinières, et mauvais pour une infrastructure de production. Choisissez selon la tâche, pas une fois pour toutes.
FAQ
Existe-t-il un mode automatique dans Codex ?
Oui, mais il s’agit d’un ensemble de préréglages plutôt que d’un interrupteur unique. Dans l’app, « Ask for approval », « Approve for me » et « Full access » sont les modes automatiques ; en CLI, vous recréez le même comportement avec --sandbox et --ask-for-approval, ou via /permissions.
Comment faire approuver automatiquement toutes les commandes par Codex ?
Définissez approval_policy = "never". Associé à workspace-write, ce réglage supprime les demandes dans le sandbox ; associé à danger-full-access, c’est-à-dire --yolo, il supprime toutes les demandes. Ce dernier mode enlève tous les garde-fous : ne l’utilisez que dans un environnement isolé.
Qu’est-ce que le mode Auto-review de Codex ?
Auto-review (approvals_reviewer = "auto_review", affiché comme « Approve for me ») transmet les décisions d’approbation à un agent relecteur IA au lieu de vous les soumettre. Il accepte environ 99% de ce qu’il examine et sollicite un humain environ 200x moins souvent, mais il ne constitue pas une garantie de sécurité.
--full-auto fonctionne-t-il encore ?
Pas dans la CLI interactive. Testé sur v0.145.0, codex --full-auto renvoie « unexpected argument ». codex exec --full-auto l’accepte toujours comme alias déprécié pour les scripts. En usage interactif, utilisez plutôt --sandbox workspace-write --ask-for-approval on-request.
Le mode --yolo est-il sûr ?
Non, c’est précisément ce que son nom indique. Il désactive simultanément le sandbox et toutes les approbations. Il n’est raisonnable que dans une VM ou un conteneur jetable, sans identifiants de production et avec une tâche au périmètre strict.