Guide pratique de sécurité Codex

Utilisez cette recette lorsque les employés doivent se connecter à Codex via l’espace de travail ChatGPT de votre entreprise, et que les comptes ChatGPT personnels ainsi que l’authentification par API key sont interdits sur les terminaux gérés.

Résultat attendu

Sur les appareils gérés par l’entreprise, Codex accepte uniquement la connexion ChatGPT à l’espace de travail ChatGPT de l’entreprise.

Prérequis

• L’UUID de l’espace de travail ChatGPT Enterprise approuvé.

• Un moyen de distribuer la configuration gérée de Codex aux terminaux.

• Une décision d’interdire l’authentification par API key sur les terminaux gérés.

Configuration

1. Consignez l’UUID de l’espace de travail approuvé dans votre dépôt de configuration interne.

2. Ajoutez les exigences d’authentification obligatoires au fichier local requirements.toml :

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

La première clé autorise uniquement l’authentification ChatGPT ; la seconde restreint la connexion à l’espace de travail approuvé. Remplacez l’UUID d’exemple par celui de votre espace de travail. Consultez la référence des exigences.

3. Déployez ces exigences via le fichier local requirements.toml ou les exigences MDM macOS, en utilisant les chemins indiqués dans Où placer la configuration. Ces exigences d’authentification s’appliquent avant le chargement des identifiants et avant la récupération de la politique cloud ; Codex les ignore dans les exigences gérées dans le cloud. Protégez le fichier et son répertoire parent contre les modifications des utilisateurs. Les anciennes valeurs par défaut managed_config.toml n’imposent pas cette restriction.

4. Pendant la phase pilote, déconnectez les utilisateurs ou supprimez les sessions Codex personnelles précédemment enregistrées. Ne supposez pas qu’une nouvelle politique invalide rétroactivement une session existante.

5. Associez la restriction de connexion aux rôles de l’espace de travail et aux accès des groupes. L’authentification contrôle l’identité qui se connecte ; le RBAC contrôle les fonctionnalités Codex que cette identité peut utiliser. Consultez Authentification.

Vérification

• Déconnectez-vous de Codex.

• Essayez de vous connecter avec un compte ChatGPT personnel. Résultat attendu : la connexion à l’espace de travail personnel est refusée.

• Essayez de vous connecter à Codex avec une API key. Résultat attendu : la connexion par API key est refusée.

• Connectez-vous à l’espace de travail approuvé avec le compte professionnel. Résultat attendu : la connexion réussit.

• Redémarrez l’application de bureau, la CLI et l’extension IDE, puis recommencez.

Retour arrière

Rétablissez les exigences d’authentification locales précédentes et redéployez l’ensemble validé.

Limites

Ce contrôle s’applique aux clients Codex gérés sur les terminaux gérés. Associez-le à des contrôles applicatifs sur les terminaux et à une politique réseau si l’exigence est d’« interdire l’utilisation personnelle de Codex depuis les ressources de l’entreprise ».

Utilisez cette recette lorsque les développeurs ont besoin d’un accès en lecture seule ou limité à l’espace de travail, et que vous souhaitez les empêcher de sélectionner Full Access ou de contourner les approbations et le bac à sable avec --yolo.

Résultat attendu

Les utilisateurs peuvent uniquement sélectionner les profils approuvés en lecture seule ou limités à l’espace de travail. Ils ne peuvent pas sélectionner danger-full-access, approval_policy = "never" ou --yolo.

Configuration

1. Définissez un profil d’espace de travail approuvé :

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. Imposez les profils et les politiques d’approbation autorisés :

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

La liste d’autorisation est exhaustive : les profils qui n’y figurent pas ou qui sont définis sur false sont refusés, y compris ceux ajoutés dans les versions futures. Consultez la Référence de configuration.

3. Pour les anciens clients qui utilisent encore sandbox_mode, utilisez :

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. Distribuez ces paramètres sous forme d’exigences imposées par l’administrateur, et non dans un fichier de configuration modifiable par l’utilisateur.

5. Si vous autorisez ultérieurement Auto-review, ajoutez-le explicitement après l’avoir testé. Auto-review change l’entité qui examine le franchissement d’une limite ; il ne rétablit pas une limite supprimée. Consultez Auto-review.

Vérification

• Ouvrez le sélecteur de permissions. Résultat attendu : Full Access est indisponible ou refusé.

• Lancez Codex avec --dangerously-bypass-approvals-and-sandbox. Résultat attendu : Codex refuse le lancement ou impose un profil compatible.

• Lancez Codex avec --sandbox danger-full-access --ask-for-approval never. Résultat attendu : le lancement est refusé.

• Exécutez une tâche habituelle dans l’espace de travail. Résultat attendu : la tâche réussit ; le franchissement des limites nécessite toujours une approbation.

Retour arrière

Rétablissez l’ensemble d’exigences précédent. Maintenez le blocage de l’accès sans restriction, sauf exception approuvée séparément.

Limites

Ce contrôle régit les permissions d’exécution de Codex. Il ne retire pas ses privilèges à un compte privilégié du système d’exploitation.

Utilisez cette recette lorsque votre organisation doit décider quels MCP servers Codex peut utiliser et imposer une liste de serveurs approuvés.

Autoriser un serveur et le configurer sont deux étapes distinctes. Une entrée de liste d’autorisation permet l’utilisation d’un serveur correspondant ; elle ne crée pas sa configuration. Configurez le serveur séparément avec le nom et l’identité correspondants, ainsi que l’authentification nécessaire.

Résultat attendu

Codex active uniquement les MCP servers dont le nom et l’identité configurés correspondent à la liste approuvée par l’entreprise.

Configuration

1. Recensez chaque serveur approuvé : responsable, usage, transport, exécutable ou URL exacts, authentification, classification des données et outils capables d’écrire des données.

2. Commencez par tout refuser. Une table gérée vide désactive tous les MCP servers :

   [mcp_servers]

