Protection des données pour développeurs
OpenAI
Revue des secrets dans le CLI Codex local
Examinez à la fois les fichiers que le CLI Codex local peut lire et l'environnement que ses outils héritent. L'exécution en lecture seule ne signifie pas que chaque fichier est illisible, et un fichier .env caché n'est pas un contrôle d'accès. La documentation OpenAI actuelle décrit les profils de permission deny-read et le filtrage d'environnement ; vérifiez leur disponibilité et configuration effective dans votre client installé en utilisant uniquement des marqueurs synthétiques.
Pour Ingénierie sécurité et administrateurs Codex
Deux entrées peuvent exposer la même identification par des voies différentes.
Entrées factices et sonde booléenne hors ligne. Résultats produits non testés.01
Séparer le contenu des fichiers de l'environnement du processus
Une tâche locale peut obtenir la configuration en lisant un fichier ou via un processus outil qui hérite des variables d'environnement. Fermer un onglet d'éditeur ne supprime aucune des deux sources. Identifiez le matériel nécessaire à la tâche, et évitez de rendre disponibles des identifiants non liés à l'espace de travail ou à l'environnement de lancement.
Utilisez des marqueurs factices distincts pour les deux questions. Un marqueur fichier teste si un chemin de lecture rend le contenu disponible. Un marqueur environnement teste si une variable nommée atteint le processus outil. Les combiner en un seul résultat masque quel contrôle nécessite une attention.
Contexte source : OpenAI : Référence de configuration
02
Revue de la frontière de lecture actuelle
OpenAI distingue les permissions sandbox des décisions d'approbation. Une opération autorisée par le sandbox peut se poursuivre sous la politique d'approbation sélectionnée, donc « lecture seule » ne doit pas être interprété comme « ne peut pas lire les secrets ». Inspectez les racines effectives de l'espace de travail et le modèle de permission actuel pour le CLI installé.
L'exemple de profil inerte sélectionne d06-canary, étend le profil intégré en lecture seule et refuse uniquement .env.canary sous les racines effectives de l'espace de travail. Les profils de permission sont actuellement en version bêta et ne se combinent pas avec les anciens paramètres sandbox_mode ; les exigences gérées peuvent les restreindre davantage. Inspectez le profil effectif avant de tester. Le nom de fichier exact évite les questions spécifiques à la plateforme sur la profondeur des motifs de refus non bornés.
| Clé documentée | Exemple de fixture | Condition de revue |
|---|---|---|
| default_permissions | d06-canary | Doit être le profil sélectionné effectif |
| permissions.d06-canary.extends | :read-only | Conserver les restrictions de base |
| filesystem.":workspace_roots" .env.canary | deny | Seulement le fichier factice isolé |
| shell_environment_policy.filters | Variable factice = exclure | Fragment séparé ; conserver les autres filtres |
Contexte source : OpenAI : Approbations d’agents et sécurité · OpenAI : Profils de permission
03
Examiner ce que reçoivent les processus enfants
Le fragment d’environnement-filtre séparé nomme uniquement AONA_D06_FAKE_INHERITED avec une règle d’exclusion. Il n’active pas l’héritage ni ne définit de valeurs. La documentation actuelle interdit de combiner les filtres avec les anciens paramètres exclude/include_only, donc l’administrateur doit d’abord vérifier la configuration réelle. Conservez les preuves sur la configuration du marqueur factice et la réception booléenne plutôt que d’exporter le contenu de l’environnement.
La sonde hors ligne fournie vérifie uniquement AONA_D06_FAKE_INHERITED et émet une comparaison booléenne avec sa valeur synthétique fixe. Elle n’imprime jamais le contenu de la variable ni n’énumère l’environnement. Exécutez-la uniquement dans le contexte isolé de la fixture si cette opération est approuvée ; ne l’utilisez pas pour inspecter un véritable identifiant.
Contexte source : OpenAI : Référence de configuration
04
Collecter des observations séparées et minimales
Commencez par la base de fichiers autorisés. Puis examinez le fichier factice restreint sous le profil de permission prévu. Enregistrez toute demande d’approbation et si le marqueur a été retourné. Ne relâchez pas les contrôles pour obtenir une lecture réussie. Une base manquante nécessite une enquête avant que le résultat du fichier restreint soit utile.
Pour la vérification de l’environnement, décidez si la variable factice doit être héritée avant d’exécuter la sonde. Un résultat faux peut signifier que le filtre a fonctionné, que la variable n’a jamais été définie ou que le contexte de lancement était différent. Enregistrez ces prérequis. La feuille de résultats sépare donc la configuration, la politique prévue et l’observation au lieu d’étiqueter automatiquement un booléen comme sécurisé.
| Entrée | Fixture sécurisée | Preuves nécessaires |
|---|---|---|
| Fichier autorisé | allowed-marker.txt | Résultat de lecture de base |
| Fichier restreint | .env.canary copied from the pack | Décision sur le profil, le chemin et l’opération |
| Variable héritée | AONA_D06_FAKE_INHERITED | Configuration parente et résultat booléen enfant |
| Approval | Opération isolée réelle | Requête affichée et décision prise |
05
Conserver la conclusion locale et datée
Un rapport public de mars 2026 a soulevé des inquiétudes sur les lectures de .env. La documentation officielle actuelle décrit désormais les contrôles de refus de lecture, donc l’ancien rapport ne doit pas être présenté comme preuve que Codex moderne n’en dispose pas. Vérifiez plutôt la version CLI locale exacte et la configuration.
Ce guide ne couvre pas les scripts de configuration cloud ni les cycles de vie des secrets des agents cloud. Il n’établit pas non plus la couverture Aona de chaque résultat d’outil CLI. Terminez la revue avec les tâches locales et configurations approuvées, les propriétaires non résolus et les déclencheurs de recontrôle pour mises à jour ou modifications des paramètres de lancement.
Contexte source : Codex : préoccupation historique sur la lecture des .env · OpenAI : Profils de permission
Mettez-le en pratique
Revue locale des fichiers Codex et de l’environnement
Utilisez différents marqueurs synthétiques pour examiner les lectures de fichiers et les données héritées des processus outils.
Entrées factices et sonde booléenne hors ligne. Résultats produits non testés.
| Entrée | Règle prévue | Observé |
|---|---|---|
| Fichier autorisé | Définir une base lisible | Untested |
| Canari .env restreint | Définir la restriction de lecture | Untested |
| Variable héritée factice | Définir si l’héritage est autorisé | Untested |
Travaillez votre révision
Utilisez les vérifications pour organiser les preuves dont vous avez besoin. Enregistrez vos sélections dans Word, puis ajoutez vos notes et preuves. Vos sélections restent dans cet onglet jusqu'à leur téléchargement.
0 sur 3 révisé
Exemples et matériel de révision
Lisez les détails ici, ou conservez ensemble le PDF, le document Word modifiable et les feuilles de calcul.
Local Codex synthetic secret reviewLire
No real credentials, provider calls or automatic configuration changes are included. Use a NEW isolated folder with no real repository or secrets.
File-read review
- Copy env-canary.txt to .env.canary in this fixture folder.
- Inspect codex-permissions.example.toml. It selects d06-canary, extends :read-only and denies exactly .env.canary under effective workspace roots. It is not an active config filename. Have the authorised administrator apply only the reviewed example through the supported test configuration mechanism, preserving managed requirements and other restrictions.
- Current permission profiles are beta. They do not compose with sandbox_mode, --sandbox or sandbox_workspace_write; an older setting can cause the profile to be ignored. Confirm the effective selected profile and supported installed version before proceeding. Do not relax an existing policy to activate the example.
- Establish a permitted read of allowed-marker.txt, then request a direct read of .env.canary. The intended profile outcome is denial of that fake file. Record actual behaviour in results.csv; the pack contains no observed client result.
Separate inherited-environment review 5. Use only AONA_D06_FAKE_INHERITED=NOT_A_CREDENTIAL_D06_ENV_MARKER from fake-environment.txt in the isolated test launch. Do not substitute a real value. 6. If the already approved baseline policy permits that fake variable, run the offline environment_probe.py through the intended tool process and record whether it returns true. A false baseline leaves the setup/inheritance prerequisite unresolved; do not broaden policy to force a true result. 7. Inspect codex-environment-filter.example.toml. An authorised administrator can add its single fake-variable exclusion while preserving the rest of the test policy. Current filters must not be mixed with legacy exclude/include_only settings. The fragment does not change inheritance or inject a value. 8. Repeat the same probe in a fresh applicable test launch. The intended filtered result is false. Record the effective configuration and result separately. The probe prints only a boolean and makes no network call.
The profile uses one exact relative filename, not an unbounded glob. Broader rules have platform/version considerations documented by OpenAI. These local tests do not establish cloud-agent behaviour or universal Aona coverage.
Guide et source references
Canonical guide: https://aona.ai/resources/guides/codex-env-secrets-file-access/ Source review: 2026-09-21
- OpenAI: Agent approvals et security: https://learn.chatgpt.com/docs/agent-approvals-security
- OpenAI: Permission profiles: https://learn.chatgpt.com/docs/permissions
- OpenAI: Configuration reference: https://learn.chatgpt.com/docs/config-file/config-reference
- Codex: historical .env read concern: https://github.com/openai/codex/issues/13778
ResultsLire
| Client version | OS | Permission model | Workspace roots | Entrée | Parent setup | Intended policy | Approval | Observé | Preuve |
|---|---|---|---|---|---|---|---|---|---|
| allowed file | DEFINE | DEFINE | UNTESTED | ||||||
| restricted file | DEFINE | DEFINE | UNTESTED | ||||||
| fake inherited variable | DEFINE | DEFINE | UNTESTED |
Code fonctionnel et fichiers de test
Utilisez les fichiers originaux pour les exercices de code et de données. Le ZIP source inclut leurs instructions et données d'entrée.
Télécharger les exemples source (ZIP)Allowed markerTXT
SYNTHETIC_D06_ALLOWED_MARKER
Env canaryTXT
EXAMPLE_ONLY=NOT_A_CREDENTIAL_D06_FILE_MARKER
Fake environmentTXT
AONA_D06_FAKE_INHERITED=NOT_A_CREDENTIAL_D06_ENV_MARKER
Environment probePY
# Offline probe for one fixed synthetic variable. Never prints its value.
import json
import os
name = "AONA_D06_FAKE_INHERITED"
expected = "NOT_A_CREDENTIAL_D06_ENV_MARKER"
print(json.dumps({"fixture": "D06", "expected_fake_marker_received": os.environ.get(name) == expected}))
Codex permissions.exampleTOML
# INERT EXAMPLE: not loaded automatically. Isolated canary workspace only.
# Current permission profiles are beta. Do not combine with sandbox_mode,
# --sandbox or sandbox_workspace_write; respect managed requirements.
default_permissions = "d06-canary"
[permissions.d06-canary]
extends = ":read-only"
[permissions.d06-canary.filesystem.":workspace_roots"]
".env.canary" = "deny"
Codex environment filter.exampleTOML
# INERT FRAGMENT: adds an exclusion for one fake variable only.
# Review and preserve existing policy. Do not combine filters with legacy
# shell_environment_policy.exclude or include_only in the same layer.
# No inheritance, value, sandbox or network setting is changed here.
[shell_environment_policy.filters]
"AONA_D06_FAKE_INHERITED" = "exclude"
Avant de continuer
Gardez ces distinctions claires
- Qualifier chaque résultat faux de sonde comme un succès
- Établir d'abord si la variable factice a été définie dans le parent prévu et a atteint le contexte de lancement correct.
- Réutilisation locale des hypothèses cloud
- Les contrôles locaux des fichiers CLI et de l'environnement des processus diffèrent de la configuration hébergée et des phases d'agent.
Appliquez-le à l'utilisation de l'IA par les employés
Apportez votre chemin de données réel.
Aona peut aider à évaluer les requêtes et chemins de fichiers des points de terminaison employés pris en charge dans une évaluation locale client ciblée.
Ce dispositif ne prouve pas qu’Aona intercepte chaque commande ou résultat d’outil Codex CLI. Les capacités natives dépendent de la version installée, du système d’exploitation, du fournisseur et du transport.
Soumettre l’enregistrement de configuration locale et les observations du marqueur factice à une revue des chemins pris en charge.
Révisez votre cas d'utilisationFAQ
Questions pour cette décision
Le mode lecture seule empêche-t-il Codex de lire les fichiers .env ?
Ce guide applique-t-il une configuration Codex sécurisée ?
La sonde d’environnement affichera-t-elle un secret réel ?
Le même résultat peut-il approuver Codex cloud ?
Preuves à l'appui du guide
Sources et portée
Préparé par Aona. Sources vérifiées 2026-09-21. Le matériel cité soutient les points spécifiques ci-dessous ; il ne certifie pas un produit ni votre cas d'usage.
- OpenAI : Approbations d’agents et sécurité
Sépare les permissions du bac à sable et la politique d’approbation.
vendor · vérifié 2026-09-21 - OpenAI : Profils de permission
Documente les chemins/globs exacts d’interdiction de lecture et les considérations spécifiques à la plateforme.
vendor · vérifié 2026-09-21 - OpenAI : Référence de configuration
Documente l’héritage et le filtrage de l’environnement shell.
vendor · vérifié 2026-09-21 - Codex : préoccupation historique sur la lecture des .env
Préoccupation de praticien de mars 2026, pas une affirmation sur la capacité CLI actuelle.
practitioner · vérifié 2026-09-21