Gardez les secrets hors de l’environnement de travail et refusez l’accès aux fichiers sensibles. Commencez par combiner ces deux mesures.
Le mode lecture seule, les approbations et le refus de participer à l’entraînement ont des objectifs différents. Vérifiez chaque contrôle séparément pour savoir s’il peut empêcher l’accès aux fichiers secrets.
Vérifiez séparément la lecture, l’exécution et la transmission
Retirez les secrets inutiles de l’environnement de travail. Envisagez une règle de lecture deny pour les fichiers sensibles.
Vérifiez qui examine les approbations. Évitez d’élargir les limites avec Full access ou une autorisation d’exécution hors du sandbox.
Vérifiez séparément le réseau des commandes, la transmission au modèle et l’accès du navigateur ou de MCP.
La documentation d’OpenAI sur Permissions, Sandbox, les approbations, la sécurité et la configuration a été revue le 8 octobre 2026. Ce guide concerne les commandes exécutées dans un sandbox local. La configuration d’exemple n’a pas été appliquée et son efficacité n’a pas été vérifiée sur une machine réelle. Aucun réglage de l’appareil ou du compte n’a été modifié.
Sommaire
- 1. Lecture seule, approbations et réglages d’entraînement
- 2. Garder les secrets hors de l’environnement de travail
- 3. Exemple de configuration pour refuser les lectures
- 4. Motifs .env et lacunes à vérifier
- 5. Ce que la désactivation du réseau des commandes bloque ou non
- 6. Variables d’environnement, systèmes d’exploitation et Cloud
- 7. Vérifier avec des fichiers fictifs
- Questions fréquentes
1. Lecture seule, approbations et réglages d’entraînement
Empêcher la modification des fichiers ne revient pas à empêcher leur lecture.
Mode qui restreint l’écriture. Il ne masque pas comme secrets le contenu des fichiers lisibles.
Définit les emplacements où l’édition est autorisée. Il ne limite pas nécessairement la lecture à ces mêmes emplacements.
| Contrôle | Ce qu’il régit principalement | Ce qu’il ne garantit pas à lui seul |
|---|---|---|
| Mode lecture seule | La possibilité de modifier les fichiers | Que les fichiers secrets accessibles ne seront pas lus |
| Politique d’approbation | Qui examine les actions franchissant une limite | Un examen humain de chaque lecture dans le périmètre autorisé |
| Règles de refus d’accès aux fichiers | Le refus des lectures et écritures aux chemins indiqués | Supprimer le contenu déjà collé ou empêcher l’accès par d’autres outils |
| Restrictions réseau des commandes | Les destinations réseau des commandes exécutées dans le sandbox | Bloquer tout le trafic des modèles, de l’authentification, des navigateurs, de MCP et d’autres services |
| Réglages d’entraînement | L’utilisation des données traitées pour améliorer les modèles | Que les données ne seront ni traitées ni transmises |
Même avec on-request, les commandes dans le périmètre autorisé peuvent s’exécuter sans approbation supplémentaire. Pour un examen humain, vérifiez à la fois la politique d’approbation et le destinataire de la demande d’examen.
En quoi l’examen automatique par IA diffère
approvals_reviewer = "auto_review" dirige l’examen concerné vers une IA. Il ne s’agit pas d’un examen humain et cela n’impose pas un examen à chaque action déjà autorisée.
Source : OpenAI : approbations et limites du sandbox. L’entraînement est traité séparément dans les réglages d’entraînement de ChatGPT et Codex et les informations confidentielles.
2. Garder les secrets hors de l’environnement de travail
Une modification d’interface peut ne nécessiter que du code source et des données fictives. Les clés API de production, les données clients et les documents familiaux n’ont pas besoin de se trouver dans ce même environnement.
Déplacer les fichiers dans un autre dossier ne suffit pas. Si des droits de lecture étendus restent actifs, ces fichiers peuvent toujours être accessibles.
N’incluez que le nécessaire dans la copie de travail
Utilisez de petites entrées reproduisant le problème plutôt que des données de production.
Les exemples de configuration doivent contenir uniquement des noms de champs. Vérifiez aussi les journaux, les sauvegardes et l’historique.
Vérifiez si d’autres dossiers, le répertoire personnel, le stockage partagé ou des applications connectées sont accessibles.
Les règles d’exclusion de Git empêchent-elles la lecture ?
.gitignore indique les fichiers non suivis que Git doit ignorer. Il ne supprime pas les droits de lecture du système d’exploitation. Même si un outil de recherche ignore normalement un fichier, cela ne garantit pas que sa lecture via un chemin explicite sera refusée. Ajouter une règle d’exclusion n’affecte pas non plus les fichiers déjà suivis par Git. Documentation Git : portée de gitignore.
Instructions et refus d’accès effectif
Écrire « ne lis pas les secrets » dans AGENTS.md peut fournir des instructions de travail utiles. Cela ne crée pas en soi de restrictions d’accès du système d’exploitation. Combinez les instructions avec un refus d’accès effectif. Consultez les précautions pour saisir des informations dans des outils d’IA pour des exemples d’anonymisation des entrées.
3. Exemple de configuration pour refuser les lectures
Les profils de permissions sont une fonctionnalité bêta. Vérifiez les environnements compatibles et la configuration sélectionnée dans la session actuelle avant de les utiliser.
read : lectureAutorisation de lire la cible
write : éditionAutorisation d’écrire sur la cible
deny : refusRefuse à la fois la lecture et l’écriture sur la cible
Attention aux conflits avec les anciens réglages du sandbox
Les profils de permissions peuvent ne pas être utilisés lorsque les anciens réglages restent actifs.
Vérifiez les réglages en conflit et les contrôles administrateur
Ne mélangez pas les anciens réglages : default_permissions et [permissions] ne sont pas destinés à être combinés avec les anciens réglages sandbox_mode ou [sandbox_workspace_write]. Normalement, si la configuration chargée contient sandbox_mode ou si le démarrage utilise --sandbox, l’ancien mécanisme est utilisé. Les contrôles administrateur via allowed_permission_profiles constituent une condition distincte.
Le bloc suivant est une proposition de configuration illustrative qui ajoute le refus des fichiers secrets et l’approbation humaine à l’exemple officiel limité à l’espace de travail. Ne remplacez pas toute votre configuration existante par ce bloc. Vérifiez la compatibilité de la version, les restrictions de l’organisation et les chemins d’exécution nécessaires, puis testez dans un environnement fictif.
Où configurer : réglages utilisateur et projet
~/.codex/config.toml
.codex/config.toml
Leur périmètre et leurs conditions de chargement diffèrent. La configuration du projet n’est chargée que pour les projets de confiance.
default_permissions = "project-private"
approval_policy = "on-request"
approvals_reviewer = "user"
[permissions.project-private]
extends = ":workspace"
[permissions.project-private.filesystem]
":root" = "deny"
":minimal" = "read"
[permissions.project-private.filesystem.":workspace_roots"]
".env" = "deny"
".env.production" = "deny"
"secrets" = "deny"
[permissions.project-private.network]
enabled = falseQuels chemins cet exemple couvre-t-il ?
Appliqué à l’espace de travail actuel et à chaque espace supplémentaire
.envVisé par le refus.env.productionVisé par le refussecrets/ et son contenuVisé par le refussubfolder/.envÀ vérifier séparémentSecrets renommés ou copies dans les journauxÀ vérifier séparément:root refuse la lecture. Les exceptions comprennent :minimal pour l’exécution et les répertoires temporaires autorisés par le profil hérité.
Hérite de l’accès en édition de :workspace et refuse les chemins précis indiqués ci-dessus. Cet exemple ne détecte pas les secrets incorporés dans les sorties.
Noms des profils, espaces de travail multiples et fichiers temporaires
project-private est le nom choisi pour cet exemple. :workspace_roots s’applique à l’espace de travail actuel et aux espaces supplémentaires, en visant les chemins indiqués directement dans chaque racine. secrets vise un fichier ou une sous-arborescence portant ce nom.
Cette configuration n’empêche pas toutes les lectures hors de l’espace de travail. Il faut également éviter de copier des secrets dans le stockage temporaire.
Source : OpenAI : configuration, refus et périmètre des profils de permissions. Cet article ne rapporte pas l’application de l’exemple sur une machine réelle ni la vérification de l’isolation.
4. Motifs .env et lacunes à vérifier
Les noms exacts conviennent aux secrets stockés à des emplacements connus. Avec des motifs, n’oubliez pas que *.env et .env.* sont différents. Ne supposez pas que l’exemple officiel **/*.env refuse aussi .env.production dans les mêmes conditions.
| Exemple de règle | Cible prévue | À vérifier séparément |
|---|---|---|
.env | Un fichier portant ce nom directement à la racine de l’espace de travail | Sous-dossiers et noms de fichiers avec un suffixe ajouté |
.env.production | Le fichier de configuration de production à la racine | Configurations de production sous d’autres noms ou copies |
secrets | Le chemin portant ce nom à la racine et son contenu | Copies ailleurs, dans des journaux ou sauvegardes par exemple |
**/*.env | Fichiers se terminant par .env à différents niveaux de répertoire | Noms avec suffixe, profondeur du parcours et modifications après le démarrage |
Vérifiez la profondeur des répertoires et les fichiers ajoutés après le démarrage
Sur Linux, WSL et Windows natif, les motifs de refus contenant ** sans restriction peuvent nécessiter une expansion bornée avant le démarrage. La documentation officielle décrit le réglage de glob_scan_max_depth à au moins 1, ou la définition explicite de la profondeur avec des motifs tels que *.env, */*.env et */*/*.env. Si vous utilisez des répertoires plus profonds, vérifiez la couverture jusqu’à cette profondeur.
Certains mécanismes d’application collectent les chemins correspondants avant le démarrage. Vérifiez si les fichiers créés ensuite sont refusés sur le système d’exploitation, la version et l’environnement d’exécution que vous utilisez réellement. Ne considérez pas les motifs de refus comme une règle universelle protégeant nécessairement tous les futurs secrets.
Quelle règle prévaut lorsque les permissions se chevauchent ?
Une règle de chemin plus précise peut remplacer une règle plus générale. Le refus prévaut pour un même chemin, mais une autorisation restreinte peut également être créée à l’intérieur d’un refus général. Vérifiez aussi les couches de configuration supplémentaires et l’héritage des profils parents.
Sources : OpenAI : refuser les lectures avec des chemins et des motifs, ordre de chargement de la configuration. Le fichier du projet .codex/config.toml n’est chargé que dans les projets de confiance. Distinguez ce qui figure dans un fichier de ce qui est actif dans la session actuelle.
5. Ce que la désactivation du réseau des commandes bloque ou non
Désactiver le réseau des commandes restreint l’usage du réseau par les programmes exécutés dans le sandbox concerné. Toutefois, les requêtes de modèles et d’authentification du client Codex sont distinctes des contrôles réseau des commandes. Un interrupteur réseau des commandes désactivé ne prouve pas que le code lu par Codex ne sera pas transmis comme contexte au modèle.
Ce que couvrent les restrictions réseau des commandes
Activité réseau des commandes, scripts et de leurs processus enfants.
Modèles et authentification, recherche web, applications connectées, MCP, navigateur et Computer Use, et tâches dans le cloud.
Pour autoriser le réseau tout en limitant les destinations, vous devez activer le proxy réseau et définir des règles de domaine. Une liste de domaines autorisés dans un profil n’active pas ces règles à elle seule.
| Réseau des commandes | Proxy | Résultat |
|---|---|---|
| Désactivé | Quel que soit le réglage | Le réseau des commandes n’est pas autorisé |
| Activé | Désactivé | Les connexions directes sont possibles ; les règles de domaine du profil ne s’appliquent pas |
| Activé | Activé | Le proxy applique les règles de domaine et refuse les destinations externes si aucune n’est autorisée |
Les secrets peuvent toujours être envoyés à une destination autorisée. Restreindre les domaines ne revient pas à inspecter le contenu envoyé. En approuvant une exécution hors du sandbox, ne supposez pas que les règles de refus actuelles vous protègent encore à l’identique. Vérifiez ce que cette approbation élargit. OpenAI : permissions réseau et exigences du proxy.
6. Variables d’environnement, systèmes d’exploitation et Cloud
Les secrets ne se limitent pas aux fichiers. Si le shell contient une clé API, un processus enfant peut utiliser sa valeur grâce aux variables d’environnement héritées, même si l’accès au fichier est refusé. L’héritage de l’environnement est géré séparément avec shell_environment_policy.
Exclusion automatique des variables : true ou false
true | Par défautN’applique pas l’exclusion automatique des variables dont le nom contient KEY, SECRET ou TOKEN
falseApplique cette exclusion automatique
ignore_default_excludes. Ce réglage est distinct des règles de refus des fichiers et filtre par nom de variable ; il ne détecte pas tous les secrets.Cela ne protège pas les variables portant d’autres noms ni les valeurs récupérées ailleurs par les programmes. set est appliqué après l’exclusion et peut rétablir des variables exclues. OpenAI : héritage de l’environnement et ordre de priorité.
Windows : vérifiez aussi l’implémentation du sandbox
Les profils de permissions locaux sont documentés pour macOS, Linux, WSL et Windows natif, mais leurs implémentations diffèrent. Sur Windows, le sandbox avec élévation est présenté comme l’approche plus robuste. Le sandbox sans élévation offre une isolation réseau plus faible et ne peut appliquer certaines politiques d’isolation en lecture et écriture. Selon la documentation, les politiques non prises en charge entraînent un refus d’exécution. Une erreur ne justifie pas de passer à Full access. OpenAI : application selon le système d’exploitation.
Cloud : ne réutilisez pas les réglages locaux tels quels
Vérifiez séparément les réglages de l’environnement Codex Cloud concerné. Ne supposez pas que les profils locaux s’appliquent automatiquement à tout Cloud ou à l’environnement cloud de dot. Ne réutilisez pas sans modification la proposition locale de cet article comme configuration cloud. Consultez Codex Remote, Cloud et conditions de connexion du PC pour les différences entre lieux d’exécution.
7. Vérifier avec des fichiers fictifs
« J’ai demandé de ne pas lire », « j’ai enregistré la configuration » et « la lecture a réellement été refusée » sont des preuves différentes. Il n’est pas nécessaire de tester en faisant lire de vrais secrets à Codex. Ce qui suit est un plan de vérification pour l’utilisateur ou l’administrateur, pas un compte rendu de tests sur cet appareil.
- Consignez l’environnement : Notez la version de Codex, le système d’exploitation, le lieu d’exécution et les permissions sélectionnées. Dans la CLI, vérifiez le périmètre de l’espace de travail avec
/statuset les permissions sélectionnées avec/permissions. - Vérifiez les conflits de configuration : Examinez les réglages utilisateur, ceux du projet de confiance, le profil sélectionné, les options de démarrage et les restrictions administrateur. Ne collez pas des fichiers de configuration complets ni des valeurs secrètes dans la conversation pour le diagnostic.
- Préparez des fichiers fictifs : Dans un espace de travail séparé sans secrets, créez des fichiers censés être autorisés et refusés. Utilisez des marqueurs fictifs comme contenu.
- Vérifiez l’autorisation et le refus : Par la même voie d’exécution, confirmez que les fichiers autorisés peuvent être lus et que les lectures refusées produisent une erreur. Le choix volontaire de Codex de ne pas lire un fichier ne prouve pas un refus effectif.
- Testez différents emplacements : Vérifiez les fichiers fictifs à la racine, dans des sous-dossiers, avec des noms suffixés et créés après le démarrage. N’approuvez pas une action contournant le refus. Si une lecture inattendue réussit, cessez d’utiliser cet environnement et cherchez la cause.
- Vérifiez aussi les sorties : Vérifiez si les tests ou compilations affichent des secrets dans les journaux ou transmettent les mêmes informations à d’autres outils MCP, navigateurs ou applications connectées.
Les informations disponibles varient selon la version de la CLI et l’affichage ; vérifiez la sortie réelle plutôt que de vous fier aux noms des commandes. La CLI officielle propose aussi des contrôles propres au système d’exploitation via codex sandbox. Avant de les considérer comme équivalents, vérifiez que les réglages testés avec une commande auxiliaire correspondent à ceux actifs dans votre session habituelle de bureau ou d’IDE. OpenAI : tester le sandbox.
Ajouter des règles de refus ensuite n’annule pas le contenu déjà lu. Vérifiez séparément le stockage des anciennes conversations, journaux et fichiers, ainsi que les réglages d’entraînement. La lecture réussie d’un fichier ne démontre pas à elle seule une divulgation à un tiers. Évaluez séparément ce qui a été lu, sa destination et la nécessité d’intervenir sur les identifiants.
Des utilisateurs ont également demandé des moyens d’exclure les fichiers secrets dans une demande publique concernant Codex. Cela illustre une préoccupation réelle, sans prouver que la fonctionnalité est toujours absente aujourd’hui. Cet article fonde ses affirmations sur la documentation officielle actuelle de Permissions, plutôt que sur d’anciens messages.
Questions fréquentes
Le mode lecture seule empêche-t-il l’envoi de .env ?
Le mode lecture seule n’offre pas cette garantie : il restreint les modifications. Pour éviter que le contenu lisible de .env devienne du contexte pour le modèle, vérifiez séparément le refus de lecture du fichier et un environnement de travail sans secrets.
.gitignore ou AGENTS.md suffisent-ils ?
Ils ne remplacent pas un refus effectif de lecture. Les règles d’exclusion de Git, les instructions de travail et les permissions imposées par le système d’exploitation sont des mécanismes distincts. Vérifiez avec des fichiers fictifs que le refus fonctionne dans l’environnement d’exécution actuel.
Désactiver le réseau fait-il fonctionner Codex entièrement sur l’appareil ?
Non. Les restrictions réseau des commandes ne désactivent pas la communication avec les modèles ou les services d’authentification. Les réglages du navigateur, de MCP, des applications connectées et du cloud sont également distincts.
Cet exemple protège-t-il totalement les secrets sur Windows ?
La protection totale n’est pas garantie. Il faut vérifier la compatibilité de la fonctionnalité bêta, l’implémentation du sandbox du système d’exploitation, les couches de configuration réelles, les chemins et les outils exécutés. L’exemple de cet article n’a pas été appliqué ni testé sur une machine réelle.