3. Ajoutez les serveurs HTTP approuvés par leur URL exacte :

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. Ajoutez les serveurs stdio approuvés par leur exécutable et leurs arguments positionnels :

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

Le mécanisme de correspondance structuré vérifie l’exécutable, le nombre d’arguments et leur ordre. Il ne contraint pas cwd, env ou env_vars. Considérez la maîtrise de l’ensemble du contexte de lancement comme un prérequis à l’approbation d’un serveur stdio : protégez son exécutable et ses dépendances, et empêchez les configurations utilisateur ou de projet non fiables de fournir un répertoire de travail ou un environnement susceptible de modifier son comportement. Si vous ne pouvez pas imposer cette limite de manière indépendante, ne validez pas le serveur stdio et utilisez plutôt un serveur HTTP ayant fait l’objet d’un examen.

5. Ajoutez séparément les identités MCP incluses dans les plugins sous plugins.<plugin>.mcp_servers.<server>.

6. Conservez la liste approuvée dans un dépôt de configuration soumis à examen et déployez-la via des exigences imposées par l’administrateur.

Le client active un serveur uniquement lorsque son nom et son identité correspondent tous deux à une entrée approuvée. Consultez Configuration gérée.

Vérification

• Configurez le serveur approuvé à l’identique. Résultat attendu : le serveur démarre.

• Modifiez un caractère de l’URL. Résultat attendu : le serveur est désactivé.

• Modifiez le nombre ou l’ordre des arguments stdio, ou fournissez un argument qui ne respecte pas les règles configurées. Résultat attendu : le serveur est désactivé. Les valeurs qui respectent toujours un préfixe autorisé restent permises.

• Dans un projet de confiance jetable, essayez des substitutions inoffensives de cwd, env et env_vars tout en conservant l’exécutable et les arguments correspondants. La seule correspondance d’identité ne rejette pas ces substitutions. Vérifiez que votre contrôle indépendant du contexte de lancement rejette les substitutions dangereuses ou que le serveur stdio reste non approuvé ; n’utilisez pas de véritable charge d’injection.

• Ajoutez un nom non approuvé. Résultat attendu : le serveur est désactivé.

• Testez un serveur inclus dans un plugin. Résultat attendu : le serveur fonctionne uniquement avec l’identité approuvée.

Retour arrière

Supprimez l’entrée nouvellement ajoutée. Pour interrompre immédiatement toute utilisation de MCP, déployez une table mcp_servers vide.

Limites

Une liste d’autorisation d’identités ne prouve pas que les outils, les données en amont, les identifiants ou l’environnement de lancement d’un serveur sont sûrs. Les processus MCP stdio locaux s’exécutent en dehors du bac à sable des commandes locales ; la correspondance d’un exécutable et de ses arguments ne limite pas l’accès du serveur et n’empêche pas le chargement de code via l’environnement. Examinez indépendamment l’ensemble du contexte de lancement et les permissions du serveur. Consultez Exigences d’identité MCP.

Utilisez cette recette lorsque votre équipe de sécurité doit comprendre ce que fait Codex sur les terminaux et dans votre réseau. Elle rassemble les événements d’exécution et d’outils, les décisions d’approbation, les enregistrements d’audit de l’espace de travail et les journaux réseau à des fins d’investigation.

Résultat attendu

Les équipes de sécurité peuvent corréler les exécutions de Codex, les décisions relatives aux outils, les approbations, les enregistrements d’audit de l’espace de travail et le trafic réseau sortant réel sans se fier au récit du modèle.

Utilisez quatre sources de preuves

1. OpenTelemetry de Codex : événements d’exécution, d’API, de modèle, de bac à sable, d’approbation et d’outils.

2. Hooks de cycle de vie gérés : enregistrements côté terminal concernant l’utilisation des outils et les demandes de permissions.

3. Journaux de proxy ou de passerelle réseau : destinations DNS/HTTP réelles et résultats des connexions.

4. Compliance API : enregistrements d’audit et d’investigation au niveau de l’espace de travail.

Aucune source ne fournit à elle seule une surveillance réseau complète.

Configuration

1. Envoyez les journaux OpenTelemetry de Codex à votre collecteur, en masquant les prompts bruts :

   [otel]
   environment = "enterprise"
   log_user_prompt = false

   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

Fournissez OTLP_TOKEN au processus Codex via votre gestionnaire de secrets approuvé ou l’environnement du processus avant de démarrer le client. Ne placez pas le jeton dans les fichiers TOML déployés ni dans le dépôt de code source.

Codex peut émettre des débuts de conversation, des requêtes API, des événements de streaming, des métadonnées de prompts, des décisions relatives aux outils et des résultats d’outils. Consultez Configuration avancée.

2. Déployez OTel en dehors de la configuration locale du projet. Les fichiers .codex/config.toml du projet ne peuvent pas modifier le routage de la télémétrie.

3. Ajoutez des hooks de cycle de vie gérés pour SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop et SessionEnd.

4. Installez les scripts de hooks dans un répertoire géré par l’administrateur et définissez allow_managed_hooks_only = true si les hooks utilisateur, de projet et de plugins doivent être ignorés.

5. Faites passer le trafic des commandes exécutées dans le bac à sable par un proxy disposant de sa propre journalisation. OTel enregistre qu’un outil a été exécuté ; le proxy enregistre les destinations auxquelles le sous-processus a tenté de se connecter.

6. Configurez une télémétrie distincte pour la recherche web, les applications, les connecteurs, les MCP servers, l’activité du navigateur et Codex Cloud. Les règles du proxy de commandes locales ne les couvrent pas automatiquement.

7. Transmettez en continu les enregistrements pris en charge par la Compliance API au SIEM et appliquez vos propres contrôles de conservation et de gel juridique. Consultez Compliance API et événements d’audit.

8. Corrélez l’utilisateur ou le compte de service, l’hôte ou le runner, l’ID de conversation, le modèle, la version du client, le profil de permissions, la décision d’approbation, la destination et le nom de l’outil.

