Configuration gérée

La configuration gérée permet aux administrateurs d’entreprise de définir des exigences et des valeurs par défaut pour ChatGPT Work et Codex. Les exigences limitent les actions des utilisateurs et des tâches. Les valeurs par défaut déterminent la configuration initiale. Les paramètres pris en charge dépendent du produit, de la version du client et de l’environnement d’exécution.

Pour les paramètres gérés dans le cloud, ouvrez Sécurité des agents dans la console d’administration. Utilisez les commandes de l’interface pour les opérations courantes ou sélectionnez Modifier au format TOML pour consulter, copier ou modifier le texte de la configuration. Les deux vues permettent de modifier la même politique. La vue TOML donne aussi accès aux champs pris en charge qui n’ont pas de commande dédiée. Vous pouvez utiliser les paramètres gérés dans le cloud sans distribuer de fichier local. Les restrictions d’authentification et les déploiements gérés sur les appareils nécessitent une configuration locale distincte.

Pour contrôler le comportement des clients locaux compatibles, les administrateurs d’entreprise disposent des mécanismes suivants :

• Exigences : contraintes imposées par l’administrateur auxquelles les utilisateurs ne peuvent pas déroger.

• Valeurs de configuration par défaut : paramètres de config.toml gérés au niveau du système ou dans le cloud que les utilisateurs peuvent modifier.

• Anciennes valeurs par défaut gérées : valeurs initiales de managed_config.toml appliquées au lancement d’un client compatible. Les utilisateurs peuvent modifier les paramètres en cours d’exécution. Le client réapplique ces valeurs par défaut au démarrage suivant.

Consultez Sécurité des agents pour connaître la configuration de référence de la portée Global, les dérogations par environnement et la liste des champs de l’orchestrateur et de l’exécuteur.

Si vos utilisateurs se connectent à Codex sans passer par ChatGPT, vous pouvez distribuer des valeurs par défaut et des exigences à Codex CLI et à l’application de bureau depuis un point de terminaison HTTPS que vous exploitez. Consultez Héberger la configuration Codex de votre équipe.

Configurer une politique dans Sécurité des agents

Lorsque la rubrique Sécurité des agents est activée, les propriétaires et les administrateurs de l’espace de travail, ainsi que les membres disposant des autorisations d’administration de Codex, peuvent gérer les politiques. L’accès à l’éditeur de politiques ne donne pas aux membres accès aux fonctionnalités régies par ces politiques.

Utilisez Politique par défaut de l’espace de travail pour définir la configuration de référence de l’espace de travail. Utilisez Dérogations si certains utilisateurs, groupes ou rôles ont besoin de paramètres différents. Une dérogation ciblée détermine qui reçoit la politique. Un paramètre d’environnement détermine où s’appliquent les contrôles d’exécution pris en charge.

1. Ouvrez Console d’administration > Sécurité des agents, puis sélectionnez Politique par défaut de l’espace de travail ou la politique à modifier sous Dérogations.
2. Ouvrez Exigences pour imposer des limites ou Valeurs par défaut pour définir les valeurs initiales que les membres pourront modifier dans ces limites.
3. Conservez les paramètres qui concernent l’agent dans son ensemble, notamment les approbations et la recherche web, dans Global. Si l’option est disponible, sélectionnez Ajouter des paramètres d’environnement dans la fiche concernée pour ajouter Environnements locaux ou Environnements Codex Cloud et y configurer les paramètres d’exécution pris en charge. Un document d’environnement vide hérite des paramètres de Global sans copier ni figer la configuration de référence actuelle.
4. Utilisez les commandes décrites dans ce guide. Pour les champs avancés, sélectionnez Modifier au format TOML, puis modifiez le fichier requirements.toml ou config.toml de la portée concernée. Sélectionnez Utiliser les commandes de configuration pour revenir à l’éditeur visuel.
5. Consultez les messages de validation, puis sélectionnez Enregistrer les modifications. Appliquer une règle dans l’éditeur de règles met à jour le brouillon. Vous devez ensuite enregistrer la politique.
6. Vérifiez la sélection des politiques et le comportement des clients compatibles comme indiqué dans Vérifier le résultat pour les administrateurs et les employés.

Les éditeurs d’environnement disponibles et les champs pris en charge dépendent de l’espace de travail et de la politique. Consultez Où s’appliquent les paramètres avant de déplacer un paramètre de Global vers un environnement. Un paramètre de Global ne s’applique pas nécessairement à tous les produits ni à tous les modes d’exécution.

Copier ou réutiliser une configuration

L’éditeur visuel ne remplace pas TOML. Sélectionnez Modifier au format TOML pour copier une configuration, conserver une copie de référence ou réutiliser des paramètres dans une autre politique. Sélectionnez Utiliser les commandes de configuration pour revenir à l’éditeur visuel.

1. Ouvrez la politique source et sélectionnez Modifier au format TOML.
2. Choisissez la portée à copier : Global ou l’un des onglets d’environnement disponibles. Selon les paramètres à réutiliser, copiez le texte des Exigences (requirements.toml), des Valeurs par défaut (config.toml) ou des deux.
3. Ouvrez la politique de destination, sélectionnez Modifier au format TOML et choisissez la portée correspondante. Collez les exigences dans requirements.toml et les valeurs par défaut dans config.toml. Avant de remplacer le texte, examinez les paramètres existants de la politique de destination et conservez les autres paramètres qui doivent continuer à s’appliquer.
4. Vérifiez les messages de validation, les destinataires et la priorité de la politique de destination, puis sélectionnez Enregistrer les modifications. Vérifiez le comportement du client avant de vous appuyer sur la politique copiée.

Le texte copié contient les paramètres définis dans cette politique pour la portée choisie. Il n’inclut ni les affectations, ni l’ordre des politiques, ni les documents des autres environnements, ni la configuration effective résultant des autres politiques et des paramètres de l’appareil. Si nécessaire, copiez les paramètres d’environnement séparément. Changer de vue ou copier du texte n’enregistre aucune modification de la politique.

Essayez l’exemple ci-dessous : modifiez un paramètre, puis sélectionnez Modifier au format TOML pour voir sa configuration. Sélectionnez Utiliser les commandes de configuration pour revenir à la vue précédente et poursuivre vos essais.

Choisir le paramètre adapté

Contrôler le navigateur et l’utilisation de l’ordinateur

Dans la console d’administration, utilisez Sécurité des agents pour gérer l’accès au navigateur et aux applications natives sur les clients de bureau compatibles. Commencez par les commandes de l’interface. Les exemples TOML ci-dessous servent de référence pour les politiques distribuées sous forme de fichiers et pour les paramètres qui nécessitent l’éditeur TOML.

La fonctionnalité Navigateur contrôle les actions de l’agent dans un navigateur. La fonctionnalité Utilisation de l’ordinateur contrôle ses actions dans les applications de bureau natives. Le volet du navigateur intégré possède ses propres paramètres, distincts de ceux de la fonctionnalité Navigateur. Consultez Sessions de navigateur et connexions existantes pour comparer les différents modes d’accès au navigateur.

Avant de commencer

Utilisez un compte autorisé à gérer les politiques de sécurité des agents. Vérifiez qui reçoit la politique et quelles versions des clients et quels systèmes d’exploitation vous devez prendre en charge. Consultez Sécurité des agents pour connaître les affectations des politiques, les paramètres de Global et les dérogations par environnement prises en charge.

Utilisez Exigences pour imposer des limites auxquelles les utilisateurs ne peuvent pas déroger. Les Valeurs par défaut définissent les valeurs initiales dans ces limites. Autoriser un site ou une application n’installe aucun plugin, n’accorde aucune autorisation du système d’exploitation, ne connecte pas l’utilisateur et n’approuve pas les actions qui nécessitent encore une vérification.

Sous Disponibilité des fonctionnalités de bureau, vérifiez Navigateur, Utilisation d’un navigateur externe et Utilisation de l’ordinateur. Forcer la désactivation désactive la fonctionnalité correspondante. Une règle autorisant un site ou une application ne l’emporte pas sur ce réglage. Vérifiez séparément Accès CDP complet. Bloquer l’activation par l’utilisateur empêche les utilisateurs d’activer cet accès.

Ces commandes de bureau ne configurent pas le navigateur hébergé de Work Cloud. Gérez séparément Utilisation du navigateur cloud et Accès réseau cloud sous Console d’administration > Autorisations et rôles > Fonctionnalités de l’espace de travail > Fonctionnalités de l’ordinateur cloud. Consultez Comment la sécurité des agents s’applique à Work Cloud.

Configurer l’accès au navigateur

1. Ouvrez Console d’administration > Sécurité des agents. Utilisez Politique par défaut de l’espace de travail pour la configuration de référence, ou ouvrez la politique concernée sous Dérogations. Dans Exigences, accédez à Contrôles du navigateur de bureau.
2. Dans Règles de site, ouvrez le menu d’actions de la ligne Par défaut et choisissez Modifier la règle par défaut. Pour limiter l’accès aux sites approuvés, réglez Accès au site sur Bloquer, puis choisissez Appliquer la règle. La ligne Par défaut fournit les valeurs des paramètres laissés sur Utiliser la règle par défaut dans une règle de site correspondante.
3. Choisissez Ajouter une règle de site. Dans Site ou motif, saisissez une origine composée d’un schéma, d’un nom d’hôte et, éventuellement, d’un port. Par exemple, https://example.com est valide, mais https://example.com/files ne l’est pas. N’incluez ni chemin, ni chaîne de requête, ni fragment. HTTP et HTTPS correspondent à des origines différentes. Précisez le port s’il diffère du port par défaut du schéma.
4. Configurez Accès au site, puis vérifiez Téléchargements, Envois de fichiers et Débogage/CDP. Choisissez Autoriser ou Bloquer selon vos besoins, ou laissez le paramètre sur Utiliser la règle par défaut. Débogage/CDP contrôle l’accès complet au protocole Chrome DevTools pour le débogage du navigateur. Autoriser maintient les vérifications habituelles de politique et d’approbation.
5. Vérifiez Révision automatique, Toujours autoriser et Durée de l’approbation pour le site. Durée de l’approbation propose Ce tour et Ce fil. Vérifiez également Historique du navigateur, Enregistrer les approbations de site et Approuver automatiquement les demandes dans Contrôles du navigateur de bureau.
6. Choisissez Ajouter la règle, consultez les messages de validation et sélectionnez Enregistrer les modifications. Testez un site autorisé et un site bloqué sur un client compatible qui reçoit la politique. Testez séparément les envois de fichiers, les téléchargements et les autres actions soumises à restriction.

