Permissions, bac à sable et approbations : ajustez le niveau de contrôle à votre guise
📚 Navigation dans la série : Le chapitre précédent 14 · Workflows courants a intégré Codex dans votre flux de développement quotidien. Ce chapitre aborde une autre dimension — non pas « comment il travaille », mais « jusqu'où il ose aller » : de la demande de confirmation pour chaque commande à l'exécution en totale autonomie, nous allons voir comment régler les curseurs du bac à sable et des approbations, et quelle configuration adopter selon les situations.
Laissez-moi vous raconter une bêtise que j'ai faite l'hiver dernier. À l'époque, je venais de me familiariser avec Codex. Pour me faciliter la tâche, j'avais configuré en dur sandbox_mode = "danger-full-access" dans mon fichier ~/.codex/config.toml, sous prétexte que « les fenêtres de confirmation m'agaçaient ». Puis, un jour, dans un répertoire temporaire sans dépôt Git initialisé, je lui ai demandé de « nettoyer les fichiers inutiles ». Il s'est mis à fouiller dans tout mon répertoire personnel — car en mode d'accès complet, aucune barrière de « zone de travail » ne le limitait. J'ai appuyé frénétiquement sur Esc pour l'interrompre, avec des sueurs froides dans le dos.
Après réflexion, le problème ne venait pas de Codex, mais de moi : j'avais défini une configuration dangereuse, censée être réservée à des conteneurs isolés, comme paramètre par défaut global. Ce n'est pas lui qui a dérapé, c'est moi qui lui ai lâché la bride là où je n'aurais pas dû.
Dans le chapitre 02, nous avons expliqué en détail les concepts de bac à sable et d'approbations en utilisant l'analogie de « la clôture d'une aire de jeux pour enfants » et du « portail + agent de sécurité ». Ce chapitre ne répétera pas les définitions, mais se concentrera sur une seule chose : vous guider pas à pas sur comment les configurer et les choisir. Quelle combinaison utiliser, comment modifier temporairement les paramètres en ligne de commande, comment les rendre persistants dans le fichier de configuration, et où tracer la ligne rouge du mode dangereux.
À la fin de ce chapitre, vous aurez en main :
- Un tableau récapitulatif montrant comment combiner les trois modes de bac à sable (
read-only/workspace-write/danger-full-access) et les trois stratégies d'approbation (untrusted/on-request/never). - Des modèles pour ajuster temporairement les réglages en ligne de commande via
--sandbox/--ask-for-approvalou pour les figer dansconfig.toml. - Le mode par défaut que Codex vous attribue au démarrage (qui dépend de la présence d'un dépôt Git dans votre dossier) et pourquoi.
- Les valeurs par défaut importantes à connaître sous le mode
workspace-write, comme le fait que le réseau soit désactivé par défaut et que le répertoire.gitsoit protégé en lecture seule. - Les limites strictes de l'option
--yolo(accès total), et pourquoi elle doit être proscrite sur votre machine locale et en production.
⚠️ Les commandes, options de configuration et valeurs par défaut présentées ci-dessous sont basées sur la documentation officielle de Codex. Les numéros de version ou les noms de modèles pouvant évoluer, fiez-vous aux informations affichées localement sur votre machine. Les « profils de permissions » (permission profiles) mentionnés sont des fonctionnalités en version Beta sujettes à modification, détaillées dans la section 05.
01 Clarification importante : Vous réglez « deux curseurs indépendants »
Commençons par dissiper l'erreur la plus fréquente : le bac à sable et les approbations ne sont pas deux niveaux d'une même échelle, ce sont deux curseurs indépendants qui gèrent chacun leur aspect.
Nous avons déjà utilisé cette analogie au chapitre 02, mais voici comment cela se traduit concrètement dans la configuration — il s'agit de deux clés distinctes dans config.toml et de deux arguments séparés en ligne de commande :
| Curseur | Rôle | Clé de configuration | Option CLI | Raccourci |
|---|---|---|---|---|
| Mode bac à sable (sandbox mode, limites du système de fichiers et du réseau) | Ce qu'il peut manipuler | sandbox_mode | --sandbox | -s |
| Stratégie d'approbation (approval policy, pause ou non pour confirmation humaine) | S'il doit vous demander l'autorisation | approval_policy | --ask-for-approval | -a |
Pourquoi insister sur cette « indépendance » ? Parce que l'incompréhension la plus classique des débutants est : « Si j'active l'accès complet, est-ce que les fenêtres de confirmation vont disparaître ? » — Non. L'accès complet (curseur de bac à sable poussé au maximum) et l'absence de confirmation (curseur d'approbation poussé au maximum) sont deux choses distinctes. Vous pouvez tout à fait autoriser l'accès à toute la machine tout en exigeant une confirmation à chaque étape, ou à l'inverse limiter Codex à de la lecture seule mais le laisser travailler sans aucune interruption. C'est la combinaison de ces deux réglages qui détermine le niveau réel de contrôle que vous ressentez.
Analogie : La boîte de vitesses et la limite de vitesse d'une voiture. Le bac à sable est comme la boîte de vitesses : en position P (read-only), la voiture ne bouge pas ; en position D (workspace-write), elle roule sur la route ; en mode tout-terrain (danger-full-access), elle peut même s'aventurer hors des sentiers battus. L'approbation ressemble aux alertes de vitesse que vous définissez : vous pouvez choisir « d'être alerté uniquement en cas d'excès de vitesse » (on-request), « d'être alerté au moindre piéton aperçu » (untrusted), ou « de couper toutes les alertes » (never). La boîte de vitesses détermine où la voiture peut aller, l'alerte détermine quand vous êtes prévenu — l'un ne remplace pas l'autre.
Voici quelques scénarios réels pour vous aider à comprendre comment ces deux aspects s'articulent :
- Vous voulez que Codex lise uniquement le code et rédige une analyse : réglez le bac à sable sur
read-onlyet l'approbation comme vous voulez — de toute façon, il ne peut rien modifier, les alertes importent peu. - Vous voulez le laisser modifier librement les fichiers du projet, mais vous alerter s'il en sort : optez pour le bac à sable
workspace-write+ l'approbationon-request. C'est la combinaison idéale au quotidien. - Vous exécutez des tâches en lot dans un conteneur isolé et ne voulez pas être dérangé : réglez le bac à sable sur
danger-full-accesset l'approbation surnever. Les deux curseurs sont poussés au maximum — mais uniquement dans un conteneur, comme nous le répéterons plus bas.
💡 En résumé : Le bac à sable (
--sandbox) gère « l'étendue des actions » et l'approbation (--ask-for-approval) gère « l'obligation de demander ». Ce sont deux curseurs distincts avec des clés de configuration séparées ; le niveau de contrôle global résulte de leur combinaison.
Ce schéma présente les deux curseurs sous forme de tableau à double entrée : l'axe horizontal représente le mode bac à sable (du plus strict read-only au plus souple danger-full-access), et l'axe vertical représente la stratégie d'approbation (du plus prudent untrusted au plus direct never). Chaque case correspond à un niveau de contrôle réel — la case encadrée en bleu workspace-write + on-request est le compromis idéal au quotidien, tandis que la case rouge en bas à droite danger-full-access + never (c'est-à-dire --yolo) ne doit être utilisée que dans des conteneurs isolés.
02 Trois modes de bac à sable : L'étendue des actions autorisées
Le curseur du bac à sable comporte trois positions. Voici comment la documentation officielle les définit, résumées selon les critères de modification de fichiers, d'accès réseau et d'usage recommandé — c'est le tableau le plus important à retenir dans cette section :
| Mode bac à sable | Modification de fichiers | Accès réseau | Usage recommandé |
|---|---|---|---|
read-only (Lecture seule) | ❌ Non (demande approbation au préalable) | ❌ | Revue de code, rédaction de spécifications, planification : « Pas touche à mes fichiers » |
workspace-write (Écriture dans la zone de travail) | ✅ Uniquement dans la zone de travail | ❌ Désactivé par défaut, activation manuelle requise | Mode par défaut recommandé pour le développement quotidien, peu intrusif |
danger-full-access (Accès complet) | ✅ Toute la machine | ✅ | Conteneurs isolés / VM, le mot « danger » est là pour une bonne raison |
Voici quelques détails techniques souvent mal compris à garder en tête :
Premièrement, l'accès réseau est désactivé par défaut en mode workspace-write. C'est un point contre-intuitif — on pourrait penser que « s'il peut modifier les fichiers, il devrait pouvoir installer des dépendances ». Ce n'est pas le cas. La documentation officielle précise que le mode workspace-write bloque les accès réseau par défaut, et qu'il faut l'activer explicitement. Pour autoriser l'accès réseau, ajoutez cette section dans votre fichier config.toml :
[sandbox_workspace_write]
network_access = trueLa première fois que j'ai demandé à Codex de faire un npm install en mode workspace-write, il s'est bloqué avec des erreurs réseau. J'ai cru à un problème de proxy avant de réaliser — c'était le bac à sable qui lui bloquait l'accès à internet. Se souvenir de ce point peut vous éviter de perdre une soirée.
Deuxièmement, la zone de travail ne se limite pas au « répertoire courant ». La documentation officielle indique que la zone de travail inclut automatiquement les répertoires temporaires (comme /tmp). Pour connaître précisément les dossiers inclus dans votre zone de travail, lancez la commande /status dans votre session. La sortie ressemble à ceci :
Sandbox: workspace-write
Approval: on-request
Workspace directories:
/Users/you/myproject
/tmpLes lignes Sandbox et Approval indiquent les modes actifs, et Workspace directories liste la zone d'écriture autorisée.
Troisièmement, même avec workspace-write, certains répertoires restent protégés en lecture seule. C'est un filet de sécurité mis en place par Codex — au sein d'une zone de travail pourtant modifiable, les chemins suivants restent inaccessibles en écriture :
| Chemin protégé | Raison de la protection |
|---|---|
<workspace>/.git | Éviter qu'il n'altère l'historique Git et ne corrompe le dépôt |
<workspace>/.agents | Éviter qu'il ne modifie sa propre configuration d'agent |
<workspace>/.codex | Identique, le répertoire de configuration propre à Codex |
Cette protection est récursive — tout le contenu de ces dossiers est verrouillé en lecture seule. Vous n'avez donc pas à craindre qu'un accès en écriture n'endommage votre dossier .git, Codex verrouille ces dossiers sensibles par défaut.
Quatrièmement, le bac à sable restreint non seulement Codex lui-même, mais aussi toutes les commandes qu'il lance. C'est un point évoqué au chapitre 02, mais son importance en pratique mérite d'être répétée : que Codex appelle git, npm ou un script de test, ces sous-commandes sont confinées dans la même limite. Vous ne risquez donc pas qu'un processus fils « s'échappe » pour modifier d'autres répertoires alors que le processus principal est restreint.
💡 En résumé : Parmi les trois modes de bac à sable,
workspace-writeis le standard au quotidien, mais gardez en tête que le réseau y est désactivé par défaut, et les répertoires.git,.agentset.codexy sont strictement protégés. Pour activer le réseau, modifieznetwork_access, et pour vérifier l'étendue de la zone de travail, utilisez la commande/status.
03 Trois stratégies d'approbation : Choisir quand être sollicité
Le curseur des approbations propose lui aussi trois niveaux. Une fois les limites du bac à sable posées, c'est la stratégie d'approbation qui décide s'il faut s'arrêter pour vous demander votre avis aux frontières autorisées :
| Stratégie d'approbation | Comportement de Codex | En clair |
|---|---|---|
untrusted (Non approuvé) | Exécute uniquement les actions de lecture jugées sûres, et demande confirmation pour le reste | Bloque toute commande suspecte ou inconnue, niveau maximal de prudence |
on-request (À la demande) | Travaille en autonomie dans les limites du bac à sable, et s'arrête pour demander confirmation dès qu'il en sort | Le choix le plus équilibré et le plus utilisé |
never (Jamais) | N'affiche aucune demande de confirmation, s'exécute directement | Souvent utilisé pour l'automatisation ; le niveau d'autorisation reste dicté par le bac à sable, cette option n'a de sens réel qu'avec un accès complet |
Un détail important de la documentation mérite d'être souligné : untrusted ne signifie pas « lecture seule ». Codex exécutera toujours automatiquement les opérations de lecture connues pour être sûres, mais il vous demandera votre accord dès qu'une commande « risque de modifier l'état du système ou de déclencher une exécution externe » (comme des actions Git destructrices ou des commandes avec des arguments de configuration écrasants). L'expérience avec untrusted est donc plus fragmentée et prudente qu'avec on-request, car les confirmations sont demandées plus souvent.
Un autre point avancé à connaître : never peut être associé à n'importe quel mode de bac à sable. Beaucoup de gens pensent à tort que never (pas de demande) équivaut à un accès total sans contrôle. C'est faux. La documentation officielle stipule que --ask-for-approval never peut s'associer à tous les modes de --sandbox. Par exemple, vous pouvez configurer read-only + never, ce qui signifie : « Permets-lui uniquement de lire les fichiers, et fais-le sans m'interrompre par des demandes de confirmation ». C'est la configuration standard et sécurisée pour les analyses en lecture seule dans les environnements d'intégration continue (CI). « Ne pas demander » et « Donner tous les droits » sont deux notions distinctes, ce qui confirme à nouveau l'indépendance de nos deux curseurs présentée à la section 01.
Concernant « qui valide les demandes », le comportement par défaut consiste à vous les afficher directement (approvals_reviewer = "user"). La documentation mentionne également une option auto_review (revue automatique) — qui délègue à un agent de revue le soin d'examiner au préalable les demandes d'approbation. Cette fonctionnalité plus avancée et en cours d'évolution fait l'objet du chapitre 16 · Sécurité et limites des risques pour ce qui est de sa logique et de ses risques associés ; pour le quotidien, la valeur user est amplement suffisante.
💡 En résumé : Le mode
on-requestest le choix par défaut idéal au quotidien ;untrustedest plus strict et prudent (il lit librement mais demande confirmation dès qu'il s'agit d'agir) ;neverélimine les questions sans étendre les droits, ce qui est très pratique en CI sous la formeread-only+never.
04 Comment les combiner : Temporairement en CLI, de façon permanente dans config.toml
Maintenant que vous connaissez les modes et les stratégies, voici comment les appliquer : temporairement via des options de ligne de commande, ou de manière permanente dans votre fichier de configuration.
Changement temporaire : Options de ligne de commande (valable pour la session en cours)
Spécifier les deux arguments au démarrage détermine le niveau de contrôle pour la session lancée. La combinaison quotidienne recommandée ressemble à ceci :
codex --sandbox workspace-write --ask-for-approval on-requestLe bac à sable est verrouillé, et Codex vous sollicite uniquement pour sortir de la zone de travail. Simple et sécurisé. En version courte avec -s et -a :
codex -s read-only -a on-request "Vérifie uniquement ce code, ne modifie rien"Vous souhaitez changer de mode sans quitter la session en cours ? Utilisez la commande slash directement dans le chat :
/permissionsUn sélecteur s'affiche pour vous permettre de choisir le profil souhaité (Read Only, Auto, Full Access, etc.), avec effet immédiat. Mon habitude personnelle est la suivante : lorsque je travaille sur un projet inconnu, je commence par basculer en lecture seule avec /permissions pour laisser l'assistant analyser le code et proposer une stratégie. Une fois que j'ai validé la démarche, je repasse en workspace-write pour le laisser coder. Cette habitude m'a évité bien des erreurs en empêchant l'IA de modifier à la va-vite un code que je ne maîtrisais pas encore.
⚠️ Le menu peut varier selon les versions : Depuis la version 0.142 du CLI Codex, les profils de permissions (Beta, sujet à modification) remplacent les anciens préréglages. Votre menu
/permissionspourrait ainsi proposer des choix de stratégies d'approbation commeAsk for approval,Approval for me, ouFull accessplutôt qu'un choix direct de typeRead Only. Pour imposer la lecture seule, utilisez l'argument de démarragecodex --sandbox read-onlyou définissezsandbox_mode = "read-only"dans votre fichier~/.codex/config.toml(Codex conserve l'ancien paramètre de bac à sable pour des raisons de compatibilité). Cette remarque s'applique à toutes les mentions de la commande/permissionspour passer en lecture seule dans la suite du texte.
Le schéma ci-dessous détaille le processus de décision en deux étapes (d'abord le bac à sable, puis l'approbation) :
Ce schéma montre le fonctionnement : pour chaque action, Codex vérifie d'abord si elle se situe dans la zone autorisée (décision du bac à sable), puis, si elle en sort, il applique la règle de validation (décision de l'approbation). Les deux étapes s'enchaînent dans cet ordre.
Configuration permanente : config.toml par défaut (s'applique à chaque démarrage)
Pour éviter de saisir les arguments à chaque fois, inscrivez votre combinaison favorite dans le fichier de configuration global ~/.codex/config.toml :
approval_policy = "on-request"
sandbox_mode = "workspace-write"Vous recherchez la configuration « la plus prudente » par défaut ? La combinaison de sécurité maximale recommandée est
approval_policy = "untrusted"avecsandbox_mode = "read-only". Codex démarrera ainsi dans le mode le plus restrictif possible, et vous pourrez étendre ses droits manuellement si nécessaire. C'est l'idéal pour les machines partagées ou les projets sensibles.
Si vous utilisez régulièrement plusieurs combinaisons différentes (par exemple une configuration quotidienne et une pour la CI), vous pouvez définir des profils de configuration (profiles) dans des fichiers distincts et les appeler avec --profile :
# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode = "read-only"Pour lancer Codex avec le profil de votre choix :
codex --profile full_auto⚠️ Attention à ne pas confondre le profil de configuration (profile) mentionné ici avec le profil de permissions (permission profile) décrit à la section 05. Bien que les noms soient proches, leurs rôles diffèrent : le premier sert à sauvegarder un ensemble de paramètres sous un nom donné, tandis que le second est le nouveau mécanisme Beta décrivant finement les droits sur le réseau et le système de fichiers. La méthode
sandbox_mode+approval_policyreste la méthode de configuration principale actuellement ; concentrez-vous sur celle-ci.
💡 En résumé : Pour des modifications ponctuelles, passez par
-s/-aou la commande/permissionsen session. Pour des réglages permanents, éditezsandbox_modeetapproval_policydans~/.codex/config.toml. Vous pouvez utiliser--profilepour basculer facilement d'un profil à un autre.
05 Configuration avancée : Contrôle précis des commandes (rules) et des limites (permission profiles) (Beta)
Les paramètres globaux de la section 04 permettent de définir les grandes lignes. Si vous avez besoin d'un contrôle plus fin, par exemple pour autoriser définitivement une commande spécifique ou en bannir une autre, Codex propose deux outils supplémentaires. Vous pouvez les ignorer lors de votre première lecture et y revenir quand le besoin s'en fera sentir.
rules : Définir des règles par commande (expérimental)
⚠️ Fonctionnalité expérimentale sujette à modification. Les règles (rules) sont documentées comme expérimentales par l'éditeur.
Le mécanisme permettant de contrôler précisément chaque commande s'appelle rules. Notez que les mots-clés de décision sont allow (autoriser), prompt (demander) et forbidden (interdire). Ne les confondez pas avec d'autres termes comme ask, approve ou deny parfois mentionnés dans des tutoriels tiers.
Ce système répond au besoin suivant : le bac à sable définit une limite globale par répertoire, mais vous pourriez vouloir que « la commande gh pr view soit toujours exécutée directement même hors de la zone de travail » ou que « la commande grep soit toujours bloquée pour vous forcer à utiliser rg ». Définir une règle par commande résout ce problème sans avoir à élargir tout le bac à sable.
Les règles se rédigent dans des fichiers portant l'extension .rules placés dans le répertoire ~/.codex/rules/. Leur syntaxe s'apparente à celle de Python (il s'agit en réalité de Starlark). Exemple de règle :
prefix_rule(
pattern = ["gh", "pr", "view"],
decision = "prompt",
justification = "Autorise l'affichage des PR, mais demande ma confirmation",
)Le paramètre decision accepte trois valeurs, avec une règle de priorité simple — la plus stricte l'emporte (forbidden > prompt > allow) :
| decision | Effet |
|---|---|
allow | Exécute directement la commande hors du bac à sable, sans confirmation |
prompt | Demande confirmation à chaque fois que la commande correspondante est détectée |
forbidden | Bloque immédiatement la commande, sans demande de confirmation |
Un mécanisme de sécurité bien pensé gère les commandes enchaînées (comme git add . && rm -rf /) : Codex les découpe et les évalue individuellement. Même si vous avez défini une règle allow pour git add, la partie rm -rf / sera interceptée et bloquée. Pour valider vos règles avant de les appliquer, utilisez la commande codex execpolicy check suivie de la commande à tester.
permission profiles : Regrouper les règles réseau et système de fichiers (Beta)
⚠️ Fonctionnalité Beta sujette à modification, incompatible avec les anciens paramètres de bac à sable. Si votre configuration contient la clé
sandbox_modeou si vous lancez Codex avec l'option--sandbox, les profils de permissions seront ignorés au profit de l'ancien mode. Choisissez l'une ou l'autre méthode, mais ne mélangez pas les deux.
Si les options classiques de type workspace-write ne sont pas assez précises pour vos besoins et que vous souhaitez spécifier exactement quel répertoire est modifiable, bloquer l'accès à vos fichiers .env, ou limiter les connexions à quelques domaines précis, les profils de permissions (permission profiles) sont faits pour cela. Ils permettent d'associer des règles de système de fichiers et des règles réseau sous un profil nommé, que vous activez via l'option default_permissions.
Trois profils sont intégrés par défaut (remarquez le préfixe deux-points) :
| Profil intégré | Rôle |
|---|---|
:read-only | Maintient les commandes locales en lecture seule |
:workspace | Autorise l'écriture dans le répertoire de travail et les dossiers temporaires du système |
:danger-full-access | Lève les restrictions de bac à sable locales, à utiliser avec précaution |
Voici un exemple de profil personnalisé (qui autorise l'écriture dans le projet mais verrouille tous les fichiers .env) :
default_permissions = "project-edit"
[permissions.project-edit]
extends = ":workspace"
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"
[permissions.project-edit.network]
enabled = true
[permissions.project-edit.network.domains]
"api.openai.com" = "allow"Le système de fichiers gère trois niveaux d'accès : read (lecture), write (écriture) et deny (interdire). La priorité suit la même logique — deny l'emporte toujours (deny > write > read), et le chemin le plus précis est prioritaire. Cette approche vous permet par exemple de rendre l'ensemble de la zone de travail modifiable tout en excluant spécifiquement vos fichiers de configuration .env. Pour le réseau, la logique repose sur une liste blanche : aucun domaine n'est accessible sauf s'il est explicitement déclaré avec allow, et toute règle deny l'emporte sur un allow.
Mon conseil est simple : commencez par maîtriser les paramètres standards décrits à la section 04. N'utilisez les profils de permissions que si vous avez un besoin réel de restreindre l'accès à un fichier sensible ou à des domaines spécifiques. N'oubliez pas de supprimer toute référence à sandbox_mode dans votre configuration avant de basculer sur ce système.
💡 En résumé : Le système
rulescible des préfixes de commandes (allow/prompt/forbidden, la plus stricte l'emporte), tandis que lespermission profiles(Beta) découpent les droits par chemins et domaines réseau (avec priorité àdeny). Ces deux outils s'adressent aux configurations avancées. Restez sur la configuration classique pour débuter et ne mélangez pas les deux systèmes.
06 Valeurs par défaut au démarrage et limites du mode dangereux
Maintenant que les concepts sont clairs, examinons comment Codex choisit ses paramètres au lancement : il applique une sélection automatique intelligente basée sur la structure de votre dossier.
Comment Codex choisit son mode par défaut
Le comportement par défaut au démarrage s'adapte selon que le dossier cible est ou non sous contrôle de version :
| Répertoire de lancement | Mode par défaut attribué |
|---|---|
| Sous contrôle de version (présence de Git) | Mode Auto (workspace-write + on-request) |
| Sans contrôle de version (pas de Git) | Lecture seule (read-only) |
Ce choix est très logique : si un dépôt Git est configuré, vous pouvez facilement analyser les modifications via git diff et annuler un changement incorrect, ce qui permet à Codex d'écrire dans la zone de travail. Dans un dossier sans historique, une modification erronée est définitive ; Codex opte donc pour la sécurité en limitant les actions à la lecture seule. Si je reprends ma mésaventure du début, c'est précisément parce que j'avais forcé un accès complet dans un répertoire temporaire sans historique Git que la situation a dérapé.
Par ailleurs, dans certains contextes, Codex démarrera systématiquement en mode read-only et attendra que vous confirmiez explicitement faire confiance au répertoire de travail (via une invite initiale ou avec /permissions) avant de débloquer l'écriture. Si Codex semble réticent à modifier vos fichiers au début, c'est simplement qu'il attend votre confirmation de confiance.
Un autre paramètre par défaut concerne la recherche sur le web : celle-ci s'appuie par défaut sur un cache (cached) et non sur une recherche en temps réel. Codex utilise un index de résultats pré-établis afin de limiter les risques d'attaques par injection de requêtes indirecte (prompt injection) via des pages web tierces. Notez un comportement important : si vous activez le mode d'accès complet (comme avec l'option --yolo), la recherche web bascule automatiquement en mode temps réel (live). Vous pouvez forcer la recherche en direct avec --search, ou la désactiver complètement avec web_search = "disabled". Nous détaillerons ces aspects de sécurité dans le chapitre 16 · Sécurité et limites des risques.
--yolo : Les limites de l'accès total
Terminons par la limite ultime en matière de droits, celle qui a causé mon erreur initiale : l'accès total sans restriction. Deux syntaxes équivalentes permettent de l'activer :
- Dans le fichier de configuration :
sandbox_mode = "danger-full-access"associé àapproval_policy = "never" - En ligne de commande : l'option
--dangerously-bypass-approvals-and-sandbox(ou son raccourci--yolopour « You Only Live Once »)
Le nom choisi pour cette option souligne les risques qu'elle comporte. Elle supprime à la fois le bac à sable et les confirmations, laissant Codex exécuter n'importe quelle action sur votre machine sans jamais vous solliciter. Voici comment évaluer son utilisation :
| Contexte | Faut-il activer --yolo / accès complet ? |
|---|---|
| Conteneur isolé / Machine virtuelle / dev container | ✅ Oui, les modifications n'impactent qu'un environnement éphémère |
| Tâches automatisées en CI (dans un conteneur) | ✅ Oui, à condition que le conteneur lui-même soit isolé |
| Machine de développement locale quotidienne | ❌ Non, gardez le système d'approbation actif quitte à valider quelques invites |
| Machine contenant du code de production ou des données sensibles | ❌ Absolument pas, c'est un risque majeur pour vos données |
La documentation officielle indique clairement que l'accès complet est non recommandé (not recommended). Si votre système ne supporte pas nativement le bac à sable Linux ou si vous développez dans des environnements conteneurisés en entreprise, la bonne pratique consiste à utiliser Docker ou un dev container pour isoler votre environnement, puis à lancer Codex avec l'option --yolo à l'intérieur du conteneur. C'est le conteneur qui sert de barrière de sécurité, et non les réglages internes de Codex. Un exemple officiel de devcontainer sécurisé avec contrôle des flux réseau sortants est d'ailleurs proposé dans la documentation.
Cependant, même dans un dev container, un accès complet comporte des risques : un projet malveillant pourrait dérober des données sensibles présentes dans le conteneur (y compris vos clés de connexion à Codex). Par conséquent, ne recourez à cette option que sur des dépôts de code de confiance, et gardez toujours un œil sur les actions effectuées.
Mon retour d'expérience tient en une phrase : n'activez l'accès complet que dans des environnements isolés dont la perte ou la corruption n'a aucune importance. Sur votre machine personnelle ou de production, conservez le système de validation. Valider quelques invites est bien moins stressant que de voir ses fichiers supprimés.
💡 En résumé : Codex s'adapte à la présence de Git (Git détecté → mode Auto, pas de Git → lecture seule) pour protéger vos données ; la recherche web utilise un cache par sécurité ; l'option
--yolo(accès total) est réservée exclusivement aux environnements isolés sous conteneur et doit être proscrite sur vos machines physiques de travail.
07 En pratique : Testez les trois niveaux de contrôle en 5 minutes
Rien ne vaut la pratique. Voici comment observer la différence de comportement de Codex entre les modes « demander confirmation » et « exécuter directement » en créant simplement un répertoire vide, sans impacter vos projets existants.
Étape 1 : Créez un répertoire de test et lancez Codex.
Sur Mac / Linux (ou sur Windows avec PowerShell, en remplaçant mkdir -p par mkdir) :
mkdir -p ~/perm-demo && cd ~/perm-demo
codexRemarque : Ce dossier ne contient pas de dépôt Git. D'après les règles de la section 06, Codex devrait démarrer par défaut en mode
read-only— ce qui nous convient pendant ce test.
Étape 2 : Vérifiez le mode actif.
Une fois la session ouverte, affichez l'état actuel :
/statusRésultat attendu : Vous devriez voir s'afficher le mode de bac à sable actif, la stratégie d'approbation et la liste des répertoires inclus dans la zone de travail.
Étape 3 : Tentez d'écrire un fichier en mode lecture seule.
Assurez-vous que le mode est bien réglé sur lecture seule (si nécessaire, utilisez /permissions pour sélectionner Read Only), puis demandez :
Crée un nouveau fichier hello.txt contenant le texte "hello codex".Résultat attendu : Codex ne va pas créer le fichier directement. Il s'arrête et affiche une demande de confirmation car l'écriture dépasse les droits du mode read-only :
J'ai besoin de créer le fichier hello.txt, ce qui dépasse les permissions actuelles du mode lecture seule. Autorisez-vous cette action ?Vous venez de voir le bac à sable et l'approbation fonctionner ensemble : le bac à sable détecte la tentative d'écriture hors limites, et la stratégie d'approbation prend le relais pour solliciter votre accord.
Étape 4 : Activez l'écriture dans la zone de travail pour comparer.
/permissionsSélectionnez le mode Auto ou Workspace Write dans le menu, puis demandez à nouveau de créer le fichier hello.txt. Résultat attendu : Le fichier est créé instantanément et sans confirmation, car l'action se situe désormais dans les limites autorisées du bac à sable.
Fichier hello.txt créé avec succès.Étape 5 (Facultatif) : Observez le blocage du réseau.
Toujours sous le mode d'écriture dans la zone de travail, tentez une action nécessitant internet :
Utilise curl pour interroger https://example.com et affiche le résultat.Résultat attendu : Le mode workspace-write bloquant le réseau par défaut (comme vu à la section 02), Codex va soit s'interrompre pour vous demander l'autorisation d'accéder au réseau, soit afficher une erreur de connexion. Cela confirme que l'accès en écriture ne donne pas automatiquement accès à internet. Pour lever cette restriction, il faudrait activer network_access dans le fichier config.toml.
Ce test rapide illustre concrètement le fonctionnement de la sécurité de Codex. Toute modification ultérieure de vos droits reposera sur ces mêmes mécanismes.
💡 En résumé : Créez un dossier vide, lancez
/status, tentez une écriture en lecture seule pour voir l'alerte, basculez en écriture dans le projet pour voir la différence, et tentez une requête réseau pour vérifier son blocage. Tester ces configurations vous-même facilite grandement la compréhension des paramètres.
08 Résumé
Ce chapitre a détaillé le fonctionnement de la sécurité et du contrôle des accès dans Codex — le niveau de liberté accordé à l'assistant dépend entièrement de la combinaison choisie pour le bac à sable et les approbations.
Voici un récapitulatif des points clés :
| Objectif | Option à utiliser | Remarque clé |
|---|---|---|
| Ajuster « l'étendue des actions » | Bac à sable --sandbox | Choix entre les trois modes : read-only, workspace-write et danger-full-access |
| Ajuster « l'obligation de demander » | Approbation --ask-for-approval | Choix entre untrusted, on-request et never (indépendant du bac à sable) |
| Modification ponctuelle | Options CLI / commande /permissions | Permet de basculer de mode directement en cours de session |
| Configuration permanente | Fichier config.toml | Définition de sandbox_mode et approval_policy ; gestion de profils avec --profile |
| Contrôle précis par commande ou répertoire | rules / permission profiles | Profils avancés ; attention, les profils de permissions excluent l'usage de sandbox_mode |
| Accès total et libre | Option --yolo | À réserver exclusivement aux conteneurs isolés, ne pas utiliser en local ou en production |
Vous êtes désormais en mesure de comprendre la différence entre les trois modes de bac à sable et les trois stratégies d'approbation, d'ajuster ces droits via les options CLI ou dans le fichier config.toml, de comprendre comment Codex adapte son mode par défaut selon la présence d'un dépôt Git, de savoir que le réseau est restreint par défaut sous workspace-write, et de limiter l'usage de l'option --yolo aux seuls environnements de conteneurs isolés. Cette maîtrise de la configuration est essentielle pour tirer pleinement parti de Codex en toute sécurité.
Le chapitre suivant 16 · Sécurité et limites des risques approfondit la dimension stratégique de ces réglages : dans quelle mesure faut-il faire confiance à une IA sur votre machine et votre code ? Comment se prémunir contre les injections de requêtes (prompt injection) ? Comment éviter la fuite de données sensibles ? Quels sont les risques réels associés à l'indexation web et à la revue automatique ? Maintenant que vous savez manipuler les curseurs, nous allons voir comment évaluer le moment de les resserrer ou de les relâcher.