Vérification

Exécutez une session contrôlée qui effectue les opérations suivantes :

• Lit un fichier autorisé.

• Tente de lire un fichier bloqué.

• Exécute une commande autorisée.

• Tente une requête sortante bloquée.

• Demande une approbation et reçoit un refus.

• Termine la session.

Résultats attendus par source de preuves :

• OTel affiche les événements d’exécution et d’outils.

• Les hooks montrent le cycle de vie de la session.

• Les journaux du proxy montrent les destinations autorisées et bloquées.

• Le système d’ingestion de conformité reçoit les enregistrements pris en charge.

• Le SIEM corrèle ces enregistrements avec l’utilisateur ou la charge de travail.

Retour arrière

Désactivez l’exportateur et les hooks en rétablissant la configuration précédente. Ne supprimez pas la journalisation indépendante du proxy lors d’un retour arrière de la télémétrie.

Limites

Ne promettez pas que la télémétrie de Codex capture chaque argument de commande, chaque octet de sortie ou chaque paquet réseau. Documentez la couverture de chaque couche.

Utilisez cette recette lorsque Codex ne doit disposer d’aucun accès à Internet ou doit uniquement accéder à des destinations approuvées. Choisissez la procédure locale ou cloud correspondant à l’environnement que vous configurez, en tenant compte de leurs périmètres de politique distincts.

Résultat attendu

Codex ne dispose d’aucun accès à Internet ou accède uniquement aux domaines approuvés, selon la configuration choisie. Les environnements Codex Cloud (Legacy) peuvent également restreindre les méthodes HTTP.

Configurer la version actuelle de Codex Cloud

1. Créez des environnements distincts pour les différents niveaux de confiance, comme no-internet-review, approved-dependencies-build et cyber-lab.

2. Dans la configuration de l’environnement, laissez Allow Codex to access internet désactivé, sauf si le workflow nécessite un accès à Internet.

3. Lorsqu’un accès est nécessaire, activez Allow Codex to access internet. Sous Allow domains, choisissez Custom domains only, puis ajoutez les hôtes exacts nécessaires sous Additional allowed domains.

4. Enregistrez et testez les services pendant la configuration. Publiez ou republiez l’environnement, puis testez l’accès aux destinations approuvées et non approuvées dans une nouvelle tâche. Examinez séparément les scripts de configuration : fixez les versions des dépendances, privilégiez les miroirs approuvés et évitez les téléchargements d’exécutables qui n’ont pas été examinés.

Consultez Se connecter aux services. Les paramètres actuels de Codex Cloud ne proposent pas le sélecteur de méthodes HTTP de la version Legacy.

Configurer Codex Cloud (Legacy)

1. Laissez l’accès Internet de l’agent sur Off lorsqu’il n’est pas nécessaire. Legacy Cloud bloque Internet par défaut pendant la phase de l’agent ; les scripts de configuration s’exécutent toujours avec un accès à Internet pour installer les dépendances.

2. Lorsque l’agent a besoin d’un accès, passez-le sur On avec une liste d’autorisation limitée. Commencez par None, puis ajoutez les domaines exacts.

3. Pour les workflows limités au téléchargement, autorisez uniquement GET, HEAD et OPTIONS. Cela bloque POST, PUT, PATCH, DELETE et les autres méthodes. Examinez séparément les scripts de configuration, car la restriction de la phase de l’agent ne régit pas leur accès à Internet.

Consultez Accès Internet de l’agent Legacy. Ces préréglages et contrôles de méthodes HTTP s’appliquent uniquement à Legacy Cloud.

Configurer Codex en local

1. Dans le fichier requirements.toml géré par l’administrateur, définissez et sélectionnez le profil réseau approuvé, puis limitez les utilisateurs à ce profil :

   default_permissions = "corp-build"

   [allowed_permission_profiles]
   "corp-build" = true

   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"

   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false

   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. Déployez l’ensemble d’exigences validé en suivant Configuration gérée. Un profil nommé n’est pas actif à lui seul ; default_permissions le sélectionne et la liste d’autorisation empêche la sélection d’autres profils.

3. Activez le proxy géré par l’administrateur dans le même ensemble d’exigences pour que les restrictions de domaines soient appliquées et que les utilisateurs ne puissent pas les élargir. Déployez ensemble le proxy et le profil avec accès réseau ; un profil avec accès réseau sans proxy actif accorde un accès réseau direct sans appliquer ses règles de domaines :

   Attention : [experimental_network] est expérimental et peut changer. Validez-le sur chaque version de client local et chaque système d’exploitation pris en charge avant un déploiement plus large. La prise en charge de Windows est limitée ; n’appliquez pas cette politique aux utilisateurs Windows avant d’avoir testé son application effective dans votre environnement.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. Laissez l’écoute sur les ports locaux désactivée, sauf si le workflow en a besoin. Configurez séparément l’accès aux cibles du réseau privé ; autoriser un domaine n’approuve pas à lui seul ses adresses privées. Consultez Exigences d’accès réseau.

5. Configurez séparément la recherche web, les applications, les MCP servers, l’activité du navigateur et Codex Cloud. Les règles du bac à sable local ne les contrôlent pas.

Vérification

• Envoyez une requête à un domaine approuvé et confirmez qu’elle réussit.

• Envoyez une requête à un domaine non approuvé et confirmez qu’elle est bloquée.

• Envoyez des requêtes à localhost, à une IP privée et à un point de terminaison de métadonnées cloud. Confirmez que chaque requête est bloquée, sauf autorisation explicite.

• Dans Codex Cloud (Legacy), tentez une requête POST vers un domaine autorisé. Confirmez que la requête est bloquée lorsque seuls GET, HEAD et OPTIONS sont autorisés.

• Confirmez que les journaux du proxy ou de la passerelle contiennent des entrées pour les requêtes autorisées comme pour les requêtes refusées.

Retour arrière