Ajouter une règle de site

La ligne Par défaut s’applique lorsqu’une règle de site laisse une autorisation sur Utiliser la règle par défaut. Si plusieurs règles se chevauchent, Bloquer l’emporte pour chaque autorisation concernée.

Site ou motif 

Accès au siteUtiliser la règle par défaut

TéléchargementsUtiliser la règle par défaut

Envois de fichiersUtiliser la règle par défaut

Débogage/CDPUtiliser la règle par défaut

Révision automatiqueUtiliser la règle par défaut

Toujours autoriserUtiliser la règle par défaut

Durée de l’approbationUtiliser la règle par défaut

Si vous désactivez la fonctionnalité Révision automatique pour les actions du navigateur, ces actions sont soumises à l’utilisateur pour approbation. La surveillance de la sécurité du modèle reste active.

Lorsque plusieurs motifs d’origine correspondent, la valeur la plus restrictive l’emporte pour chaque paramètre. La configuration locale ne peut pas assouplir une interdiction gérée. Les interdictions réseau gérées et les listes exclusives de destinations autorisées s’appliquent également aux outils de navigation. Consultez les champs de politique du navigateur pour connaître les motifs d’origine et le fonctionnement des approbations.

La fonctionnalité Utilisation de l’ordinateur peut aussi piloter un navigateur comme une application native. Les règles de site et de fonctionnalités du Navigateur ne s’appliquent pas à ce mode d’accès. Vérifiez séparément l’accès aux applications natives. Consultez les limites des contrôles de sécurité du navigateur.

Configurer l’accès aux applications natives

1. Dans Exigences, accédez à Contrôles des applications de bureau > Règles d’application.
2. Utilisez le menu d’actions de la ligne Par défaut pour configurer l’accès aux applications qui ne correspondent à aucune règle. Pour limiter l’utilisation de l’ordinateur aux applications approuvées, bloquez l’accès par défaut et ajoutez des règles autorisant ces applications.
3. Choisissez Ajouter une règle d’application. Dans la boîte de dialogue Modifier la règle, sélectionnez Identifiant de bundle macOS, AUMID Windows ou Exécutable Windows dans App. Saisissez l’identifiant de l’application exact pour un identifiant de bundle ou un Application User Model ID (AUMID). Pour un exécutable Windows, saisissez le nom de l’éditeur et le nom du produit. Le nom du binaire est facultatif. Utilisez des informations vérifiées sur l’identité de l’application. Un nom d’affichage ou un chemin de fichier ne convient pas.
4. Définissez l’accès à l’application dans la règle, puis choisissez Ajouter la règle. Vérifiez Enregistrer les approbations d’application sous Contrôles des applications de bureau, consultez les messages de validation et sélectionnez Enregistrer les modifications. Si vous désactivez l’enregistrement des approbations, les approbations restent possibles pour la session en cours. Autoriser leur enregistrement n’approuve aucune application.
5. Testez une application autorisée et une application bloquée sur chaque système d’exploitation pris en charge dans votre déploiement. Vérifiez que les autorisations du système d’exploitation s’appliquent toujours et que les utilisateurs doivent fournir les approbations requises.

Modifier la règle

Définissez l’accès par défaut aux applications et ajustez-le pour celles qui correspondent à une règle.

AppIdentifiant de bundle macOS

Identifiant de l’application 

Accès à l’applicationChoisir le type d’accès

Consultez les champs de politique d’utilisation de l’ordinateur pour les exigences d’identification sur Windows et les restrictions d’utilisation lorsque le Mac est verrouillé pour les Mac gérés.

Vérifier la politique effective

Si un site ou une application reste bloqué malgré une règle d’autorisation, vérifiez les autres règles correspondantes, les affectations et la priorité des politiques, les exigences de l’appareil et la configuration utilisateur. Une autorisation provenant d’une source ne permet pas de contourner une interdiction applicable provenant d’une autre source. Consultez Emplacements et ordre de priorité des exigences.

Si un paramètre reste sans effet, vérifiez que le client, le système d’exploitation et le mode de distribution de la politique le prennent en charge. Soyez particulièrement attentif à Work Cloud avec accès à l’ordinateur local : certains champs ne sont que partiellement pris en charge ou doivent être validés. Consultez la compatibilité avec Work dans la référence de configuration.

Vérifiez séparément les autorisations de l’espace de travail et les contrôles des plugins lorsqu’un utilisateur ne peut pas accéder à la fonctionnalité ou au plugin requis.

Référence de configuration TOML

Les exemples suivants mettent en œuvre les mêmes règles dans requirements.toml. Utilisez-les si vous gérez la politique à l’aide de fichiers ou de l’éditeur TOML. Vous pouvez utiliser les commandes de Sécurité des agents sans modifier de fichier local.

Cet exemple de configuration du navigateur refuse l’accès par défaut, autorise https://example.com, y bloque les envois de fichiers et l’accès CDP complet, et limite l’approbation de l’accès au site au tour en cours :

[browser_use]
allow_history_access = false
allow_global_persistent_approval = false

[browser_use.default_origin_policy]
access = "deny"

[browser_use.origins."https://example.com"]
access = "allow"
uploads = "deny"
downloads = "allow"
full_cdp_access = "deny"
persistent_approval = false
access_approval_lifetime = "turn"

Pour désactiver la fonctionnalité Révision automatique pour les actions du navigateur, définissez browser_use.disable_auto_review = true. Pour la désactiver pour une origine donnée, définissez auto_review = "deny" dans la politique de cette origine.

Pour les offres gérées éligibles, laissez browser_use.allow_webmcp non défini ou réglez-le sur true pour que la politique de l’espace de travail autorise les outils de site dans le navigateur intégré de l’application de bureau. Réglez-le sur false pour désactiver l’accès accordé par cette politique. Les utilisateurs qui disposent déjà de cet accès grâce au déploiement de la fonctionnalité sur leur compte peuvent continuer à utiliser les outils de site. Leur utilisation dépend également de la prise en charge par le modèle, des paramètres du navigateur et des autorisations du site.

Cet exemple autorise la Calculette sur macOS, refuse par défaut l’accès aux autres applications et empêche la conservation des approbations d’application d’une session à l’autre :

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Les politiques Windows peuvent identifier les applications empaquetées avec computer_use.windows.aumids ou les exécutables avec computer_use.windows.exes. Les règles relatives aux exécutables exigent publisher_name, product_name et access. Le champ binary_name est facultatif.

Consultez la référence de requirements.toml pour connaître tous les champs et toutes les valeurs pris en charge. Pour désactiver une fonctionnalité entière plutôt que de restreindre certains sites ou certaines applications, consultez Imposer la valeur des indicateurs de fonctionnalité.

Autres contrôles de bureau

Les contrôles suivants concernent la disponibilité des fonctionnalités de bureau, l’utilisation lorsque l’ordinateur est verrouillé, les Appshots et le contrôle à distance de l’appareil. Utilisez les paramètres dédiés pour la disponibilité des fonctionnalités et l’utilisation en mode verrouillé. Configurez les Appshots et le contrôle à distance de l’appareil avec Modifier au format TOML. Pour restreindre les destinations du trafic de l’application de bureau, consultez Contrôler les destinations réseau de l’application de bureau.

Imposer la valeur des indicateurs de fonctionnalité

Pour les fonctionnalités de bureau proposées dans Sécurité des agents, ouvrez Global > Exigences > Disponibilité des fonctionnalités de bureau. Réglez Navigateur intégré, Navigateur, Utilisation d’un navigateur externe ou Utilisation de l’ordinateur sur Forcer la désactivation pour désactiver la fonctionnalité concernée, puis sélectionnez Enregistrer les modifications. Pour Accès CDP complet, choisissez Bloquer l’activation par l’utilisateur afin d’empêcher les utilisateurs de l’activer. Même autorisée, une fonctionnalité reste soumise aux conditions de disponibilité du produit, de la plateforme et du déploiement.

Pour les autres indicateurs de fonctionnalité pris en charge, utilisez Modifier au format TOML et le document requirements.toml de Global, ou une source d’exigences locales compatible. Les exemples suivants imposent des valeurs pour des fonctionnalités du moteur d’exécution et pour des fonctionnalités propres aux applications de bureau :

[features]
hooks = true
unified_exec = false

# Disable surface-specific features when needed.
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false

Pour les fonctionnalités du moteur d’exécution, utilisez les clés canoniques de config.toml figurant dans la table [features]. Le moteur d’exécution local ajuste les fonctionnalités reconnues aux valeurs imposées et rejette toute écriture incompatible dans les paramètres de fonctionnalité de config.toml ou d’un fichier de profil.

Le paramètre géré unified_exec = false maintient l’exécution des commandes, mais désactive les processus qui peuvent reprendre après une interruption ainsi que l’outil write_stdin. La configuration utilisateur ne peut pas désactiver cette fonctionnalité.

• in_app_browser = false désactive le volet du navigateur intégré.
• in_app_updates = false désactive, au redémarrage, le mécanisme de mise à jour de l’application de bureau ChatGPT sur les plateformes compatibles. Ce réglage n’affecte pas le déploiement externe de paquets et ne prolonge pas la prise en charge des anciennes versions de l’application. Pour la configuration et le déploiement, consultez Gérer les mises à jour de l’application.
• browser_use = false désactive les capacités prises en charge de la fonctionnalité Navigateur. L’utilisation d’un navigateur externe et l’utilisation de l’ordinateur dans les applications natives disposent de contrôles distincts.
• browser_use_full_cdp_access = false désactive l’accès CDP complet dans le moteur d’exécution local, y compris le mode développeur du navigateur, et empêche l’application de bureau ChatGPT d’activer le paramètre correspondant.
• browser_use_external = false empêche l’agent de piloter le navigateur via les extensions de navigateur prises en charge.
• computer_use = false désactive l’utilisation de l’ordinateur dans les applications natives, y compris le pilotage d’un navigateur en tant qu’application native. Ce réglage désactive aussi l’enregistrement et la relecture des actions, ainsi que les procédures d’installation ou de configuration associées.

