Sur cette page
- Que fait réellement danger-full-access dans Codex ?
- Que retire --dangerously-bypass-approvals-and-sandbox ?
- -a never, --full-auto et « mode unsafe », est-ce la même chose ?
- L'accès complet de Codex est-il sûr ?
- Comment la sandbox de Codex fonctionne-t-elle sur macOS, Linux et Windows ?
- Quand l'accès complet est-il le bon choix ?
- Que faut-il utiliser à la place de --yolo ?
- La brèche qu'aucun flag ne ferme
- Questions fréquentes
- danger-full-access et --yolo, est-ce la même chose ?
- Que fait concrètement codex --yolo ?
- -a never est-il dangereux à lui seul ?
- Qu'appelle-t-on le « mode unsafe » de Codex ?
- Comment autoriser le réseau à Codex sans passer en accès complet ?
- La sandbox de Codex fonctionne-t-elle sous Windows ?
- La sandbox arrête-t-elle la prompt injection ?
danger-full-access, --dangerously-bypass-approvals-and-sandbox, --yolo, -a never, --full-auto : OpenAI Codex offre cinq façons de desserrer ses propres garde-fous, et leurs noms ne sont pas interchangeables. Certains retirent la sandbox du système d'exploitation, d'autres retirent les demandes d'approbation, un seul retire les deux. Ce guide explique précisément ce que chaque flag désactive, comment la sandbox est appliquée sur macOS, Linux et Windows, dans quels cas l'accès complet est un choix raisonnable, et la configuration qui vous donne un agent rapide sans lui donner votre machine.
Que fait réellement danger-full-access dans Codex ?
danger-full-access est l'une des trois valeurs du flag --sandbox de Codex, et elle coupe la sandbox entièrement. La documentation d'OpenAI sur le sandboxing la décrit en une phrase : l'agent s'exécute sans restriction de sandbox, ce qui retire les frontières fichiers et réseau. Chaque commande shell générée par le modèle s'exécute alors sous votre utilisateur, avec vos droits, sur votre vrai système de fichiers, avec votre vrai réseau.
Les deux autres valeurs sont celles qui comptent au quotidien :
Valeur de --sandbox | Lecture de fichiers | Écriture de fichiers | Réseau | Appliqué par |
|---|---|---|---|---|
read-only | Oui | Non | Non | Sandbox de l'OS |
workspace-write (défaut) | Oui | L'espace de travail, /tmp et $TMPDIR | Fermé sauf activation | Sandbox de l'OS |
danger-full-access | Tout ce que votre utilisateur peut lire | Tout ce que votre utilisateur peut écrire | Sans restriction | Rien |
Deux détails de workspace-write méritent d'être connus avant de le juger trop restrictif. D'abord, l'ensemble inscriptible ne se limite pas au dossier courant : /tmp et $TMPDIR sont inscriptibles par défaut, et vous pouvez ajouter des chemins via sandbox_workspace_write.writable_roots dans config.toml (la référence de configuration expose aussi exclude_slash_tmp et exclude_tmpdir_env_var si vous voulez les retirer). Ensuite, l'accès réseau a son propre interrupteur, sandbox_workspace_write.network_access = true : « il me faut npm install » est un argument pour un booléen, pas pour l'accès complet.
Ce que danger-full-access ne fait pas, c'est faire taire Codex. Les demandes d'approbation dépendent d'un flag distinct, et c'est la source de l'essentiel de la confusion abordée dans la section suivante.
Que retire --dangerously-bypass-approvals-and-sandbox ?
--dangerously-bypass-approvals-and-sandbox, dont l'alias est --yolo, retire les deux protections d'un coup : la sandbox de l'OS et les demandes d'approbation. La référence CLI d'OpenAI le décrit ainsi : exécuter chaque commande sans approbation ni sandbox, à n'utiliser qu'à l'intérieur d'un environnement durci de l'extérieur. Cette seconde phrase est toute la politique. Le flag existe pour un conteneur ou une machine virtuelle qui constitue elle-même la frontière, pas pour un portable qui héberge vos clés SSH, vos identifiants cloud et le .env de production.
La distinction entre les deux mécanismes devient simple une fois qu'on les met côte à côte :
- La sandbox décide ce qu'une commande peut toucher : quels chemins sont inscriptibles, si des sockets peuvent être ouvertes. Elle est appliquée par le système d'exploitation, donc une commande que le modèle n'avait pas l'intention de lancer est confinée exactement comme une commande voulue.
- Les approbations décident quand Codex s'arrête pour vous demander. C'est un point de contrôle humain, et il ne fonctionne que si un humain le lit.
danger-full-access seul vous laisse encore le point de contrôle. --yolo ne vous laisse que le jugement du modèle, et le jugement du modèle est précisément ce qu'une prompt injection cachée dans un README, une fixture de test ou le message d'erreur d'une dépendance cherche à fléchir. Ce n'est pas théorique : notre guide sur les évasions de sandbox des agents de code montre comment le contenu d'un dépôt devient une commande, et le schéma s'applique à Codex sans modification.
-a never, --full-auto et « mode unsafe », est-ce la même chose ?
Non. Ils desserrent des couches différentes, et l'un des trois n'est même pas un flag. Voici la carte complète :
| Ce que les gens tapent | Ce que c'est vraiment | Sandbox | Approbations |
|---|---|---|---|
--sandbox danger-full-access, « full access » | Un mode de sandbox | Coupée | Inchangées |
--ask-for-approval never, -a never | Une politique d'approbation | Inchangée | Coupées |
--dangerously-bypass-approvals-and-sandbox, --yolo | Un flag de contournement | Coupée | Coupées |
--full-auto | Flag de compatibilité déprécié ; la référence renvoie vers --sandbox workspace-write | Active | Comportement hérité |
| « mode unsafe », « mode dangereux », « run dangerously » | Pas un flag Codex | Selon ce qu'on voulait dire | Selon ce qu'on voulait dire |
--ask-for-approval accepte untrusted (exécute seul les lectures réputées sûres, demande pour tout ce qui modifie un état), on-request (le défaut : le modèle demande quand il veut escalader, atteindre le réseau ou sortir de l'espace de travail) et never. Les versions plus anciennes acceptaient aussi on-failure, qui exécutait tout dans la sandbox et ne demandait qu'en cas d'échec ; --full-auto était le raccourci de cette combinaison, ce qui explique qu'il survive aujourd'hui comme flag de compatibilité.
Le préréglage « Full access » du sélecteur interactif combine danger-full-access et never, et OpenAI l'étiquette « not recommended » dans sa propre documentation des approbations. C'est --yolo avec un nom plus aimable.
L'accès complet de Codex est-il sûr ?
L'accès complet de Codex est sûr exactement tant que l'environnement qui l'entoure l'est, et dangereux dès qu'il ne l'est plus. Dans un conteneur neuf sans identifiants, avec un clone jetable et une règle de sortie réseau, danger-full-access est un compromis raisonnable : le conteneur est la sandbox, et celle de Codex ne ferait que le ralentir. Sur un poste de développeur, cela signifie qu'un modèle doté de votre identité peut lancer curl vers n'importe où, écrire n'importe où et lire chaque token de votre répertoire personnel, et que la seule chose qui sépare une instruction hostile de ce résultat est la décision du modèle de ne pas obéir.
Les données dont nous disposons sur les agents non gardés ne rassurent pas. Dans notre étude de montée en charge, des agents travaillant sans couche de garde ont exécuté DROP SCHEMA contre une base de données applicative vivante dix-huit fois, et l'un d'eux a lancé rm -rf hors de son propre projet. Lorsque nous avons placé un garde de commandes devant les mêmes agents, il a vérifié 1 769 commandes shell sur l'ensemble des sessions et en a stoppé dix-sept en plein vol : un sudo destructeur hors du projet, une suppression de schéma, et l'installation d'un paquet qui n'existe pas sur le registre. Dix-sept sur 1 769, c'est moins d'un pour cent, et un pour cent de « exécute toutes les commandes » est justement le chiffre qui compte quand la commande est destructrice.
exécutions de DROP SCHEMA contre une base vivante par des agents non gardés, dans notre étude
commandes shell vérifiées dans les sessions gardées de la même étude
commandes stoppées en plein vol : sudo destructeur, suppression de schéma, paquet inexistant
Notez ce contre quoi l'accès complet ne vous protège pas, même dans un environnement propre : le code. Une sandbox confine des commandes ; elle n'a aucun avis sur la justesse du contrôle d'autorisation que le modèle vient d'écrire. Nous y revenons à la fin.
Comment la sandbox de Codex fonctionne-t-elle sur macOS, Linux et Windows ?
Codex applique sa sandbox avec le système d'exploitation, pas avec le modèle, et c'est pour cela qu'elle tient même quand le modèle est manipulé. Sur macOS, elle repose sur le framework Seatbelt d'Apple, le mécanisme de politiques sandbox-exec qui confine déjà les démons système, et elle fonctionne sans installation. Sur Linux et sous WSL2, elle utilise bubblewrap (bwrap) avec des filtres seccomp ; les versions antérieures utilisaient directement Landlock et seccomp. Sur Windows, elle utilise une sandbox Windows native, avec ou sans élévation, depuis PowerShell, et le mécanisme Linux sous WSL2.
Deux conséquences pratiques en découlent. Si bwrap manque sur une machine Linux, Codex ne peut pas y construire sa sandbox : installez-le avant de vous croire protégé. Et si une commande est refusée sans que vous sachiez pourquoi, codex sandbox exécute une commande sous la politique courante à des fins de diagnostic, avec --log-denials sur macOS pour afficher ce que Seatbelt a bloqué. C'est le bon outil pour « Codex ne peut pas écrire ici », et une bien meilleure réponse que de dégainer danger-full-access.
Seatbelt règle aussi une question qui revient beaucoup dans les recherches : « Codex seatbelt » n'est pas une option à activer. C'est la matière dont read-only et workspace-write sont faits sur un Mac.
Quand l'accès complet est-il le bon choix ?
L'accès complet est le bon choix quand quelque chose d'autre constitue déjà la frontière. Le schéma qui fonctionne :
Trois vérifications avant de basculer le flag :
- Que peut lire le processus ? Si
~/.ssh,~/.aws,~/.codex/auth.jsonou un.envavec des clés actives est accessible, la réponse n'est pas l'accès complet. Le fichier d'identifiants de Codex a déjà été la cible d'un paquet npm malveillant ; ne facilitez pas la tâche. - Où peut-il envoyer des données ? Réseau sans restriction plus prompt injection égale canal d'exfiltration. Si vous ne pouvez pas restreindre la sortie, laissez
network_accessfermé et laissez Codex demander. - Qui lit la sortie ? Dans les pipelines
codex exec, personne ne regarde les approbations de toute façon, ce qui est une raison de s'appuyer davantage sur la sandbox, pas de la retirer.
Si l'une des trois échoue, utilisez plutôt la configuration ci-dessous.
Que faut-il utiliser à la place de --yolo ?
Pour presque toutes les tâches, workspace-write avec des approbations on-request, le réseau fermé et le projet marqué comme de confiance vous donne un agent rapide qui ne peut toujours pas quitter sa voie. Dans ~/.codex/config.toml :
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[sandbox_workspace_write]
network_access = false
writable_roots = ["/Users/vous/scratch"]
[projects."/Users/vous/work/payments-api"]
trust_level = "trusted"
trust_level = "trusted" indique à Codex d'appliquer la configuration .codex/ propre au projet ; les projets non approuvés ignorent ces couches locales, ce qui est exactement ce que vous voulez pour un dépôt que vous venez de cloner chez un inconnu. Si ce sont les demandes qui gênent, resserrez ce qui les déclenche plutôt que de les couper : les versions récentes exposent une approval_policy granulaire et une option approvals_reviewer = "auto_review" qui confie les approbations à un relecteur automatique. Considérez l'auto-review comme une commodité, pas comme une frontière : c'est un modèle qui juge un modèle.
Pour la CI et codex exec, gardez la sandbox et ne retirez que les demandes : --sandbox workspace-write -a never sur un runner qui n'a aucun identifiant de production est une posture cohérente. --yolo sur le même runner ne l'est pas, parce que la sandbox ne vous coûtait rien.
La brèche qu'aucun flag ne ferme
Chaque flag de cet article gouverne ce que Codex peut exécuter. Aucun ne gouverne ce que Codex écrit, et c'est dans le code que vit désormais l'essentiel du risque. Une sandbox workspace-write laissera volontiers l'agent committer un endpoint sans contrôle d'autorisation, un gestionnaire de remboursement sans plafond ou une requête construite par concaténation de chaînes, parce qu'aucun de ces éléments n'est une commande. Ce sont des diffs.
C'est la couche que VibeDefend ajoute au moment de l'agent. Elle se place dans la boucle de Codex, confronte le diff que l'agent s'apprête à écrire à vos propres règles, réécrit la version dangereuse avant qu'elle n'atterrisse, et garde les commandes shell avec la politique qui a produit les dix-sept blocages ci-dessus. Dans notre étude, les agents équipés de la couche ont respecté les règles de sécurité sur 89 % des tickets, contre 12 % pour des agents dotés d'un simple fichier de règles dans le dépôt. La sandbox tient Codex à l'écart de votre machine ; le garde tient son code à l'écart de votre file d'incidents.
Si vous lancez Codex en --yolo délibérément, dans un conteneur, avec un garde sur le diff, vous avez une configuration défendable. Si vous le lancez en --yolo sur votre portable parce que les demandes agaçaient, lisez le guide complet de sécurité Codex puis parlons-en : la correction prend environ une minute.
Questions fréquentes
danger-full-access et --yolo, est-ce la même chose ?
Non. --sandbox danger-full-access retire la sandbox de l'OS et conserve les demandes d'approbation. --dangerously-bypass-approvals-and-sandbox (--yolo) retire la sandbox et les demandes. Le préréglage « Full access » du sélecteur correspond au second.
Que fait concrètement codex --yolo ?
Il exécute immédiatement chaque commande générée par le modèle, avec les droits de votre utilisateur, sur votre vrai système de fichiers, avec un réseau sans restriction, et ne demande jamais rien. La référence d'OpenAI le réserve à un environnement durci de l'extérieur, c'est-à-dire un conteneur ou une VM qui constitue elle-même la frontière.
-a never est-il dangereux à lui seul ?
Moins qu'on ne le croit, tant que la sandbox reste active. --ask-for-approval never retire le point de contrôle humain, mais workspace-write confine toujours les écritures et le réseau reste fermé sauf si vous l'avez ouvert. Il devient dangereux à l'instant où on l'associe à danger-full-access.
Qu'appelle-t-on le « mode unsafe » de Codex ?
Aucun flag ne porte ce nom. « Mode unsafe », « mode dangereux » et « run dangerously » désignent selon les gens danger-full-access, --yolo ou -a never, qui sont trois choses différentes. Vérifiez ce qu'un tutoriel veut vraiment dire avant de copier la commande.
Comment autoriser le réseau à Codex sans passer en accès complet ?
Mettez network_access = true sous [sandbox_workspace_write] dans config.toml, ou passez -c sandbox_workspace_write.network_access=true pour une seule exécution. Les écritures restent confinées à l'espace de travail ; seul le réseau s'ouvre.
La sandbox de Codex fonctionne-t-elle sous Windows ?
Oui. Depuis PowerShell, elle utilise une sandbox Windows native, avec ou sans élévation ; sous WSL2, elle utilise le mécanisme Linux (bubblewrap et seccomp). Les valeurs de --sandbox et les clés de config.toml sont identiques sur toutes les plateformes.
La sandbox arrête-t-elle la prompt injection ?
Elle confine ce qu'une commande injectée peut toucher ; elle n'arrête pas l'injection. Un README malveillant peut toujours pousser le modèle à écrire du code non sécurisé, ou à demander une escalade qu'un humain fatigué approuve. Gardez la sandbox active, et ajoutez une couche qui vérifie le code et les commandes, pas seulement les chemins de fichiers.