Remettez l’environnement sur Off ou rétablissez la politique de domaines précédente. Évitez de revenir à un accès Internet sans restriction.

Limites

Une élévation approuvée permettant de sortir entièrement du bac à sable peut contourner le proxy de commandes locales. Testez séparément les commandes ordinaires exécutées dans le bac à sable et les commandes avec élévation approuvée avant de vous fier à la restriction.

Un domaine autorisé peut tout de même héberger des injections de prompt, des paquets compromis ou de la documentation dangereuse.

Utilisez cette recette lorsque Codex a besoin d’accéder à des répertoires source approuvés, tandis que les secrets, les fichiers .env, les clés SSH et les dépôts sans rapport avec le travail doivent rester hors de portée. Elle couvre la restriction de l’accès aux fichiers et la réduction du nombre de variables d’environnement contenant des identifiants transmises aux commandes lancées.

Résultat attendu

Codex peut travailler dans les répertoires source approuvés, mais ne peut pas lire les fichiers courants contenant des secrets ni hériter d’un large ensemble de variables d’environnement contenant des identifiants.

Configuration

1. Définissez des motifs de refus de lecture dans un profil d’espace de travail :

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"

   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6

   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. Ajoutez des chemins exacts à refuser pour les répertoires d’identifiants connus, les clés de signature, la configuration de production et les dépôts voisins.

3. Dans le fichier système /etc/codex/config.toml ou le fichier utilisateur ~/.codex/config.toml, réduisez les variables d’environnement transmises aux commandes lancées :

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false

   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

Il s’agit d’une valeur par défaut configurable par l’utilisateur, et non d’une exigence obligatoire. Elle réduit les variables héritées, mais n’empêche pas l’accès aux fichiers d’identifiants, aux utilitaires d’authentification, au contenu de démarrage du shell ou à d’autres identités. Consultez Configuration avancée.

4. Dans le fichier requirements.toml géré par l’administrateur, sélectionnez le profil restreint et n’autorisez que ce profil. Les profils intégrés n’héritent pas de ses refus d’accès aux fichiers secrets :

   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. Choisissez le mode de gestion des identifiants pour votre environnement Cloud :

   • Dans la version actuelle de Codex Cloud, utilisez Network secrets pour les identifiants envoyés à un service HTTPS autorisé. Les programmes reçoivent une valeur de substitution, et le proxy la remplace par la valeur réelle pour les destinations approuvées sur le port 443 pendant la configuration et les tâches. L’identifiant brut n’est placé ni dans un processus local ni dans un fichier local. Les variables d’environnement directes sont accessibles aux programmes. Consultez Variables d’environnement et secrets réseau.
   • Dans Codex Cloud (Legacy), les secrets permettent l’authentification pendant la configuration et sont supprimés avant la phase de l’agent ; les variables d’environnement restent disponibles pendant toute la conversation. Consultez Environnements Legacy Cloud.

6. Si l’agent doit s’authentifier, utilisez un courtier indépendant pour fournir des identifiants de courte durée limités à la cible et à l’action exactes. Consultez Configuration recommandée.

Vérification

Créez des fichiers témoins inoffensifs :

.env.test
test-key.pem
.aws/credentials
.kube/config

Demandez ensuite à Codex de :

• Lire un fichier ordinaire.

• Lire chaque fichier témoin.

• Rechercher des secrets de manière récursive.

• Afficher l’environnement de ses commandes.

• Lire un dépôt voisin.

Résultat attendu : la lecture d’un fichier ordinaire réussit ; les fichiers interdits et les dépôts voisins restent inaccessibles, et les variables exclues sont absentes de l’environnement des commandes.

Retour arrière

Rétablissez le profil précédent, mais conservez les refus d’accès aux fichiers secrets établis avec un haut degré de certitude pendant l’investigation des échecs de workflows.

Limites

Les refus d’accès au système de fichiers ne suppriment pas les secrets déjà collés dans les prompts, enregistrés dans du code source lisible, renvoyés par des connecteurs ou écrits dans des journaux accessibles au modèle.

Utilisez cette recette lorsque des actions telles que git push, les déploiements, les migrations de bases de données et les commandes CLI cloud doivent être approuvées avant leur exécution. Décidez quelles commandes doivent déclencher une demande d’examen et lesquelles doivent être interdites, puis configurez les règles correspondantes.

Résultat attendu

Les commandes sensibles attendent systématiquement une approbation ou sont interdites, même lorsque le modèle les juge appropriées.

Configuration

1. Décidez quelles commandes nécessitent une demande d’approbation et lesquelles sont interdites.

2. Ajoutez des règles de commandes imposées par l’administrateur :

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

Les règles des exigences peuvent imposer une demande d’approbation ou interdire une commande ; elles ne peuvent pas en autoriser une. Consultez Configuration gérée.

3. Pour les profils à haut risque, ajoutez une entrée pour les wrappers de shell au même tableau prefix_rules lorsque ces wrappers pourraient masquer une commande sensible :

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

L’entrée pour les wrappers de shell génère de nombreuses demandes ; utilisez-la de manière ciblée.

4. Si une personne doit approuver les commandes, imposez ces paramètres :

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

Auto-review change l’entité chargée de l’examen ; ce n’est pas une garantie de sécurité déterministe. Consultez Auto-review.

5. Envoyez les événements PermissionRequest, de décision relative aux outils et de résultat d’outil au pipeline de sécurité.

Vérification

• Exécutez git status. Résultat attendu : aucune demande d’approbation ne s’affiche.

• Exécutez git push. Résultat attendu : une demande d’approbation s’affiche.

• Exécutez terraform apply. Résultat attendu : une demande d’approbation s’affiche.

• Exécutez kubectl delete pod test. Résultat attendu : une demande d’approbation s’affiche.

• Exécutez rm -rf test-directory. Résultat attendu : la commande est interdite.

• Refusez une demande d’approbation. Résultat attendu : la commande ne s’exécute pas et le refus est journalisé.