Désactiver uniquement la fonctionnalité Navigateur ne bloque pas tous les modes d’accès au navigateur. La fonctionnalité Utilisation de l’ordinateur peut toujours piloter un navigateur comme une application native si la fonctionnalité et l’accès à l’application sont autorisés. Les règles de site et de fonctionnalités du Navigateur ne s’appliquent pas à ce mode d’accès. Pour le bloquer, réglez Utilisation de l’ordinateur sur Forcer la désactivation (computer_use = false) ou bloquez l’application de navigation dans les règles d’application si les autres applications natives doivent rester disponibles. Vérifiez séparément Utilisation d’un navigateur externe et Navigateur intégré. Consultez Sessions de navigateur et connexions existantes pour connaître les contrôles applicables à chaque mode d’accès.

Si vous omettez ces clés, la politique autorise les fonctionnalités, sous réserve des conditions habituelles de disponibilité du client, de la plateforme et du déploiement.

Restreindre l’utilisation de l’ordinateur lorsqu’il est verrouillé

Pour empêcher les utilisateurs d’activer l’utilisation en mode verrouillé sur un Mac géré, ouvrez Global > Exigences > Contrôles des applications de bureau, réglez Autoriser l’utilisation en mode verrouillé sur Désactivé, puis sélectionnez Enregistrer les modifications. Ce paramètre ne désactive pas l’utilisation en mode verrouillé sur un Mac où elle est déjà activée.

Dans l’éditeur TOML ou pour une distribution gérée sur les appareils, l’exigence équivalente est la suivante :

[computer_use]
allow_locked_computer_use = false

Cette exigence supprime les commandes permettant d’activer l’utilisation en mode verrouillé. Elle ne la désactive pas si elle est déjà activée. Si vous omettez cette exigence, les conditions habituelles de disponibilité du produit et le réglage local de l’utilisateur continuent de s’appliquer.

Désactiver les Appshots

Les Appshots permettent aux clients compatibles d’inclure des instantanés d’applications. Pour les désactiver pour les utilisateurs gérés dans le cloud, sélectionnez Modifier au format TOML dans Sécurité des agents et définissez le champ de premier niveau allow_appshots dans le document requirements.toml de Global. Pour les déploiements gérés sur les appareils, utilisez la source d’exigences locales applicable :

allow_appshots = false

Lorsque les Appshots sont disponibles, allow_appshots = false les désactive. Si vous omettez la clé, les exigences n’imposent aucune restriction aux Appshots et les vérifications habituelles de disponibilité du produit s’appliquent. Les clients d’App Server qui lisent les exigences effectives via configRequirements/read reçoivent la même restriction sous le nom allowAppshots. Une valeur absente ou null pour allowAppshots ne désactive pas les Appshots.

Désactiver le contrôle à distance de l’appareil

Pour désactiver le contrôle à distance de l’appareil pour les utilisateurs gérés dans le cloud, sélectionnez Modifier au format TOML dans Sécurité des agents et définissez le champ de premier niveau allow_remote_control dans le document requirements.toml de Global. Vous pouvez également définir allow_remote_control dans une source d’exigences locales compatible :

allow_remote_control = false

Lorsque le contrôle à distance de l’appareil est pris en charge, allow_remote_control = false le désactive. Si vous omettez la clé, les exigences n’imposent aucune restriction au contrôle à distance et les vérifications habituelles de disponibilité du produit s’appliquent. Cette exigence ne désactive pas les connexions SSH à distance.

Définir les approbations et les autorisations d’exécution

Cette section explique comment configurer les approbations, les limites des autorisations et les valeurs initiales. Commencez par les garde-fous de la politique et les valeurs par défaut. Les procédures suivantes expliquent comment utiliser les exigences TOML pour imposer un responsable des approbations, définir des profils d’autorisations personnalisés, restreindre l’accès au système de fichiers, définir des dérogations par hôte et établir des règles de commande.

Exigences imposées par l’administrateur (requirements.toml)

Les exigences encadrent les paramètres sensibles pour la sécurité : politique d’approbation, responsable des approbations, politique de la fonctionnalité Révision automatique, mode de bac à sable, profils d’autorisations, mode de recherche web, hooks gérés, serveurs MCP que les utilisateurs peuvent activer et sources de marketplaces de plugins qu’ils peuvent utiliser. Lorsqu’il détermine la configuration à appliquer, par exemple à partir de config.toml, des fichiers de profil ou des paramètres de substitution de la CLI, le client local remplace toute valeur incompatible avec une règle imposée par une valeur compatible et en informe l’utilisateur. Si vous configurez une liste de serveurs autorisés avec mcp_servers, le client n’active un serveur MCP que si son nom et son identité correspondent tous deux à une entrée approuvée. Sinon, il le désactive.

Les exigences peuvent aussi encadrer les indicateurs de fonctionnalité via la table [features] de requirements.toml. Les fonctionnalités ne sont pas toutes sensibles pour la sécurité, mais les entreprises peuvent en imposer les valeurs si elles le souhaitent. Les clés omises ne sont soumises à aucune contrainte.

Pour Codex 0.138.0 ou version ultérieure, privilégiez les profils d’autorisations avec allowed_permission_profiles et le paramètre géré default_permissions. Réservez allowed_sandbox_modes aux anciens déploiements qui configurent encore sandbox_mode.

Pour la liste exacte des clés, consultez la section requirements.toml de la référence de configuration.

Définir les garde-fous pour les approbations, le bac à sable et la recherche web

Utilisez Exigences > Garde-fous de la politique pour limiter les options des clients compatibles. Ces contrôles encadrent la configuration sans définir la valeur initiale. Définissez celle-ci séparément sous Valeurs par défaut.

1. Dans Global, ouvrez Politiques d’approbation et sélectionnez les modes d’approbation autorisés. Par exemple, Demander si nécessaire permet à l’agent de demander une approbation pour des actions telles qu’une exécution hors du bac à sable. Ne jamais demander empêche les demandes d’approbation sans autoriser pour autant une exécution sans restriction.
2. Ouvrez Modes de bac à sable pour limiter les options de l’ancien système de bac à sable. Lecture seule restreint les écritures, Écriture dans l’espace de travail les autorise dans l’espace de travail et les répertoires racines configurés comme accessibles en écriture, et Accès complet supprime l’isolation du système de fichiers. Utilisez les exigences relatives aux profils d’autorisations pour les déploiements qui utilisent des profils d’autorisations à la place de sandbox_mode.
3. Dans Global, ouvrez Modes de recherche web pour limiter la recherche web. Choisissez En cache pour permettre la recherche dans le cache sans recherche en direct, ou Désactivé pour désactiver la recherche web. Les restrictions de recherche web sont distinctes des règles réseau des commandes.
4. Vérifiez les options autorisées et les valeurs par défaut correspondantes, puis sélectionnez Enregistrer les modifications.

Une exigence non définie n’impose aucune limite au titre de cette politique. Les autres politiques applicables restent en vigueur. L’option Demander pour les commandes non fiables correspond à untrusted dans la liste des valeurs autorisées par les exigences. Elle ne rétablit pas le paramètre explicite approval_policy = "untrusted", qui a été retiré. Dans ce cas, suivez les consignes de migration ci-dessous.

Pour restreindre la recherche web, utilisez Global > Exigences > Garde-fous de la politique > Modes de recherche web. Voici l’équivalent TOML :

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] autorise uniquement "disabled". Par exemple, allowed_web_search_modes = ["cached"] empêche la recherche web en direct, même dans les sessions danger-full-access.

Définir les valeurs de configuration par défaut

Les valeurs par défaut fournissent aux membres une configuration initiale. Elles n’imposent aucune restriction et n’accordent pas l’accès à une fonctionnalité de l’espace de travail.

1. Ouvrez la fiche Valeurs par défaut de la politique. Conservez les valeurs par défaut qui concernent l’agent dans son ensemble dans Global. Utilisez un onglet d’environnement disponible pour les valeurs par défaut d’exécution prises en charge.
2. Sous Exécution des commandes, choisissez la politique d’approbation et le responsable des approbations initiaux, ainsi que le mode de bac à sable ou les autorisations par défaut applicables. Le responsable des approbations détermine qui examine les demandes par défaut. La politique d’approbation détermine quand une demande peut être formulée.
3. Sous Recherche web, choisissez le mode initial de recherche web et le contexte de recherche web. Sous Applications et outils, vérifiez Applications/connecteurs, Outils en monde ouvert et Outils destructifs pour les outils d’application pris en charge.
4. Vérifiez que les valeurs par défaut respectent vos Exigences, puis sélectionnez Enregistrer les modifications.

Utilisez Modifier au format TOML pour les valeurs par défaut prises en charge sans commande visuelle, comme la configuration des marketplaces de plugins. Ces valeurs par défaut cloud suivent l’ordre de priorité habituel de la configuration. Elles diffèrent de l’ancien ordre de priorité de managed_config.toml, qui donne la priorité aux valeurs par défaut gérées sur la configuration locale au démarrage.

Exemple de fichier requirements.toml

Cet exemple bloque --ask-for-approval never et --sandbox danger-full-access (y compris --yolo) :

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

Ici, untrusted conserve le comportement d’approbation plus strict découlant de trust_level = "untrusted". Il ne rétablit pas la prise en charge du paramètre explicite approval_policy = "untrusted".

Migrer depuis la politique d’approbation untrusted retirée

Codex et ChatGPT Work ne prennent plus en charge approval_policy = "untrusted". Supprimez ce paramètre des valeurs par défaut gérées, de l’ancien fichier managed_config.toml et de toute configuration utilisateur, de projet, de profil ou de démarrage qui le définit.

Pour une utilisation interactive en lecture seule, sélectionnez approval_policy = "on-request" avec un bac à sable ou un profil d’autorisations en lecture seule autorisé par vos exigences gérées. Les commandes autorisées par ce bac à sable peuvent s’exécuter sans approbation.

Pour conserver des approbations de commande plus strictes, omettez le paramètre explicite approval_policy, définissez trust_level = "untrusted" dans l’entrée du projet du fichier utilisateur ~/.codex/config.toml et conservez untrusted dans allowed_approval_policies. Cela désactive également la configuration locale du projet. Définir explicitement on-request remplace cette politique. Consultez Migrer depuis la politique d’approbation untrusted retirée pour des exemples et les compromis de sécurité associés.

Configurer la politique de la fonctionnalité Révision automatique

Pour utiliser la Révision automatique par défaut, sélectionnez Global > Valeurs par défaut > Exécution des commandes > Responsable des approbations. Les utilisateurs peuvent toujours choisir un autre responsable autorisé. Pour imposer la Révision automatique ou remplacer la politique que suit le responsable des approbations, sélectionnez Modifier au format TOML et modifiez le document requirements.toml de Global. Les actions du navigateur disposent de leurs propres paramètres de Révision automatique.

L’exemple suivant impose la Révision automatique pour les demandes d’approbation éligibles. Pour autoriser également l’approbation manuelle, incluez "user" dans allowed_approvals_reviewers.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

Pour remplacer l’intégralité de la politique, utilisez guardian_policy_config. Consultez la configuration de la Révision automatique pour connaître la politique par défaut et savoir comment préparer une politique de remplacement.

Contrôler les profils d’autorisations disponibles

Utilisez Valeurs par défaut > Exécution des commandes > Autorisations par défaut pour choisir le profil intégré que les utilisateurs auront au démarrage. Pour imposer la liste des profils disponibles ou définir des profils personnalisés, sélectionnez Modifier au format TOML et configurez requirements.toml dans Global ou dans l’environnement d’exécution compatible concerné. Le choix d’un profil par défaut ne restreint pas à lui seul les profils disponibles.

Utilisez allowed_permission_profiles pour déterminer quels profils d’autorisations intégrés ou personnalisés les utilisateurs peuvent sélectionner. Ce paramètre est l’équivalent de allowed_sandbox_modes pour les profils d’autorisations. Utilisez la liste qui correspond au mode de sélection des autorisations de vos utilisateurs.

Les listes de profils d’autorisations autorisés nécessitent Codex 0.138.0 ou version ultérieure. Codex 0.137.0 et les versions antérieures ignorent allowed_permission_profiles et le paramètre géré default_permissions.

N’utilisez les exemples de profils d’autorisations ci-dessous qu’une fois tous les clients gérés passés à une version compatible. Attendez la fin de la mise à niveau du parc avant de déployer des profils personnalisés gérés.

Lorsqu’elle est présente, la table contient la liste complète des profils autorisés. Elle autorise les profils définis sur true et refuse ceux qui sont omis ou définis sur false, y compris les profils intégrés ajoutés dans de futures versions de Codex.

Autoriser les profils standard

Cette politique autorise l’accès en lecture seule et l’accès à l’espace de travail, mais refuse l’accès complet :

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

Ajouter un profil par défaut géré selon le principe du moindre privilège

Les administrateurs peuvent définir un profil personnalisé dans la même source d’exigences. Choisissez des noms propres à votre organisation qui n’entrent pas en conflit avec ceux de la configuration chargée par les utilisateurs. Un nom personnalisé ne peut pas commencer par : ni reprendre le nom réservé filesystem.

Ne déployez pas de profils personnalisés gérés sur des clients exécutant Codex 0.137.0 ou une version antérieure. Ces clients reconnaissent la table des profils, mais ignorent la valeur par défaut gérée qui sélectionne le profil.

Par exemple :

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

Autoriser uniquement les profils définis par l’entreprise

Omettez tous les profils intégrés si les utilisateurs doivent pouvoir sélectionner uniquement les profils définis par l’administrateur :

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Le profil personnalisé peut hériter de :workspace même si les utilisateurs ne peuvent pas sélectionner directement le profil intégré :workspace.

Désactiver un profil autorisé par une autre source

Les listes de profils autorisés se combinent par nom de profil. Comme les exigences cloud ont priorité sur les exigences système, elles peuvent utiliser false pour désactiver un profil autorisé dans le fichier système.

Exigences cloud :

default_permissions = ":read-only"

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

Exigences système :

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # Not honored because cloud requirements set this to false.

Définissez explicitement default_permissions sur un profil autorisé. Si vous omettez ce paramètre, le moteur d’exécution local utilise :workspace par défaut uniquement si :workspace et :read-only sont tous deux explicitement autorisés. En l’absence de allowed_permission_profiles, les exigences gérées ne limitent pas les noms de profils que les utilisateurs peuvent sélectionner. Chaque entrée doit désigner un profil intégré ou un profil personnalisé défini dans une source de configuration ou d’exigences chargée. Définissez les profils personnalisés dans les exigences gérées pour contrôler leur comportement de façon centralisée.

Imposer des interdictions de lecture

Utilisez Modifier au format TOML pour ajouter des restrictions du système de fichiers au document requirements.toml de Global ou de l’environnement d’exécution compatible concerné. Ces restrictions bloquent la lecture des chemins sensibles. Un profil en lecture seule par défaut ne masque pas les fichiers.

Les administrateurs peuvent interdire la lecture de chemins exacts ou correspondant à des motifs glob avec [permissions.filesystem]. Les utilisateurs ne peuvent pas assouplir ces exigences dans leur configuration locale.

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

En présence d’interdictions de lecture, le moteur d’exécution local refuse les autorisations d’accès complet et maintient l’exécution locale dans un bac à sable en lecture seule ou limité à l’espace de travail pour faire respecter ces interdictions. Sur Windows en mode natif, le paramètre géré deny_read s’applique aux outils qui accèdent directement aux fichiers. Les lectures effectuées par les sous-processus du shell n’utilisent pas cette règle du bac à sable.

Adapter les exigences du bac à sable selon l’hôte

Utilisez Modifier au format TOML dans Sécurité des agents pour définir des exigences propres à certains hôtes. Les contrôles d’environnement sélectionnent un environnement d’exécution. Les motifs d’hôte sélectionnent les machines correspondantes dans le moteur d’exécution compatible.

Utilisez [[remote_sandbox_config]] si une même politique gérée doit appliquer des exigences de bac à sable différentes selon l’hôte. Vous pouvez, par exemple, conserver une configuration par défaut plus stricte sur les ordinateurs portables tout en autorisant l’écriture dans l’espace de travail sur certaines machines de développement ou certains runners de CI. Pour le moment, les entrées propres aux hôtes remplacent uniquement allowed_sandbox_modes :

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Le moteur d’exécution local compare chaque entrée de hostname_patterns au nom d’hôte qu’il a pu déterminer. Il privilégie le nom de domaine complet lorsqu’il est disponible et utilise à défaut le nom d’hôte local. La comparaison est insensible à la casse. * correspond à une suite quelconque de caractères et ? à un seul caractère.

Dans une même source d’exigences, la première entrée [[remote_sandbox_config]] correspondante l’emporte. Si aucune entrée ne correspond, le moteur d’exécution local conserve la valeur de premier niveau de allowed_sandbox_modes. La correspondance du nom d’hôte sert uniquement à sélectionner la politique. Elle ne constitue pas une preuve authentifiée de l’identité de l’appareil.

Imposer des règles de commande à partir des exigences

Utilisez Modifier au format TOML dans Sécurité des agents pour ajouter des règles de commande et des restrictions de serveurs MCP au document requirements.toml de Global. Les règles de commande déterminent s’il faut demander une approbation ou interdire les commandes correspondantes. Les restrictions MCP limitent les identités de serveur que le client peut activer. Le contrôle Politiques d’approbation ne permet de définir aucun de ces deux ensembles de règles.

Les administrateurs peuvent également imposer des règles de commande restrictives depuis requirements.toml à l’aide d’une table [rules]. Ces règles fusionnent avec celles des fichiers .rules habituels, et la décision la plus restrictive l’emporte toujours.

Contrairement aux règles de .rules, les règles des exigences doivent préciser decision. Sa valeur doit être "prompt" ou "forbidden" (et non "allow").

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

Pour limiter les serveurs MCP qu’un client local peut activer, ajoutez une liste de serveurs approuvés avec mcp_servers. Pour les serveurs stdio, établissez la correspondance avec command. Pour les serveurs HTTP prenant en charge le streaming, utilisez url :

[mcp_servers.docs]
identity = { command = "codex-mcp" }

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

Sous forme de chaîne, identity.command vérifie uniquement la correspondance avec la valeur de command configurée. Cette forme n’examine ni args, ni cwd, ni env, ni env_vars.

Pour encadrer un appel stdio complet, vérifiez la correspondance de l’exécutable et de chaque argument positionnel :

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

L’exécutable, le nombre d’arguments et leur ordre doivent correspondre. Les règles d’argument et d’URL prennent en charge les correspondances de type exact, prefix et regex, ce dernier type portant sur la valeur entière. Même sous forme structurée, les règles de commande n’examinent ni cwd, ni env, ni env_vars. Les serveurs MCP fournis avec un plugin utilisent les mêmes structures d’identité sous plugins.<plugin>.mcp_servers.<server>.

Si mcp_servers est présent mais vide, le client local désactive tous les serveurs MCP.

Configurer l’accès réseau

Les commandes et l’application de bureau disposent de contrôles réseau distincts. Commencez par les Contrôles d’utilisation du réseau pour le trafic des commandes prises en charge. Vérifiez les limites de l’environnement et du moteur d’exécution, puis utilisez au besoin les exigences propres à l’application de bureau. Les règles de site du navigateur sont décrites dans Contrôler le navigateur et l’utilisation de l’ordinateur.

Utiliser le proxy système pour les requêtes du client natif