• Redémarrez le client et répétez les vérifications. Résultat attendu : la règle reste appliquée.

Retour arrière

Rétablissez l’ensemble d’exigences précédent. Affinez un motif de jetons trop large plutôt que de supprimer toute une catégorie de commandes sensibles.

Limites

Les règles de préfixe ne constituent pas un moteur complet de politiques du système d’exploitation. Associez-les au bac à sable, à des comptes du système d’exploitation dotés du minimum de privilèges, aux restrictions réseau, à l’IAM cloud, à la protection des branches, aux approbations de déploiement et aux autorisations de bases de données.

Utilise les recettes de configuration suivantes : Restreindre les profils de permissions et Full Access ; Protéger les secrets et les dépôts sans rapport avec le travail ; Exiger une approbation pour les commandes sensibles.

Les développeurs disposent d’un accès légitime à la production, mais vous souhaitez que Codex les aide à développer sans apporter de modifications non examinées à la production.

• Définissez un profil d’espace de travail approuvé et imposez les profils et les politiques d’approbation autorisés. Distribuez ces paramètres sous forme d’exigences imposées par l’administrateur pour empêcher les utilisateurs de les modifier.

• Exécutez Codex sous une identité distincte dotée de privilèges réduits ou dans un environnement qui ne peut ni accéder à des identifiants d’écriture en production ni en obtenir. Les développeurs peuvent conserver leur accès à la production via un workflow autorisé distinct.

• Réduisez au minimum les variables d’environnement transmises aux commandes lancées. Si l’agent doit s’authentifier, utilisez un courtier indépendant pour fournir des identifiants de courte durée limités à la cible et à l’action exactes.

• Décidez quelles commandes nécessitent une demande d’approbation et lesquelles sont interdites. Exigez qu’une personne approuve certaines commandes à fort impact, comme git push, terraform apply, les modifications Kubernetes et les migrations de bases de données ; interdisez les commandes qui ne doivent jamais être exécutées.

• Maintenez l’application de l’IAM de production, de la protection des branches et des approbations de déploiement indépendamment de Codex.

Restreindre les profils de permissions et exiger un examen humain

Dans le fichier requirements.toml géré par l’administrateur, autorisez les profils intégrés d’espace de travail et de lecture seule, et exigez un examen par l’utilisateur pour les actions nécessitant une approbation :

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

Le profil d’espace de travail permet de travailler dans l’espace de travail au sein de son bac à sable ; le profil de lecture seule est disponible pour les travaux plus restreints. Les profils d’accès complet ne figurent pas dans la liste d’autorisation.

Définissez approval_policy = "on-request" dans la configuration du client si celui-ci nécessite un choix compatible explicite. on-request permet d’afficher une demande d’approbation lorsque c’est nécessaire ; il n’en affiche pas pour chaque commande. Ajoutez des règles explicites pour les actions qui nécessitent un examen et conservez des autorisations de production indépendantes.

Les listes d’autorisation de profils gérées nécessitent Codex 0.138.0 ou une version ultérieure ; pour les clients plus anciens, utilisez et testez les exigences documentées de l’ancien mode de bac à sable.

Redémarrez chaque client pilote, vérifiez que le profil approuvé fonctionne et qu’un profil d’accès complet non autorisé est refusé.

Séparer l’identité Codex des identifiants de production

Dans votre système de gestion des appareils ou de provisionnement des environnements de développement, créez un utilisateur, un conteneur ou un hôte de développement dédié à Codex, avec un accès limité au code source et aux services de développement dont il a besoin. Ne montez pas les fichiers d’identifiants de production, les utilitaires de gestion des jetons ou les trousseaux du développeur dans cet environnement, et empêchez cette identité d’obtenir des rôles d’écriture en production.

Si l’agent a besoin d’accéder à des services, configurez le courtier d’identifiants de votre organisation pour émettre des identifiants de courte durée limités à la ressource de développement et à l’action concernées. Le développeur peut utiliser son identité habituelle via un workflow de production autorisé distinct.

Par exemple, dans AWS IAM, ouvrez Roles, sélectionnez le rôle de développement Codex et, sous Permissions, ajoutez une politique intégrée ayant fait l’objet d’un examen, comme celle-ci, en remplaçant le compte et le rôle par les vôtres :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

Cet exemple refuse les tentatives d’endosser le rôle nommé, mais ne refuse pas les tentatives d’endosser d’autres rôles. Supprimez également les permissions directes en production, restreignez les autres rôles de production et sources d’identifiants, et examinez les politiques de confiance ainsi que les contrôles au niveau de l’organisation.

Testez le rôle de développement avec des autorisations représentatives de développement et de production, sans effectuer de modification en production. Consultez les exemples de stratégies de rôle AWS IAM.

Réduire l’environnement du shell au minimum

Dans /etc/codex/config.toml pour une configuration initiale à l’échelle du système, ou dans ~/.codex/config.toml pour un seul utilisateur, configurez les variables d’environnement dont héritent les commandes lancées :

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Il s’agit d’un comportement par défaut configurable, et non d’une barrière imposée pour protéger les identifiants. Les paramètres utilisateur, l’initialisation ou les instantanés du shell, les assistants d’authentification et d’autres sources d’identifiants peuvent toujours exposer des identifiants.

Dans requirements.toml, utilisez les restrictions facultatives suivantes pour désactiver les shells de connexion et les instantanés du shell si elles sont compatibles avec votre flux de travail :

allow_login_shell = false

[features]
shell_snapshot = false

Testez ces paramètres sur un périmètre pilote, car certains flux de travail dépendent de l’initialisation du shell de connexion.

Démarrez Codex avec des variables synthétiques inoffensives correspondant aux filtres, puis inspectez l’environnement d’une commande lancée ; vérifiez également qu’une demande de shell de connexion est rejetée si cette fonction est désactivée. Vérifiez séparément que l’identité d’exécution ne peut pas accéder aux véritables identifiants de production. Consultez la stratégie d’environnement du shell.