Le paramètre expérimental features.respect_system_proxy permet au moteur d’exécution natif de Codex, utilisé par l’application de bureau ChatGPT et par Codex, d’utiliser les paramètres de proxy du système d’exploitation pour ses propres requêtes réseau. Activez-le sur les appareils qui nécessitent un proxy système ou une configuration automatique du proxy (PAC). Sa valeur par défaut est false.

Ajoutez les lignes suivantes à une source compatible de valeurs par défaut config.toml ou à managed_config.toml :

[features]
respect_system_proxy = true

La configuration locale d’un projet ne peut pas activer ce paramètre. Pour la gestion MDM sur macOS, incluez le même TOML dans config_toml_base64. Redémarrez le client après avoir modifié la configuration locale. Pour annuler l’activation, définissez le paramètre sur false dans la source de configuration qui l’a activé.

Connexion et valeurs par défaut cloud

La fonctionnalité distincte system_proxy_fallback est activée par défaut. Après un échec de connexion, elle peut retenter les requêtes de connexion et de configuration cloud prises en charge via le proxy système, même si respect_system_proxy vaut false. Ce mécanisme de secours peut permettre aux clients compatibles de se connecter et de récupérer les valeurs par défaut cloud sans activation locale. Désactiver uniquement respect_system_proxy ne désactive pas ce mécanisme.

Si l’accès direct échoue et que le mécanisme de secours est indisponible, désactivé ou échoue à son tour, déployez respect_system_proxy localement avant la connexion.

Portée et limites

Vérifiez la connexion et l’envoi d’une requête authentifiée avec les versions de client et les réseaux que vous prévoyez d’utiliser. Tenez compte des limites suivantes :

• Requêtes concernées : le paramètre s’applique aux clients réseau du moteur d’exécution de Codex. Il ne configure pas toutes les requêtes de l’application de bureau ChatGPT ou du navigateur, ni tous les processus de plugins ou les commandes du shell. Il n’impose pas de liste de destinations autorisées et ne garantit pas le blocage des connexions directes. Pour le trafic pris en charge, consultez les exigences réseau des commandes et les exigences réseau de l’application de bureau.
• Plateformes prises en charge : macOS et Windows prennent en charge la détection native du proxy système. Si le système ne peut pas déterminer le proxy, le moteur d’exécution utilise les paramètres de proxy explicites de l’environnement, s’ils existent. Sinon, il se connecte directement. Sur les autres plateformes, il utilise les paramètres d’environnement ou, à défaut, une connexion directe, sans détection native du proxy système.
• Routage PAC : le moteur d’exécution sélectionne une seule route dans le résultat PAC. Si la connexion échoue, il n’essaie pas les entrées de proxy ou DIRECT suivantes du résultat.
• Authentification Windows : les versions compatibles peuvent répondre à une demande d’authentification HTTP 407 du proxy lors de l’établissement du tunnel en utilisant les identifiants de l’utilisateur Windows connecté avec Negotiate ou NTLM. Les proxys HTTPS qui nécessitent des jetons d’authentification liés à la connexion TLS du proxy ne sont pas pris en charge.

Configurer les exigences d’accès réseau

Dans Sécurité des agents, utilisez Exigences > Contrôles d’utilisation du réseau pour gérer l’accès réseau des commandes prises en charge. Configurez une base commune dans Global ou utilisez un onglet Environnements locaux ou Environnements Codex Cloud disponible pour les paramètres d’exécution propres à un environnement.

1. Réglez Gestion du réseau sur Activée pour appliquer les règles de domaine au trafic des commandes gérées. L’ajout de règles de domaine ne suffit pas à activer le proxy géré.
2. Sous Règles réseau, sélectionnez Ajouter une règle réseau. Saisissez un domaine, par exemple api.openai.com ou **.example.com, sans schéma d’URL ni chemin. Choisissez Autoriser ou Refuser sous Accès, puis sélectionnez Enregistrer la règle pour mettre à jour le brouillon. Répétez l’opération pour les autres destinations.
3. Réglez Autoriser uniquement les domaines ajoutés par les administrateurs sur Activé si les paramètres utilisateur et les approbations par domaine ne doivent pas étendre la liste gérée de domaines autorisés. Ajoutez les autorisations nécessaires. Une liste composée uniquement d’interdictions n’autorise pas les autres destinations.
4. Vérifiez Autoriser l’accès au réseau local pour les workflows qui nécessitent des services locaux en écoute ou des destinations privées. Les connexions locales directes peuvent contourner les règles de domaine du proxy. Avant de modifier ce paramètre, consultez les limites de connectivité de Codex Cloud ci-dessous.
5. Vérifiez les règles héritées et les messages de validation, puis sélectionnez Enregistrer les modifications. Dans chaque environnement d’exécution concerné, testez une requête qui doit aboutir et une autre qui doit être bloquée.

Régler Gestion du réseau sur Désactivée efface les règles réseau définies dans cette portée et enregistre une désactivation explicite, sans couper l’accès à Internet. Non défini supprime les paramètres réseau définis dans cette portée afin que la politique applicable ou les valeurs par défaut du moteur d’exécution puissent s’appliquer. Supprimer les paramètres d’un environnement peut rétablir les règles héritées de Global. Utilisez Modifier au format TOML pour les champs réseau avancés ou les anciennes listes de domaines existantes que l’éditeur visuel ne peut pas représenter.

Dans Codex 0.166.0, [network_proxy] est le nom canonique de la table de requirements.toml qui régit l’accès réseau des commandes gérées. Codex accepte également l’ancien nom [experimental_network]. Choisissez un seul nom de table par couche. Si les couches utilisent des noms différents, Codex applique l’ordre de priorité habituel des exigences.

Définissez enabled = true dans la table gérée pour démarrer le proxy indépendamment du paramètre utilisateur features.network_proxy. Le bac à sable actif doit lui aussi autoriser les commandes à accéder au réseau. L’exemple utilise le nom reconnu par les anciens clients et les anciennes couches de validation des politiques.

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

Utilisez experimental_network.managed_allowed_domains_only = true uniquement si vous définissez également des entrées "allow" gérées par l’administrateur dans [experimental_network.domains] et souhaitez que ces règles soient exclusives. Si ce paramètre vaut true sans règle d’autorisation gérée, les règles d’autorisation de domaine ajoutées par les utilisateurs cessent d’être effectives. Ne combinez pas la table canonique domains avec les anciennes listes allowed_domains ou denied_domains.

*.example.com correspond uniquement aux sous-domaines. **.example.com correspond au domaine racine et à ses sous-domaines. Une règle d’interdiction correspondante l’emporte sur une règle d’autorisation.

La syntaxe des domaines, les règles pour les destinations locales ou privées, la priorité des interdictions sur les autorisations et les limites relatives au DNS rebinding sont les mêmes que pour le réseau du bac à sable décrit dans Approbations et sécurité des agents.

Le proxy achemine le trafic des commandes locales exécutées dans le bac à sable. Avant d’accéder à une origine, les outils de navigation vérifient aussi les interdictions réseau gérées et les listes exclusives de destinations autorisées. Il s’agit d’une vérification de politique distincte : le trafic du navigateur ne passe pas par le proxy des commandes. Ce proxy ne filtre ni la recherche web, ni les applications et connecteurs, ni les serveurs MCP, ni le trafic des applications natives, ni les requêtes aux services Codex, ni le trafic propre aux autres fonctionnalités. Utilisez les contrôles de chaque interface :

• Utilisez allowed_web_search_modes pour restreindre la recherche web.
• Utilisez features.apps = false pour désactiver les intégrations d’applications et de connecteurs, et features.plugins = false pour désactiver les plugins lorsque cette option est prise en charge.
• Utilisez la liste gérée mcp_servers pour restreindre les serveurs MCP autorisés.
• Utilisez des exigences de fonctionnalité telles que browser_use, in_app_browser et computer_use pour restreindre les capacités de navigation et d’utilisation de l’ordinateur.
• Pour les commandes gérées prises en charge dans Codex Cloud, vérifiez les paramètres Internet de l’environnement ainsi que ceux de Sécurité des agents. L’environnement peut bloquer un domaine autorisé dans Sécurité des agents.

Testez séparément les commandes ordinaires et les exécutions entièrement hors du bac à sable que la politique autorise. Une exécution entièrement hors du bac à sable peut, une fois approuvée, contourner le proxy géré des commandes. Consultez Isolation réseau.

Aucune destination effectivement autorisée : lorsque Gestion du réseau et Autoriser uniquement les domaines ajoutés par les administrateurs sont activés, les commandes gérées ordinaires ne peuvent atteindre une destination que si une règle d’autorisation explicite ou héritée le permet. Vérifiez les destinations effectivement autorisées avant d’enregistrer.

Connectivité locale et privée de Codex Cloud : si une commande Cloud ne peut pas atteindre un domaine autorisé, vérifiez la valeur effective de allow_local_binding. Si ce paramètre est désactivé par héritage, l’accès au proxy en amont peut être bloqué. Consultez Connectivité locale et privée de Codex Cloud pour connaître la valeur par défaut et les dérogations propres à Cloud.

Lorsque les exigences de l’environnement sont vides, celles de Global s’appliquent. Le réglage Gestion du réseau sur Désactivée est indépendant du paramètre d’accès à Internet de l’environnement Cloud. Consultez les contrôles d’exécution de Sécurité des agents pour plus de détails sur la portée d’exécution.

Priorité des politiques réseau et limites du moteur d’exécution

Au sein d’une même politique, l’ordre de priorité décroissant est le suivant : dérogation d’environnement propre au système d’exploitation → dérogation d’environnement valable pour tous les systèmes → Global. Une politique de priorité supérieure l’emporte toujours sur une politique de priorité inférieure, même si cette dernière est plus spécifique. Certaines exigences ont des règles de fusion propres à chaque champ. Le moteur d’exécution fait ensuite respecter les exigences ainsi déterminées. Distinguez les cas propres aux champs réseau ci-dessous de la priorité des politiques.

Ces exemples comparent les paramètres d’un environnement à ceux de Global au sein d’une même politique. Ils supposent que la gestion du réseau est déjà configurée et qu’aucune politique de priorité supérieure ne modifie les valeurs. Ils décrivent la fusion des champs concernés et leur comportement à l’exécution.

Définir des accès aux domaines différents selon l’environnement

Pour une même règle de domaine au sein d’une politique, une dérogation d’environnement définie par l’administrateur peut autoriser un domaine refusé dans Global ou refuser un domaine autorisé dans Global. Sans dérogation d’environnement, la règle de Global est héritée. D’autres interdictions effectives ou contrôles d’accès peuvent toujours bloquer une requête.

Combinaison des règles de domaine

Ces résultats comparent une même clé de domaine dans une seule politique, sans qu’une politique de priorité supérieure modifie le résultat. La valeur de priorité supérieure remplace celle de la même clé. Les autres clés héritées sont conservées. Une autorisation ne contourne pas une autre interdiction correspondante, par exemple une règle héritée avec un caractère générique. Une table de domaines vide pour l’environnement n’efface pas les règles héritées.

Exemple : refusez packages.example.com dans Global et autorisez-le dans l’environnement de développement. Celui-ci peut autoriser le domaine dans les conditions décrites ci-dessus. L’environnement de production hérite de l’interdiction de Global, sauf dérogation.

Vérifiez que l’exécuteur déployé prend en charge ces règles de fusion. Leur prise en charge par les exécuteurs gérés standard reste à valider.

Limites de l’orchestrateur. Le moteur d’exécution cloud ne prend pas en charge les ports d’écoute HTTP/SOCKS gérés ni les proxys à l’écoute sur une adresse autre que l’adresse de bouclage. La prise en charge des règles de socket dépend du mode d’exécution. Les paramètres d’exécution locale du tableau ci-dessous ne constituent pas une configuration prise en charge par l’orchestrateur.

Autres limites réseau du moteur d’exécution

Tous les champs ci-dessous appartiennent à la table gérée network_proxy (également acceptée sous le nom experimental_network) de requirements.toml. Les flèches indiquent la valeur de Global, suivie de celle de l’environnement dans la même politique. Ces cas d’exécution locale ne permettent pas de conclure que l’orchestrateur prend en charge les mêmes paramètres.

L’activation du proxy, l’exclusivité des autorisations, le comportement du proxy en amont et les règles de socket Unix dépendent de l’exécuteur. N’appliquez pas à ces paramètres les règles de combinaison des clés de domaine. Vérifiez les valeurs effectives et testez le moteur d’exécution déployé. Pour la connectivité locale et privée de Codex Cloud, consultez Configurer les exigences d’accès réseau.

Vérifier le comportement avant le déploiement

Testez les destinations, les services locaux en écoute, le comportement du proxy et les chemins de socket réellement utilisés par vos workflows. Dans chaque environnement concerné, testez une action qui doit aboutir et une autre qui doit être bloquée. Vérifiez que la version déployée du moteur d’exécution prend en charge chacun des paramètres utilisés.

Contrôler les destinations réseau de l’application de bureau

Utilisez Modifier au format TOML dans Sécurité des agents pour configurer ces exigences propres à l’application de bureau dans Global. L’interface Contrôles d’utilisation du réseau gère l’accès réseau des commandes, qui relève d’une politique distincte.

Utilisez [application.network] dans requirements.toml pour restreindre les destinations réseau de l’application de bureau. Avec enabled = true, les requêtes externes doivent utiliser HTTPS ou WSS et correspondre exactement à un domaine dont la valeur est "allow" dans [application.network.domains]. Les sous-domaines ne sont pas implicitement autorisés. Une table de domaines vide n’autorise aucune destination externe. Consultez la référence de configuration pour connaître les clés prises en charge.

Cette politique est distincte de celle qui régit le réseau des commandes et des règles d’origine du navigateur. Elle ne restreint pas les destinations des modules natifs ni des processus lancés, et ne régit pas l’exécution dans Work Cloud.

Configurer les plugins et les hooks gérés

Pour ces tâches, utilisez Modifier au format TOML dans Sécurité des agents ou une source de configuration locale compatible. Les valeurs par défaut des marketplaces, les restrictions imposées aux plugins et les hooks gérés répondent à des besoins différents. Choisissez la procédure correspondant à votre politique.

Configurer les marketplaces de plugins et leurs valeurs par défaut

Utilisez Sécurité des agents > Modifier au format TOML pour définir des marketplaces locales ou Git et les valeurs par défaut des plugins dans le document config.toml de Global. Vous pouvez également distribuer ces paramètres dans le fichier config.toml du système. Ils fournissent une configuration initiale pour les marketplaces et les plugins, sans imposer de politique. Pour limiter les sources que les membres peuvent utiliser, configurez les exigences relatives aux sources des marketplaces.

Consultez la référence de configuration pour les clés de configuration, l’ordre de priorité de la configuration pour les substitutions et les paramètres de plugins du dépôt pour la configuration au niveau du projet. L’importation et la synchronisation GitHub de l’espace de travail sont distinctes.

Contrôler la disponibilité des plugins

Utilisez Modifier au format TOML dans Sécurité des agents pour imposer les paramètres de fonctionnalité des plugins dans le document requirements.toml de Global, ou distribuez-les via les exigences locales pour les clients gérés sur les appareils. Valeurs par défaut > Applications et outils > Applications/connecteurs définit les valeurs par défaut des outils d’application. Ce réglage est distinct du paramètre imposé features.plugins. Pour les autorisations de plugins dans l’espace de travail, consultez Applications et connecteurs.

Pour désactiver les plugins dans les clients locaux compatibles, définissez features.plugins sur false dans requirements.toml :

features.plugins = false

Ce paramètre s’applique également lorsque les utilisateurs se connectent à Codex avec une clé API. Consultez la référence de features.plugins pour connaître la configuration prise en charge.

Restreindre les sources des marketplaces de plugins

Utilisez Modifier au format TOML pour configurer les exigences relatives aux sources des marketplaces dans le document requirements.toml de Global, ou distribuez-les via les exigences locales. Ces règles limitent les sources locales ou Git que les utilisateurs peuvent ajouter et utiliser. Elles sont distinctes des valeurs par défaut des marketplaces.

Pour restreindre les sources des marketplaces de plugins, définissez restrict_to_allowed_sources = true et ajoutez une ou plusieurs règles de source :

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

Les règles Git vérifient l’URL normalisée du dépôt et, si elle est présente, la valeur exacte de ref. Les motifs d’hôte sont des expressions régulières comparées au nom d’hôte Git en minuscules. Utilisez ^ et $ pour que la correspondance porte sur le nom d’hôte entier. Les règles locales exigent un chemin absolu et normalisé. Consultez la référence de requirements.toml pour le schéma complet et les règles de fusion.

Ces exigences rejettent les opérations d’ajout de marketplace, d’installation de plugin et d’actualisation de marketplace Git configurée qui ne correspondent à aucune règle. Elles filtrent également les marketplaces configurées et leurs plugins à l’exécution.

Les marketplaces Git sélectionnées par OpenAI, y compris le catalogue accessible avec une clé API, doivent également correspondre à la liste des sources autorisées. Pour les autoriser, incluez la source Git suivante sans contrainte sur ref :

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

Pour exclure ces catalogues, omettez cette source et vérifiez qu’aucune règle d’hôte plus large ne l’autorise. Les plugins fournis avec le client et les plugins de l’espace de travail installés à distance sont indépendants de cette politique relative aux sources Git sélectionnées par OpenAI.

Ces restrictions de source s’appliquent uniquement aux clients locaux qui prennent en charge les opérations sur les marketplaces de plugins : ChatGPT et Codex dans l’application de bureau, ainsi que Codex CLI. Elles ne contrôlent pas l’utilisation des plugins dans ChatGPT sur le Web ou sur mobile et n’ajoutent aucun plugin à l’extension IDE.

Imposer des hooks gérés à partir des exigences

Dans Sécurité des agents, ouvrez Global > Exigences > Modifier au format TOML. Pour le mode Work avec accès à l’ordinateur local et pour les dots, configurez les gestionnaires mcp_tool pris en charge dans le document requirements.toml de Global. Avant le déploiement, testez la connexion de rappel et vérifiez ce qui se passe lorsque le délai de réponse du rappel est dépassé. Consultez Hooks avec orchestration cloud pour connaître les événements pris en charge et le comportement en cas d’échec.

Pour Codex en local, distribuez les scripts des hooks avec votre outil de gestion des appareils. Pour imposer leur exécution même si un utilisateur désactive les hooks, imposez [features].hooks = true dans requirements.toml. Consultez l’exemple de configuration de hooks gérés pour connaître les chemins des scripts et savoir comment autoriser uniquement les hooks gérés.

Comprendre la portée et la priorité des politiques

Cette section explique où une politique s’applique, comment les exigences se combinent, comment les clients reçoivent les paramètres gérés dans le cloud et comment vérifier le résultat.

Pour Work avec accès local et les dots, les paramètres pris en charge de la politique Global régissent l’orchestrateur cloud partagé lorsque la politique gérée est activée. Les exigences d’exécution locale applicables régissent l’ordinateur connecté. Les conteneurs cloud de Work conservent les politiques Work Cloud existantes et les contrôles d’appareil pris en charge continuent de s’appliquer à l’exécution locale. Codex conserve son fonctionnement habituel en matière de configuration. La configuration gérée n’attribue pas de place dans un espace de travail et n’accorde pas l’accès aux fonctionnalités. Pour gérer ces accès, consultez Rôles et autorisations de l’espace de travail.

Sécurité des agents et accès à l’ordinateur local avec Work Cloud

Utilisez Sécurité des agents dans la console d’administration pour gérer les politiques et la configuration. Cette rubrique remplace Politiques et configuration. Elle est disponible dans la console d’administration indépendamment de l’accès à l’ordinateur local avec Work Cloud. Les politiques existantes, leurs affectations et leur ordre sont conservés. Vérifiez vos politiques existantes dans Sécurité des agents. L’accès à l’ordinateur local avec Work Cloud s’active séparément. Consultez Sécurité des agents pour les consignes de migration.

Avant de migrer l’automatisation de vos politiques vers Sécurité des agents :