Demander une approbation pour certaines commandes à fort impact

Ajoutez des règles d’exigences pour les commandes utilisées par votre organisation. Par exemple :

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

Utilisez forbidden pour une commande qui ne doit jamais être exécutée ; remplacez ou ajoutez des motifs correspondant aux outils de déploiement et de migration réellement utilisés.

Ces règles recherchent des correspondances avec les préfixes de commande et ne couvrent pas toutes les actions équivalentes. Testez séparément les chemins absolus, les scripts intermédiaires, les autres ordres d’arguments, les autres clients et les autres outils.

Sur une cible jetable, exécutez une commande normale, demandez une action répertoriée, refusez la demande d’approbation et vérifiez que l’action n’a pas été exécutée. Consultez la section Application des règles de commande.

Imposer les approbations de dépôt et de déploiement en dehors de Codex

Dans votre plateforme de gestion de code source, protégez les branches de production telles que main : exigez des modifications relues ainsi que les approbations et les vérifications de statut nécessaires, et examinez quels rôles peuvent contourner ces exigences. Configurez l’approbation des déploiements dans le système de déploiement concerné et les privilèges de base de données dans la base de données elle-même.

Utilisez un dépôt jetable pour vérifier qu’une modification relue aboutit et qu’un push direct non autorisé est rejeté. Ces contrôles s’appliquent, que l’action ait été demandée via Codex ou non.

Vérification

Sur une cible de test jetable :

• Exécutez une tâche normale dans l’espace de travail. Résultat attendu : la tâche réussit.

• Tentez d’exécuter une commande sensible représentative et refusez la demande d’approbation. Résultat attendu : la commande refusée n’est pas exécutée.

• Vérifiez que l’identité de Codex ne peut pas obtenir d’accès en écriture à la production.

• Redémarrez le client et recommencez.

Limites

Les règles de préfixe ne constituent pas un moteur complet de stratégies de sécurité du système d’exploitation. Associez-les à l’exécution en sandbox, à des comptes du système d’exploitation dotés de privilèges minimaux, à des restrictions réseau, à la gestion IAM du cloud, à la protection des branches, aux approbations de déploiement et aux autorisations de base de données.

Utilise les recettes de configuration suivantes : Protéger les secrets et les dépôts sans rapport avec la tâche ; Restreindre les destinations réseau ; Autoriser uniquement les MCP servers approuvés ; Exiger une approbation pour les commandes sensibles.

Les développeurs utilisent Codex avec des dépôts internes, et vous souhaitez réduire le risque d’envoi de code vers un dépôt public, un extrait de code public ou une autre destination non approuvée.

• Ajoutez des chemins d’interdiction exacts pour les répertoires d’identifiants connus et les dépôts sans rapport avec la tâche, et réduisez au minimum les variables d’environnement transmises aux commandes lancées.

• Lorsque l’agent a besoin d’un accès à Internet, utilisez une liste d’autorisation restreinte de domaines approuvés. Autorisez uniquement les noms et identités de MCP servers approuvés, et exigez une validation pour certaines commandes de publication ou interdisez-les, comme git push.

• Utilisez des hooks et des autorisations de gestion de code source, des stratégies applicables aux dépôts et aux extraits de code publics, ainsi que des contrôles de prévention des pertes de données adaptés à votre organisation.

Interdire l’accès aux dépôts sans rapport avec la tâche et aux fichiers d’identifiants

Dans le fichier requirements.toml géré par l’administrateur, ajoutez les chemins exacts que l’agent local ne doit pas lire :

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

Remplacez les exemples par des chemins présents sur vos appareils gérés. Cette interdiction gérée s’applique à tous les profils d’autorisation autorisés ; une interdiction configurée uniquement dans un profil personnalisé ne protège pas les utilisateurs qui sélectionnent un autre profil. Privilégiez les chemins exacts connus et testez les motifs glob aux profondeurs nécessaires.

Sous Windows natif, le paramètre géré deny_read couvre les outils d’accès direct aux fichiers, mais n’empêche pas à lui seul les lectures par des sous-processus du shell ; utilisez également les identités du système d’exploitation et les listes de contrôle d’accès aux fichiers.

Créez des fichiers témoins inoffensifs aux emplacements interdits. Avec chaque profil autorisé, vérifiez que les lectures directes et les lectures via le shell de ces fichiers sont refusées et qu’un fichier source approuvé peut être lu. Consultez les exigences gérées d’interdiction de lecture.

Réduire au minimum les variables du shell contenant des identifiants

Dans /etc/codex/config.toml ou ~/.codex/config.toml, définissez un environnement hérité restreint :

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Ce paramètre réduit le nombre de variables héritées, mais reste configurable par l’utilisateur et n’empêche pas l’accès aux fichiers d’identifiants, aux assistants d’authentification, au contenu d’initialisation du shell ou à d’autres identités.

Si cela convient, un administrateur peut également ajouter ces restrictions à requirements.toml et les tester sur un périmètre pilote pour évaluer leur effet sur les flux de travail des développeurs :

allow_login_shell = false

[features]
shell_snapshot = false

Effectuez les tests avec des variables témoins synthétiques et une identité d’exécution distincte dotée de privilèges minimaux. N’utilisez pas de véritables identifiants. Consultez la stratégie d’environnement du shell.

Autoriser uniquement les destinations réseau approuvées pour les commandes locales

Si les commandes locales exécutées en sandbox ont besoin d’un accès réseau, intégrez à la fois les paramètres de profil et de proxy géré ci-dessous dans requirements.toml, en remplaçant les domaines par des points de terminaison approuvés :

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

Le profil avec accès réseau fournit un accès au réseau à la commande exécutée en sandbox, tandis que le proxy géré restreint ses destinations. Déployez-les ensemble ; un profil avec accès réseau sans le proxy géré prévu n’applique pas les mêmes restrictions de destination. Si l’accès à Internet est inutile, laissez l’accès réseau désactivé.

Ne combinez pas la table canonique domains avec les anciens paramètres allowed_domains ou denied_domains ; migrez et testez la stratégie existante.

Redémarrez le client et vérifiez qu’un point de terminaison approuvé fonctionne et qu’un point de terminaison non approuvé est bloqué.

Ces paramètres sont expérimentaux ; vérifiez leur prise en charge par le système d’exploitation et le client, et configurez séparément l’accès au réseau privé si un hôte approuvé est résolu en adresse privée. Une élévation complète approuvée hors de la sandbox peut contourner le proxy de commandes.

Ce contrôle réseau des commandes locales ne couvre pas à lui seul la recherche web, les applications, les MCP servers, l’activité du navigateur ou les environnements cloud, qui nécessitent des stratégies distinctes. Un domaine d’hébergement approuvé peut également contenir des dépôts ou des extraits de code publics ; une liste d’autorisation de destinations ne suffit donc pas à protéger le contenu. Consultez les exigences d’accès réseau.

Configurer séparément le réseau de l’environnement cloud

Dans l’interface actuelle de Codex Cloud, ouvrez la configuration de l’environnement. Laissez Autoriser Codex à accéder à Internet désactivé. Si vous avez besoin d’un accès à Internet, activez cette option et choisissez Domaines personnalisés uniquement, ajoutez les hôtes exacts nécessaires sous Domaines autorisés supplémentaires, puis enregistrez la configuration, publiez ou republiez l’environnement et testez une nouvelle tâche.

Examinez séparément l’authentification et les capacités des services.

L’ancienne version de Codex Cloud utilise un paramètre d’accès de l’agent à Internet propre à chaque environnement, avec des contrôles sur les domaines autorisés et les méthodes HTTP ; les scripts de configuration ont leur propre comportement d’accès.

Testez la version de l’environnement que vous utilisez réellement. Consultez les sections Connexion aux services et anciens paramètres Internet.

Restreindre les MCP servers et demander une approbation avant les push Git

Autorisez uniquement les identités de MCP servers locaux approuvées dans requirements.toml. Par exemple :

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

Configurez séparément le serveur réel dans le fichier config.toml de l’utilisateur ou des valeurs par défaut gérées, avec le nom et l’URL correspondants ainsi que l’authentification requise par votre serveur :

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

L’exigence autorise uniquement un serveur correspondant et ne le crée pas. Examinez les accès et les outils propres à ce serveur.

Vérifiez que le serveur approuvé peut se connecter et qu’un serveur portant un nom ou une URL différents n’est pas autorisé.

Ajoutez une règle de commande gérée pour demander une validation avant une commande de publication représentative :

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

Associez-la à allowed_approval_policies = ["on-request"] et à allowed_approvals_reviewers = ["user"] comme exigences de premier niveau si une personne doit effectuer la validation.

Refusez un push de test et confirmez qu’il n’est pas exécuté.

La correspondance de préfixe ne couvre pas tous les scripts intermédiaires, clients API, applications ou autres voies de publication.

Restreindre la publication publique à l’aide des contrôles de gestion de code source et de DLP

Dans votre plateforme de gestion de code source, restreignez la création de dépôts publics et limitez les personnes pouvant modifier la visibilité des dépôts, lorsque ces fonctions sont disponibles. Examinez les autorisations de contournement des utilisateurs privilégiés. Vérifiez séparément les comptes personnels, les extraits de code, les organisations externes et les accès par jeton : les paramètres de l’organisation ne régissent pas toutes les destinations.

Dans le dépôt concerné, exigez des modifications relues et examinez la protection des branches ainsi que les autorisations de contournement.

Dans la console DLP de votre organisation, configurez une stratégie pilote pour le contenu sensible du code source et les canaux de téléversement ou de dépôt que votre produit DLP couvre réellement ; définissez l’action sur le blocage et testez avec un marqueur synthétique inerte.

Lorsque la plateforme de gestion de code source prend en charge les contrôles côté serveur, configurez et imposez des hooks relus pour les dépôts recevant des push.

Utilisez des destinations de test autorisées et confirmez le blocage avant toute publication.

Vérification

• Créez des fichiers témoins inoffensifs et confirmez que les tentatives de lecture des fichiers interdits échouent.

• Si l’accès réseau est activé, vérifiez qu’une destination approuvée est accessible et qu’une destination non approuvée est bloquée ; sinon, vérifiez que les requêtes réseau sont bloquées.

• Avec un marqueur inoffensif et des comptes ou destinations de test jetables, vérifiez que des tentatives représentatives de publication publique sont bloquées avant la publication.

Limites

Un domaine autorisé peut tout de même héberger du contenu public. Configurez séparément la recherche web, les applications, les MCP servers, l’activité du navigateur et Codex Cloud ; les règles de la sandbox locale ne les contrôlent pas.

Utilise les recettes de configuration suivantes : Restreindre les profils d’autorisation et l’accès complet ; Autoriser uniquement les MCP servers approuvés ; Restreindre les destinations réseau ; Protéger les secrets et les dépôts sans rapport avec la tâche ; Exiger une approbation pour les commandes sensibles.

Vous souhaitez que les restrictions encadrant Codex restent en vigueur lorsqu’il travaille dans un dépôt ou qu’un utilisateur modifie les configurations locales.

• Déployez les restrictions prises en charge concernant les autorisations, les approbations, MCP, le réseau et les commandes sous forme d’exigences imposées par l’administrateur.

• Installez les scripts de hooks dans un répertoire géré par l’administrateur et utilisez uniquement les hooks gérés si les hooks d’utilisateur, de projet et de plugin doivent être ignorés.

• Protégez les fichiers de stratégie et le circuit de distribution de la configuration à l’aide des contrôles du système d’exploitation et de gestion des appareils. Exécutez Codex sans les privilèges nécessaires pour modifier ces protections.

• Examinez la configuration effective de chaque client et environnement concerné.