1. Identifiez les intégrations concernées. Recensez les configurations Terraform et les scripts qui mettent à jour les politiques, puis notez les politiques qu’ils gèrent.

2. Utilisez l’API des politiques pour gérer les paramètres de Global. Pour gérer les paramètres de Local ou de Codex Cloud, utilisez l’interface de Sécurité des agents. Les workflows API existants pour Global restent disponibles après la migration. Testez vos scripts et vos intégrations Terraform, puis vérifiez que les affectations et l’ordre des politiques sont conservés.

3. Apportez les modifications nécessaires et testez l’automatisation. Vérifiez que la mise à jour atteint la politique voulue dans Sécurité des agents et que les contrôles qui en résultent sont effectivement appliqués.

La migration des politiques n’accorde pas à Work ni aux dots l’accès à l’ordinateur local. Il est recommandé d’examiner ou de créer les politiques avant le déploiement, mais la procédure de confirmation n’exige pas la création d’une politique pour activer l’accès. Avant d’activer Autoriser l’accès à l’ordinateur local, vérifiez la configuration de référence migrée ou créez une configuration de référence cloud si vos politiques sont actuellement distribuées uniquement par MDM. Si enforce_residency est activé dans une politique cloud, Autoriser l’accès à l’ordinateur local est désactivé pour Work comme pour les dots. Cette protection ne configure pas la résidence des données de l’espace de travail et ne désactive pas à elle seule Work Cloud ni les dots.

Les dérogations d’environnement permettent d’adapter les paramètres pris en charge au sein d’une politique. Dans une même politique, l’ordre de priorité décroissant est le suivant : dérogation d’environnement propre au système d’exploitation → dérogation d’environnement valable pour tous les systèmes → Global. Une politique de priorité supérieure l’emporte toujours sur une politique de priorité inférieure, même si cette dernière est plus spécifique. Certaines exigences ont des règles de fusion propres à chaque champ. Vérifiez les éditeurs de dérogations et les champs disponibles pour votre espace de travail.

Avant d’activer l’accès local pour un workflow qui utilise des hooks, vérifiez quels hooks s’exécutent avec l’orchestration cloud.

Emplacements et ordre de priorité

Pour l’exécution locale, les exigences s’appliquent dans l’ordre de priorité croissant suivant. Cet ordre s’applique aussi aux étapes locales lorsque Work Cloud accède à l’ordinateur local :

1. Fichier système requirements.toml (/etc/codex/requirements.toml sur les systèmes Unix, dont Linux et macOS, ou %ProgramData%\OpenAI\Codex\requirements.toml sur Windows).
2. Exigences de Sécurité des agents distribuées dans le paquet de configuration cloud.
3. Champs de l’ancien fichier managed_config.toml que le client local réinterprète comme des exigences.
4. Préférences gérées macOS (MDM) distribuées via com.openai.codex:requirements_toml_base64.

Les couches de priorité supérieure remplacent les valeurs scalaires et les listes ordinaires des couches de priorité inférieure. Les tables fusionnent par clé. Certaines exigences, notamment les règles, les hooks et les restrictions du système de fichiers, se combinent selon des règles propres à chaque champ. Consultez la référence de requirements.toml pour connaître le schéma actuel sans supposer que tous les champs fusionnent de la même manière.

Pour assurer la rétrocompatibilité, les clients locaux compatibles réinterprètent les anciens champs approval_policy, approvals_reviewer et sandbox_mode comme des exigences. Cette conversion ajoute, si nécessaire, des options de compatibilité. Utilisez requirements.toml pour définir explicitement les listes de valeurs autorisées.

Ordre de priorité pour l’accès à l’ordinateur local avec Work Cloud

Pour Work avec accès local et les dots, distinguez la politique de l’orchestrateur dans Global de la politique d’exécution. Les exigences locales applicables régissent l’ordinateur connecté. Les conteneurs cloud de Work et les ordinateurs cloud des dots utilisent leur propre configuration d’exécution et leurs propres exigences, au lieu du paquet d’environnement géré utilisé par les autres exécuteurs.

Pour l’exécution locale, les exigences MDM et les anciennes exigences gérées sur les appareils ont priorité sur Sécurité des agents. Le fichier d’exigences système de l’appareil a une priorité inférieure à Sécurité des agents. Dans chaque politique, appliquez d’abord les dérogations d’environnement propres au système d’exploitation, puis celles valables pour tous les systèmes, puis les paramètres de Global. Entre plusieurs politiques, la priorité l’emporte sur le degré de spécificité.

Les exigences imposent des contraintes, tandis que les valeurs de configuration par défaut fournissent des valeurs initiales. Pour Work avec accès local et les dots, les paramètres pris en charge de la politique Global s’appliquent via l’orchestrateur cloud partagé lorsque la politique gérée est activée. Les exigences locales applicables de requirements.toml régissent l’exécution sur l’ordinateur connecté. Les conteneurs cloud de Work et les ordinateurs cloud des dots utilisent leur propre configuration d’exécution et leurs propres exigences, au lieu du paquet d’environnement géré utilisé par les autres types d’exécuteurs. Les restrictions d’exécution locale ne s’appliquent pas automatiquement à ces ordinateurs cloud. Vérifiez les autorisations des fonctionnalités cloud et testez séparément l’exécution locale et l’exécution cloud.

Conservez les contrôles de l’orchestrateur dans Global, notamment les approbations et la recherche web. Utilisez les commandes dédiées Politiques d’approbation autorisées et Modes de recherche web autorisés lorsqu’elles sont disponibles, et TOML pour les autres champs pris en charge. Consultez la référence de configuration pour connaître la liste des champs et leur portée d’exécution.

Exigences gérées dans le cloud

Lorsqu’un utilisateur se connecte avec ChatGPT dans le cadre d’une offre compatible, les clients locaux pris en charge peuvent recevoir les exigences que l’administrateur impose à l’espace de travail. Ce mécanisme distribue des politiques compatibles avec requirements.toml. Il n’accorde pas l’accès à l’espace de travail et ne remplace pas le contrôle d’accès basé sur les rôles de l’espace de travail. Les exigences d’authentification doivent être gérées localement.

Configurez les exigences courantes avec les commandes de Sécurité des agents. Pour une politique qui n’autorise que les approbations sur demande et les bacs à sable en lecture seule ou en mode workspace-write, utilisez Politiques d’approbation et Modes de bac à sable sous Garde-fous de la politique. Pour demander également une approbation avant l’exécution d’un point d’entrée de shell pris en charge, utilisez Modifier au format TOML pour ajouter la table [rules] au document requirements.toml de Global.

Voici l’équivalent TOML complet :

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

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

Vérifiez que chaque version des clients gérés prend en charge les clés choisies. Affectez la politique aux utilisateurs ou aux groupes visés et vérifiez qu’elle prend effet sur leurs clients compatibles. Consultez la référence de configuration pour connaître le schéma actuel et l’interface d’administration pour vérifier le fonctionnement actuel des affectations.

Le service sélectionne les couches d’exigences gérées par l’entreprise qui s’appliquent à l’identité connectée. Le client local les évalue avec les autres sources d’exigences décrites dans Emplacements et ordre de priorité. Utilisez l’interface d’administration actuelle pour créer et affecter des politiques dans l’espace de travail. Ne vous fiez pas à une copie de l’algorithme de correspondance des groupes : le service d’administration gère cette logique et peut la modifier indépendamment du format des exigences locales.

Pour les clés prises en charge et des exemples, consultez l’exemple de fichier requirements.toml et la référence de requirements.toml.

Comment les clients locaux appliquent les exigences gérées dans le cloud

Le fonctionnement du chargement local et du cache décrit ci-dessous concerne les clients locaux compatibles. Il ne détermine pas à quel moment une modification de politique cloud prend effet dans une tâche déjà en cours avec accès à l’ordinateur local depuis Work Cloud. Vérifiez la politique effective avant de vous appuyer sur une restriction modifiée.

Lorsqu’un utilisateur démarre un client local compatible et se connecte avec ChatGPT dans le cadre d’une offre compatible, le client recherche d’abord une entrée de cache valide correspondant à son identité. À défaut, le client tente de récupérer le paquet applicable, renouvelle la requête si nécessaire et écrit une entrée de cache signée en cas de réussite. Si la requête échoue ou dépasse le délai imparti et qu’aucune entrée de cache valide n’est disponible, le chargement du paquet de configuration cloud renvoie une erreur. Le client ne démarre pas silencieusement sans la couche d’exigences gérées dans le cloud.

Après cette vérification du cache, le client combine les exigences cloud avec les autres couches d’exigences décrites ci-dessus. Une actualisation en arrière-plan met à jour le paquet en cache pour les prochains chargements de configuration. Cela ne garantit pas qu’une tâche en cours utilise immédiatement une politique modifiée. Certains paramètres de bureau nécessitent un redémarrage de l’application. Suivez les invitations à redémarrer et vérifiez les paramètres effectifs avant de vous appuyer sur la modification.

Vérifier le résultat pour les administrateurs et les employés

Désignez un responsable pour chaque politique gérée, consignez les utilisateurs ou groupes qui doivent la recevoir et documentez la raison métier de chaque restriction portant sur le système de fichiers, le réseau, les approbations ou les profils d’autorisations.

Testez un workflow autorisé et un workflow bloqué avec un utilisateur disposant des autorisations prévues. Vérifiez les paramètres effectifs dans le client compatible. L’appartenance à un groupe ou l’attribution d’un rôle dans l’espace de travail ne suffit pas à imposer une restriction au moteur d’exécution local.

Utilisez Tester les politiques dans Sécurité des agents pour vérifier quelles politiques correspondent au membre, au groupe ou au rôle sélectionné. Dans une session de modification, le test porte sur le brouillon en cours sans l’enregistrer. Le résultat indique les politiques sélectionnées. Il n’indique ni la configuration finale après fusion, ni si un client applique une restriction. Après l’enregistrement, testez les workflows autorisés et bloqués sur chaque client concerné et dans chaque mode d’exécution applicable.

Déployer une configuration gérée sur les appareils

Utilisez les exigences système locales ou la gestion MDM pour les restrictions d’authentification et les politiques gérées sur les appareils. Au démarrage, l’ancien mécanisme managed_config.toml suit un ordre de priorité différent des Valeurs par défaut de Sécurité des agents. La procédure MDM couvre à la fois les exigences et les anciennes valeurs par défaut.

Gérer l’authentification localement

Définissez allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store et chatgpt_base_url dans le fichier requirements.toml du système local ou dans les exigences MDM de macOS. Codex ignore ces quatre champs dans les exigences gérées dans le cloud. Les exigences d’authentification locales s’appliquent avant le chargement des identifiants et avant que Codex récupère la politique cloud.

Pour imposer la connexion avec ChatGPT à un espace de travail approuvé et stocker les identifiants dans le gestionnaire d’identifiants du système d’exploitation, utilisez la configuration suivante :

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

allowed_login_methods accepte chatgpt, api ou les deux. Si vous omettez ce paramètre, il ne restreint pas les méthodes de connexion. Si vous le définissez, la liste doit contenir au moins une méthode. api autorise l’authentification par API, y compris avec Amazon Bedrock. La restriction relative à l’espace de travail s’applique aussi aux jetons d’accès Codex.

Les paramètres forced_login_method et forced_chatgpt_workspace_id configurés par l’utilisateur doivent respecter les exigences. L’espace de travail sélectionné par l’utilisateur doit aussi figurer dans la liste gérée des espaces de travail autorisés. Si aucun espace de travail ne correspond, la connexion avec ChatGPT est indisponible. L’authentification par API reste disponible si elle est autorisée. Si aucune méthode de connexion n’est disponible, Codex refuse de démarrer.

Consultez la référence des exigences pour les modes de stockage des identifiants et la configuration de l’URL du service.

Imposer les paramètres OpenTelemetry

Dans Codex CLI 0.166.0, utilisez [otel] dans requirements.toml pour configurer séparément les exportateurs de journaux, de traces et de métriques, attribuer un libellé à l’environnement et choisir les contenus exportés par Codex. Cet exemple envoie les journaux à un collecteur OTLP/HTTP et limite à 256 octets en UTF-8 le texte consigné pour chaque résultat d’outil. Il exclut le texte des prompts, le texte des réponses finales et les évaluations d’approbation automatique.

La version 26.1027.30824 de l’application de bureau pour macOS intègre la version 0.166.0-alpha.5.1 de la CLI. Cette version de la CLI ne prend pas en charge [otel] dans requirements.toml et ne peut donc pas imposer log_user_prompt = false au moyen de cette politique.

[otel]
environment = "prod"
exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary" } }
log_user_prompt = false
log_agent_responses = false
log_guardian_assessments = false
tool_result = { max_bytes = 256 }
span_attributes = { team = "platform" }
tracestate = { acme = { region = "eu" } }

Les valeurs gérées ont priorité sur la configuration locale. Pour exporter, trace_exporter et metrics_exporter, l’exigence de priorité la plus élevée qui définit l’exportateur fournit sa définition complète, y compris les en-têtes et les paramètres TLS. Chaque paramètre scalaire ainsi que la table tool_result prennent également la valeur fournie par l’exigence de priorité la plus élevée qui les définit. Les paramètres omis restent configurables, sauf si une autre couche d’exigences les définit.

Les attributs des spans fusionnent par nom d’attribut. Les champs de tracestate fusionnent par membre et par nom de champ. Pour les entrées qui correspondent, la valeur de priorité supérieure l’emporte. Les autres entrées restent disponibles, même en présence d’une table de métadonnées vide. Consultez Observabilité et télémétrie pour connaître les options des exportateurs et le contenu des journaux.

Migrer des bases de données SQLite sur NFS

Sous Linux, Codex crée les nouvelles bases de données SQLite sur NFS en mode de journalisation DELETE. Pour migrer les bases existantes qui utilisent la journalisation en écriture anticipée (WAL), définissez unsafe_enforce_sqlite_journal_mode = true au premier niveau de requirements.toml. Ce paramètre est désactivé par défaut. Lorsque vous l’activez, Codex migre les bases avant de les ouvrir en écriture.

Le montage NFS doit prendre en charge les verrous POSIX entre les hôtes. Des options de montage comme nolock et local_lock=all empêchent ces verrous de fonctionner. Sur chaque hôte, arrêtez tous les clients SQLite qui utilisent ces bases, y compris Codex. Démarrez une seule instance de Codex et laissez tous les autres clients à l’arrêt jusqu’à ce que la migration ait réussi. L’utilisateur qui exécute cette instance doit disposer d’un accès en écriture au répertoire des bases de données et au verrou de migration. Les fichiers de remplacement conservent les bits de permission Unix des originaux et appartiennent à cet utilisateur. La migration ne reprend ni le propriétaire, ni le groupe, ni les listes de contrôle d’accès étendues des fichiers d’origine. Codex conserve les originaux dans un répertoire de sauvegarde privé.

Valeurs par défaut gérées (managed_config.toml)

Utilisez les valeurs par défaut de Sécurité des agents pour les valeurs initiales prises en charge dans le cloud. Cette section décrit l’ancien mécanisme managed_config.toml géré sur les appareils et son ordre de priorité distinct au démarrage. Modifier les Valeurs par défaut dans Sécurité des agents ne déploie pas de fichier managed_config.toml sur les appareils des membres.

Les valeurs par défaut gérées définissent la configuration de démarrage d’un client local compatible. Au démarrage, elles ont priorité sur le fichier config.toml local de l’utilisateur et sur les paramètres --config fournis via la CLI. Les utilisateurs peuvent modifier ces paramètres en cours d’exécution. Les valeurs par défaut s’appliquent de nouveau au démarrage suivant du client.

GPT-5.5 est retiré de Codex pour les utilisateurs connectés avec ChatGPT le 14 octobre 2026 à midi, heure avancée du Pacifique (19 h 00 UTC). Si une valeur par défaut gérée, un profil MDM macOS ou une configuration enregistrée impose gpt-5.5 à ces utilisateurs, remplacez-le par un modèle disponible. Choisissez gpt-6.1-sol une fois qu’un administrateur l’a activé pour les utilisateurs concernés. L’API OpenAI et les sessions Codex authentifiées avec une clé API ne sont pas concernées. Consultez la disponibilité des modèles dans l’espace de travail.

Pour les configurations qui imposent encore gpt-5.4 ou gpt-5.4-mini, suivez les consignes de migration de GPT-5.4.

Vérifiez que vos valeurs par défaut gérées respectent vos exigences. Le moteur d’exécution local rejette les valeurs interdites.

Ordre de priorité des couches de configuration

Le moteur d’exécution local établit la configuration effective dans l’ordre suivant, de la priorité la plus élevée à la plus basse :

• Préférences gérées (MDM macOS, priorité la plus élevée)
• managed_config.toml (fichier système géré)
• config.toml (configuration de base de l’utilisateur)

Les substitutions --config key=value de la CLI s’appliquent à la configuration de base, mais les couches gérées ont priorité. Chaque exécution commence donc avec les valeurs par défaut gérées, même si vous fournissez des options locales.

Le fichier config.toml du cloud suit l’ordre de priorité habituel de la configuration, qui diffère de l’ancien ordre ci-dessus. Le fichier requirements.toml du cloud suit l’ordre de priorité des exigences.

Emplacements

• Linux/macOS (Unix) : /etc/codex/managed_config.toml
• Windows/systèmes non Unix : ~/.codex/managed_config.toml

Si le fichier est absent, le moteur d’exécution local ignore la couche gérée.

Exemple de fichier managed_config.toml

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary" } }
log_user_prompt = false            # keep prompts redacted

Garde-fous recommandés

• Privilégiez workspace-write avec approbations pour la plupart des utilisateurs. Réservez l’accès complet aux conteneurs contrôlés.
• Conservez network_access = false, sauf si votre revue de sécurité autorise un collecteur ou des domaines nécessaires à vos workflows.
• Pour imposer les paramètres de télémétrie, utilisez les exigences OpenTelemetry. Conservez log_user_prompt = false, sauf si votre politique autorise le stockage du contenu des prompts.
• Examinez périodiquement les différences entre le fichier config.toml local et la politique gérée pour détecter les écarts. Les couches gérées doivent avoir priorité sur les options et les fichiers locaux.

Préférences gérées macOS (MDM)

Sur macOS, les administrateurs peuvent distribuer un profil d’appareil contenant des données TOML encodées en base64 aux emplacements suivants :

• Domaine de préférences : com.openai.codex
• Clés :
  • config_toml_base64 (valeurs par défaut gérées)
  • requirements_toml_base64 (exigences)

Le moteur d’exécution local interprète le contenu de ces « préférences gérées » comme du TOML. Pour les valeurs par défaut gérées (config_toml_base64), les préférences gérées ont la priorité la plus élevée. Pour les exigences (requirements_toml_base64), la priorité suit l’ordre des exigences. La même table [features] utilisée pour les exigences fonctionne dans requirements_toml_base64. Utilisez-y également les clés de fonctionnalité canoniques.

Procédure de configuration MDM

Le moteur d’exécution local prend en compte les profils MDM standard de macOS. Vous pouvez donc distribuer les paramètres à l’aide d’outils tels que Jamf Pro, Fleet ou Kandji. Pour un déploiement simple, procédez comme suit :

1. Préparez le contenu TOML géré et encodez-le avec base64, sans retour à la ligne.
2. Insérez la chaîne dans votre profil MDM, sous le domaine com.openai.codex, dans config_toml_base64 pour les valeurs par défaut gérées ou requirements_toml_base64 pour les exigences.
3. Distribuez le profil, puis demandez aux utilisateurs de redémarrer le client local compatible et de vérifier que le récapitulatif de la configuration au démarrage affiche les valeurs gérées.
4. Pour révoquer ou modifier une politique, mettez à jour le contenu géré. Le client lit la préférence actualisée au démarrage suivant.

Évitez d’intégrer des secrets ou des valeurs dynamiques qui changent fréquemment dans le profil. Soumettez le TOML géré à la même procédure de contrôle des modifications que tout autre paramètre MDM.