Imposer les profils, approbations, identités de serveurs et commandes autorisés

Intégrez les paramètres relus au fichier requirements.toml géré par l’administrateur, au lieu de vous appuyer sur les paramètres modifiables d’un utilisateur ou d’un dépôt. Par exemple :

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

Cet exemple autorise deux profils, exige un réviseur humain lorsqu’une approbation est nécessaire, autorise une identité MCP correspondante et demande une approbation pour un préfixe de commande particulier.

Configurez séparément le MCP server lui-même et ajoutez les autres motifs de commandes sensibles de l’organisation. Ajoutez des restrictions globales sur les fichiers et des restrictions réseau au besoin ; les exigences encadrent les paramètres pris en charge, mais ne remplacent pas les contrôles d’identité, de service et de destination extérieurs à Codex.

Les listes de profils autorisés gérées nécessitent Codex 0.138.0 ou une version ultérieure.

Sur un client pilote, tentez de sélectionner un profil non autorisé, de modifier un paramètre utilisateur ou de projet soumis à restriction et d’utiliser une identité MCP absente de la liste d’autorisation ; vérifiez que chaque tentative est rejetée ou reste soumise aux restrictions après le redémarrage. Refusez l’approbation d’une commande de test et vérifiez que la commande n’est pas exécutée.

Ajouter des restrictions gérées sur le système de fichiers et le réseau

Pour interdire l’accès aux fichiers locaux sensibles dans tous les profils autorisés, ajoutez la table suivante à requirements.toml et remplacez les exemples par les chemins de votre organisation :

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

Lorsque les commandes locales exécutées en sandbox ont besoin d’un accès réseau, définissez ensemble un profil autorisé avec accès réseau et des destinations gérées :

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

Choisissez cette stratégie de profil à la place de la valeur par défaut :workspace précédente, ou fusionnez délibérément les deux noms de profil ; ne collez pas de clés ou de tables en double. Si les commandes n’ont pas besoin du réseau, laissez-le désactivé.

Vérifiez les chemins exacts interdits à l’aide de fichiers inoffensifs, ainsi que les destinations approuvées et non approuvées.

Sous Windows natif, utilisez également des listes de contrôle d’accès aux fichiers, car les lectures par des sous-processus du shell ne sont pas couvertes par le seul paramètre géré deny_read.

La gestion du réseau des commandes locales ne régit pas les autres clients, applications, connecteurs ou exécutions cloud.

Installer et imposer des hooks gérés par l’administrateur

Demandez à un administrateur d’installer un programme de hook relu dans un répertoire géré par root, tel que /etc/codex/hooks/pre_tool_use_policy.py, et d’empêcher l’utilisateur exécutant Codex de modifier le fichier ou son répertoire. Dans requirements.toml, activez les hooks et ignorez ceux de l’utilisateur, du projet, de la session et des plugins :

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

L’exigence enregistre le hook, mais ne l’installe pas. Pour un test d’intégration local sous macOS, enregistrez ce qui suit sous pre_tool_use_policy.py et demandez à un administrateur de l’installer avec les commandes ci-dessous.

Il bloque uniquement le marqueur synthétique ; remplacez-le par une stratégie propre à votre organisation et relue avant de vous y fier. Confirmez que /usr/bin/python3 existe sur la cible et adaptez le chemin de l’interpréteur si nécessaire :

import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

Redémarrez le client local, puis :

• Confirmez qu’une commande Bash bénigne s’exécute.

• Confirmez qu’une commande contenant CODEX_HOOK_TEST_DENY est bloquée.

• Vérifiez que l’utilisateur exécutant Codex ne peut pas modifier la stratégie ni ses dépendances.

allow_managed_hooks_only ignore tous les hooks non gérés d’utilisateur, de projet, de session et de plugin, et peut affecter d’autres flux de travail.

Le mécanisme de correspondance Bash ne couvre pas tous les outils ni les entrées fournies ultérieurement à un processus existant ; des erreurs, des délais d’attente dépassés ou des réponses de hook mal formées peuvent laisser un appel d’outil se poursuivre.

Work orchestré dans le cloud utilise d’autres gestionnaires de hooks pris en charge. Conservez des protections indépendantes au niveau du système d’exploitation et des services. Consultez les sections Hooks gérés et comportement des hooks.

Protéger la stratégie et sa distribution

Sous macOS, un administrateur peut déployer un fichier d’exigences relu et fusionné dans un répertoire parent appartenant à root et empêcher l’utilisateur exécutant Codex d’écrire dans le fichier :

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

Sous Linux, utilisez le groupe d’administrateurs approprié ; sous Windows, protégez le répertoire ProgramData et le fichier à l’aide de listes de contrôle d’accès gérées par l’administrateur. Limitez les personnes pouvant modifier la stratégie MDM ou cloud, faites relire les modifications et conservez une copie permettant un retour en arrière.

Avec un compte pilote non administrateur, vérifiez que ce compte ne peut modifier ni la stratégie, ni le répertoire parent, ni le programme de hook géré ; essayez un paramètre utilisateur ou de projet moins restrictif, redémarrez Codex et vérifiez que le comportement imposé persiste.

Testez chaque client et environnement concerné au lieu de supposer que tous les clients chargent la même stratégie.

Vérification

Avec une identité de test non administrateur :

• Tentez de modifier la stratégie gérée. Résultat attendu : le fichier géré ne peut pas être modifié.

• Tentez d’assouplir une restriction via la configuration utilisateur ou de projet. Résultat attendu : les paramètres moins restrictifs sont rejetés ou restent soumis aux restrictions.

• Redémarrez le client et vérifiez que les restrictions s’appliquent toujours.

Limites

Un utilisateur ou un agent disposant de privilèges d’administration suffisants sur l’hôte peut être en mesure de modifier les protections environnantes. Les paramètres modifiables par l’utilisateur ne remplacent pas à eux seuls les exigences gérées par l’administrateur.