Configuration gérée

La configuration gérée permet aux administrateurs d’entreprise de définir les exigences et les valeurs par défaut prises en charge pour ChatGPT Work et Codex. Les exigences limitent ce que les utilisateurs et les tâches peuvent faire. Les valeurs par défaut fournissent les valeurs initiales. La prise en charge dépend du produit, de la version du client et de l’environnement d’exécution.

Commencez par Sécurité des agents dans la console d’administration pour les paramètres pris en charge et gérés via le cloud. Utilisez les commandes de réglage pour les tâches courantes, ou sélectionnez Modifier en TOML pour examiner, copier ou modifier le texte de la configuration. Les deux vues modifient la même politique ; TOML expose également les champs pris en charge qui n’ont pas de commande dédiée. Vous n’avez pas besoin de distribuer un fichier local pour utiliser les paramètres gérés via le cloud. Les restrictions d’authentification et les déploiements gérés sur les appareils disposent d’une configuration locale distincte.

Les administrateurs Enterprise peuvent contrôler le comportement des clients locaux pris en charge au moyen des éléments suivants :

• Exigences : contraintes imposées par les administrateurs que les utilisateurs ne peuvent pas modifier.

• Valeurs de configuration par défaut : paramètres de config.toml gérés par le 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 pris en charge. Les utilisateurs peuvent toujours modifier les paramètres pendant l’exécution. Le client réapplique ces valeurs par défaut au démarrage suivant.

Consultez Agent Security pour connaître la configuration de base Global, les remplacements par environnement et les listes de champs de l’orchestrateur et de l’exécuteur.

Configurer une politique dans Sécurité des agents

Lorsque Sécurité des agents est activé, les propriétaires et les administrateurs de l’espace de travail, ainsi que les membres disposant des autorisations d’administration Codex, peuvent gérer les politiques. L’accès à l’éditeur de politiques n’accorde pas aux membres l’accès aux fonctionnalités contrôlées par une politique.

Utilisez Valeurs par défaut de l’espace de travail pour définir la configuration de base de l’espace de travail. Utilisez Dérogations lorsque des utilisateurs, groupes ou rôles particuliers ont besoin de paramètres différents. Une dérogation ciblée détermine qui reçoit une politique ; un paramètre d’environnement détermine où les contrôles d’exécution pris en charge s’appliquent.

1. Ouvrez Console d’administration > Sécurité des agents, puis sélectionnez Valeurs par défaut de l’espace de travail ou la politique à modifier sous Dérogations.
2. Ouvrez Exigences pour définir des limites obligatoires, ou Valeurs par défaut pour définir les valeurs initiales que les membres peuvent modifier dans ces limites.
3. Conservez les paramètres d’approbation, de recherche web et les autres paramètres applicables à l’ensemble de l’agent dans Global. Lorsque cette option est disponible, utilisez Ajouter des paramètres d’environnement dans la carte correspondante pour ajouter Environnements locaux ou Environnements Codex Cloud pour les paramètres d’exécution pris en charge. Un document d’environnement vide hérite des paramètres de Global ; il ne copie ni ne fige la configuration de base actuelle.
4. Utilisez les commandes décrites dans ce guide. Pour les champs avancés, sélectionnez Modifier en TOML et modifiez le fichier requirements.toml ou config.toml de la portée appropriée. Sélectionnez Utiliser les commandes de réglage pour revenir à l’éditeur visuel.
5. Examinez les messages de validation, puis sélectionnez Enregistrer les modifications. L’application d’une règle dans un éditeur de règles met à jour le brouillon ; elle n’enregistre pas à elle seule la politique.
6. Vérifiez la sélection de la politique et le comportement des clients pris en charge comme décrit dans Vérifier l’expérience des administrateurs et des employés.

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

Copier ou réutiliser une configuration

L’éditeur visuel ne remplace pas TOML. Sélectionnez Modifier en 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 réglage pour revenir à l’éditeur visuel.

1. Ouvrez la politique source et sélectionnez Modifier en TOML.
2. Choisissez la portée à copier : Global ou un onglet d’environnement disponible. Copiez le texte de Exigences (requirements.toml), de Valeurs par défaut (config.toml), ou des deux, selon ce que vous souhaitez réutiliser.
3. Ouvrez la politique de destination, sélectionnez Modifier en TOML, puis choisissez la portée correspondante. Collez les exigences dans requirements.toml et les valeurs par défaut dans config.toml. Examinez les paramètres existants de la destination avant de remplacer le texte ; conservez les paramètres sans rapport qui doivent continuer à s’appliquer.
4. Examinez les messages de validation ainsi que les cibles et la priorité de la politique de destination, puis sélectionnez Enregistrer les modifications. Vérifiez le comportement qui en résulte côté client avant de vous appuyer sur la politique copiée.

Le texte copié contient les paramètres définis pour cette politique et cette portée. Il n’inclut pas les affectations, l’ordre des politiques, les autres documents d’environnement ni la configuration effective résultant de la combinaison des autres politiques et des paramètres de l’appareil. Copiez les paramètres d’environnement séparément si nécessaire. Le changement de vue ou la copie de texte n’enregistre pas les modifications d’une politique.

Essayez l’exemple ci-dessous : modifiez un paramètre, puis sélectionnez Modifier en TOML pour voir sa configuration. Revenez à la vue précédente avec Utiliser les commandes de réglage pour poursuivre vos essais.

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only"]
allowed_web_search_modes = ["disabled"]

Choisir la commande appropriée

Contrôler le navigateur et Computer Use

Utilisez Sécurité des agents dans la console d’administration pour gérer l’accès au navigateur et aux applications natives pour les clients de bureau pris en charge. Commencez par les commandes de l’interface. Les exemples TOML ci-dessous servent de référence de configuration pour la distribution de politiques par fichier et les paramètres qui nécessitent l’éditeur TOML.

Browser Use contrôle les actions effectuées par l’agent dans un navigateur. Computer Use contrôle les actions effectuées par l’agent dans les applications de bureau natives. Les paramètres du volet de navigateur intégré sont distincts de ceux de Browser Use. Consultez Sessions de navigateur et connexions existantes pour connaître les différences entre les modes d’accès au navigateur.

Avant de commencer

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

Utilisez Exigences pour les limites que les utilisateurs ne peuvent pas contourner. Valeurs par défaut définit les valeurs initiales dans ces limites. Autoriser un site ou une application n’installe pas de plugin, n’accorde pas d’autorisations du système d’exploitation, ne connecte pas l’utilisateur et n’approuve pas une action qui nécessite encore un examen.

Sous Disponibilité des fonctionnalités de bureau, examinez Utilisation du navigateur, Utilisation du 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 peut pas passer outre. Examinez Accès CDP complet séparément ; Bloquer l’activation par l’utilisateur empêche les utilisateurs de l’activer.

Ces contrôles de bureau ne configurent pas le navigateur hébergé de Work Cloud. Gérez Utilisation du navigateur cloud et Accès réseau cloud séparément sous Console d’administration > Autorisations et rôles > Capacités de l’espace de travail > Capacités de l’ordinateur cloud. Consultez comment Agent Security s’applique à Work Cloud.

Configurer l’accès au navigateur

1. Ouvrez Console d’administration > Sécurité des agents. Utilisez Valeur par défaut de l’espace de travail pour la configuration de référence de l’espace de travail, 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 les actions de la ligne Par défaut et choisissez Modifier les valeurs par défaut. Pour limiter l’accès aux sites approuvés, définissez Accès au site sur Bloquer, puis choisissez Appliquer la règle. La ligne Par défaut fournit les valeurs des paramètres qu’une règle de site correspondante laisse sur Utiliser la règle par défaut.
3. Choisissez Ajouter une règle de site. Dans Site ou motif, saisissez une origine : un schéma, un nom d’hôte et un port facultatif. Par exemple, https://example.com est valide ; https://example.com/files ne l’est pas. N’incluez ni chemin, ni requête, ni fragment. HTTP et HTTPS constituent des origines distinctes. Précisez le port lorsqu’il diffère du port par défaut du schéma.
4. Définissez Accès au site et examinez Téléchargements, Téléversements et Débogage/CDP. Choisissez Autoriser ou Bloquer selon le cas, ou laissez un paramètre sur Utiliser la règle par défaut. Débogage/CDP contrôle l’accès complet au Chrome DevTools Protocol pour le débogage du navigateur. Autoriser laisse les vérifications habituelles de politique et d’approbation se poursuivre.
5. Examinez Examen automatique, Toujours autoriser et Durée d’approbation pour le site. Durée d’approbation propose Ce tour et Ce fil. Examinez également Historique du navigateur, Enregistrer les approbations de site et Approuver automatiquement les demandes dans Contrôles du navigateur de bureau.
6. Choisissez Ajouter une règle, examinez les messages de validation et sélectionnez Enregistrer les modifications. Testez un site autorisé et un site bloqué sur un client pris en charge qui reçoit la politique. Testez séparément les téléversements, les téléchargements et les autres actions restreintes.

Ajouter une règle de site

La ligne Par défaut s’applique lorsqu’une règle de site laisse une autorisation sur Par défaut. Si des règles se chevauchent, Bloquer prévaut pour chaque autorisation.

Site ou motif 

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

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

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

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

Examen automatiqueUtiliser la règle par défaut

Toujours autoriserUtiliser la règle par défaut

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

La désactivation de l’examen automatique des actions du navigateur soumet ces actions à l’utilisateur pour approbation. Elle ne désactive pas la surveillance de la sécurité du modèle.

Lorsque plusieurs motifs d’origine correspondent, la valeur la plus restrictive prévaut pour chaque paramètre. La configuration locale ne peut pas assouplir un refus imposé par une politique gérée. Les refus réseau gérés et les listes d’autorisation exclusives s’appliquent également aux outils de navigateur. Consultez les champs de la politique du navigateur pour les motifs d’origine et le fonctionnement des approbations.

Computer Use peut également piloter un navigateur comme une application native. Les règles de site et de capacités de Browser Use ne s’appliquent pas à ce mode d’utilisation. Examinez séparément l’accès aux applications natives ; consultez les limites 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 les actions de la ligne Par défaut pour configurer l’accès aux applications sans règle correspondante. Pour limiter Computer Use aux applications approuvées, bloquez l’accès par défaut et ajoutez des règles d’autorisation pour 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 Application. Saisissez l’Identifiant de l’application exact pour un identifiant de bundle ou un Application User Model ID (AUMID). Pour Exécutable Windows, saisissez Nom de l’éditeur et Nom du produit ; Nom du binaire est facultatif. Utilisez des informations vérifiées sur l’identité de l’application, et non un nom d’affichage ou un chemin de fichier.
4. Définissez Accès à l’application pour la règle, puis choisissez Ajouter une règle. Examinez Enregistrer les approbations d’application sous Contrôles des applications de bureau, examinez les messages de validation et sélectionnez Enregistrer les modifications. Désactiver l’enregistrement des approbations permet toujours les approbations pour la session en cours ; autoriser leur enregistrement n’approuve pas une 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 toujours fournir les approbations requises.

Modifier la règle

Définissez l’accès par défaut aux applications et remplacez-le pour les applications correspondantes.

ApplicationIdentifiant de bundle macOS

Identifiant de l’application 

Accès à l’applicationChoisir l’accès

Consultez les champs de la politique de Computer Use pour les exigences d’identité sous Windows et les restrictions d’utilisation en mode verrouillé pour les Mac gérés.

Vérifier la politique effective

Si un site ou une application autorisés restent bloqués, vérifiez les autres règles correspondantes, les affectations et la priorité des politiques, les exigences relatives aux appareils et la configuration utilisateur. Une règle d’autorisation dans une source ne contourne pas un autre refus applicable. Consultez les emplacements des exigences et leur ordre de priorité.

Si un paramètre n’a aucun effet, vérifiez que le client, le système d’exploitation et le mode de distribution de la politique le prennent en charge. Portez une attention particulière à Work Cloud avec accès à l’ordinateur local : certains champs sont partiellement pris en charge ou nécessitent une validation. Consultez la compatibilité avec Work dans la référence de configuration.

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

Référence de configuration TOML

Les exemples suivants expriment la même intention de politique pour requirements.toml. Utilisez-les pour gérer la politique à l’aide de fichiers ou de l’éditeur TOML. Vous n’avez pas besoin de modifier un fichier local pour utiliser les contrôles disponibles dans Agent Security.

Cet exemple de configuration du navigateur refuse l’accès par défaut, autorise https://example.com, bloque les téléversements et l’accès CDP complet sur ce site, et limite l’approbation d’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 l’examen automatique des actions du navigateur, définissez browser_use.disable_auto_review = true, ou définissez auto_review = "deny" dans une politique d’origine pour le restreindre pour cette origine.

Pour activer les outils de site dans un espace de travail Enterprise éligible, définissez browser_use.allow_webmcp = true. Cette activation administrée s’applique au navigateur intégré de l’application de bureau. Définir ce paramètre sur false ou l’omettre maintient les vérifications habituelles de disponibilité de la fonctionnalité ; false n’impose aucun blocage. Les préférences de l’utilisateur et les autorisations des sites continuent de s’appliquer.

Cet exemple de configuration des applications natives autorise Calculator sur macOS, refuse les autres applications par défaut, et empêche les approbations d’applications de persister 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 ; binary_name est facultatif.

Pour connaître tous les champs et toutes les valeurs pris en charge, consultez la référence de requirements.toml. Pour désactiver une fonctionnalité plutôt que de restreindre des sites ou des applications spécifiques, consultez Imposer les indicateurs de fonctionnalité.

Autres contrôles de l’application de bureau

Les contrôles suivants de l’application de bureau couvrent la disponibilité des fonctionnalités, Locked Use, Appshots et le contrôle à distance des appareils. Utilisez les paramètres dédiés pour la disponibilité des fonctionnalités et Locked Use ; configurez Appshots et le contrôle à distance des appareils avec Modifier en TOML. Pour les restrictions de destination du trafic de l’application de bureau, consultez Contrôler les destinations réseau de l’application de bureau.

Imposer les indicateurs de fonctionnalité

Pour les fonctionnalités de bureau disponibles dans Agent Security, ouvrez Global > Exigences > Disponibilité des fonctionnalités de bureau. Définissez Navigateur intégré, Utilisation du navigateur, Utilisation d’un navigateur externe ou Utilisation de l’ordinateur sur Forcer la désactivation pour désactiver la fonctionnalité correspondante, puis sélectionnez Enregistrer les modifications. Pour Accès CDP complet, choisissez Bloquer l’activation par l’utilisateur pour empêcher les utilisateurs de l’activer. Autoriser une fonctionnalité ne modifie pas sa disponibilité selon le produit, la plateforme ou le déploiement.

Pour les autres indicateurs de fonctionnalité pris en charge, utilisez Modifier en TOML et le document requirements.toml de Global, ou une source locale d’exigences prise en charge. Les exemples suivants imposent des valeurs pour les fonctionnalités de l’environnement d’exécution et celles propres à l’application 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

Utilisez les clés canoniques de la table [features] de config.toml pour les fonctionnalités de l’environnement d’exécution. L’environnement d’exécution local normalise les fonctionnalités reconnues pour respecter ces valeurs imposées et rejette les écritures incompatibles dans config.toml ou dans les paramètres de fonctionnalité des fichiers de profil.

Le paramètre administré unified_exec = false maintient l’exécution des commandes disponible, mais désactive les processus pouvant être repris et 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 le programme de mise à jour propre à l’application de bureau ChatGPT au redémarrage, lorsque cette option est prise en charge. Ce paramètre n’affecte pas le déploiement externe de paquets et ne prolonge pas la prise en charge des anciennes versions de l’application. Pour obtenir des conseils de configuration et de déploiement, consultez Gérer les mises à jour de l’application.
• browser_use = false désactive les fonctionnalités Browser Use prises en charge. External Browser Use et Computer Use pour les applications natives disposent de contrôles distincts.
• browser_use_full_cdp_access = false désactive l’accès CDP complet dans l’environnement 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 désactive l’utilisation de Browser Use par l’agent au moyen des extensions de navigateur prises en charge.
• computer_use = false désactive Computer Use pour les applications natives, y compris le pilotage d’un navigateur en tant qu’application native, ainsi que Record & Replay et les parcours d’installation ou de configuration associés.

Désactiver uniquement Browser Use ne bloque pas toutes les voies d’accès au navigateur. Pour les applications natives, Computer Use peut toujours piloter un navigateur lorsque cette fonctionnalité et l’accès à l’application sont autorisés ; les règles de Browser Use relatives aux sites et aux fonctionnalités ne s’appliquent pas à cette voie. Pour la bloquer, définissez Utilisation de l’ordinateur sur Forcer la désactivation (computer_use = false), ou refusez l’application de navigateur dans les règles des applications si les autres applications natives doivent rester disponibles. Examinez Utilisation d’un navigateur externe et Navigateur intégré séparément. Consultez Sessions de navigateur et connexions existantes pour connaître les contrôles qui s’appliquent à chaque voie.

Si vous omettez ces clés, la politique autorise les fonctionnalités, sous réserve de leur disponibilité habituelle selon le client, la plateforme et le déploiement.

Restreindre l’utilisation de l’ordinateur verrouillé

Pour empêcher les utilisateurs d’activer Locked Use sur un Mac administré, ouvrez Global > Exigences > Contrôles de l’application de bureau, définissez Autoriser l’utilisation en mode verrouillé sur Désactivé, puis sélectionnez Enregistrer les modifications. Ce paramètre ne désactive pas Locked Use sur un Mac où cette fonctionnalité est déjà activée.

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

[computer_use]
allow_locked_computer_use = false

Cette exigence supprime les contrôles permettant d’activer Locked Use. Elle ne désactive pas Locked Use si cette fonctionnalité est déjà activée. Si vous l’omettez, la disponibilité habituelle du produit et le paramètre local de l’utilisateur continuent de s’appliquer.

Désactiver Appshots

Appshots permet aux clients pris en charge d’inclure des instantanés d’applications. Pour désactiver cette fonctionnalité pour les utilisateurs administrés via le cloud, ouvrez Modifier en TOML dans Agent Security et définissez le champ de premier niveau allow_appshots dans le document requirements.toml de Global. Pour les déploiements administrés sur les appareils, utilisez la source locale d’exigences applicable :

allow_appshots = false

Lorsque la fonctionnalité Appshots est disponible, allow_appshots = false la désactive. Si vous omettez cette clé, les exigences ne restreignent pas Appshots, et les vérifications habituelles de disponibilité du produit s’appliquent. Les clients app-server qui lisent les exigences effectives via configRequirements/read reçoivent la même restriction sous la forme de allowAppshots ; une valeur null ou l’absence de allowAppshots ne désactive pas Appshots.

Désactiver le contrôle à distance des appareils

Pour désactiver le contrôle à distance des appareils pour les utilisateurs administrés via le cloud, utilisez Modifier en TOML dans Agent Security 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 locale d’exigences prise en charge :

allow_remote_control = false

Lorsque le contrôle à distance des appareils est pris en charge, allow_remote_control = false le désactive. Si vous omettez cette clé, les exigences ne restreignent pas le contrôle à distance des appareils, 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

Utilisez cette section pour définir le comportement des approbations, les limites des autorisations et les valeurs initiales par défaut. Commencez par les Garde-fous de la politique et les Valeurs par défaut. Les tâches suivantes expliquent les exigences TOML relatives à l’imposition d’un réviseur, aux profils d’autorisation personnalisés, aux restrictions du système de fichiers, aux remplacements de paramètres d’hôte et aux règles de commande.

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

Les exigences limitent les paramètres sensibles pour la sécurité (politique d’approbation, responsable de l’examen des approbations, politique d’examen automatique, mode de sandbox, profils d’autorisations, mode de recherche web, hooks gérés, MCP servers que les utilisateurs peuvent activer et sources de places de marché de plugins qu’ils peuvent utiliser). Lors de la résolution de la configuration (par exemple à partir de config.toml, de fichiers de profil ou de remplacements de configuration via la CLI), si une valeur entre en conflit avec une règle imposée, le client local utilise une valeur compatible et en informe l’utilisateur. Si vous configurez une liste d’autorisation mcp_servers, le client n’active un MCP server que si son nom et son identité correspondent tous deux à une entrée approuvée ; sinon, il le désactive.

Les exigences peuvent également limiter les indicateurs de fonctionnalité via la table [features] de requirements.toml. Notez que les fonctionnalités ne sont pas toujours sensibles pour la sécurité, mais les entreprises peuvent figer leurs valeurs si elles le souhaitent. Les clés omises restent sans contrainte.

Pour Codex 0.138.0 ou version ultérieure, privilégiez les profils d’autorisation avec allowed_permission_profiles et un default_permissions géré. Utilisez allowed_sandbox_modes uniquement pour les déploiements hérités qui configurent encore sandbox_mode.

Pour obtenir 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 choix pris en charge par les clients. Ces contrôles restreignent la configuration ; ils ne sélectionnent pas la valeur initiale. Définissez la valeur initiale séparément dans 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 que l’élévation des privilèges du bac à sable. Ne jamais demander empêche les demandes d’approbation ; cette option n’autorise pas une exécution sans restriction.
2. Ouvrez Modes de bac à sable pour limiter les choix de bac à sable hérités. Lecture seule restreint les écritures, Écriture dans l’espace de travail autorise les écritures dans l’espace de travail et les racines accessibles en écriture configurées, et Accès complet supprime le cloisonnement du système de fichiers. Utilisez les exigences relatives aux profils de permissions pour les déploiements qui utilisent des profils de permissions à la place de sandbox_mode.
3. Dans Global, ouvrez Modes de recherche web pour limiter la recherche web. Choisissez En cache pour autoriser la recherche en cache sans recherche en direct, ou Désactivée pour désactiver la recherche web. Les restrictions de recherche web sont distinctes des règles réseau applicables aux commandes.
4. Vérifiez les choix autorisés 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 d’autorisation des exigences ; elle ne rétablit pas le paramètre explicite approval_policy = "untrusted" désormais retiré. Suivez les instructions de migration ci-dessous pour ce cas.

Pour restreindre la recherche web, utilisez Global > Exigences > Garde-fous des politiques > Modes de recherche web. L’équivalent TOML est :

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 aucun accès à une fonctionnalité de l’espace de travail.

1. Ouvrez la carte Valeurs par défaut de la politique. Conservez les valeurs par défaut communes à l’agent dans Global ; utilisez un onglet d’environnement disponible pour les valeurs d’exécution par défaut 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 Permissions par défaut applicables. Le responsable détermine qui examine les demandes d’approbation par défaut ; la politique d’approbation détermine quand ces demandes peuvent survenir.
3. Sous Recherche web, choisissez le mode Recherche web et le Contexte de recherche web initiaux. Sous Applications et outils, vérifiez Applications/connecteurs, Outils en environnement 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 en TOML pour les valeurs par défaut prises en charge sans commandes visuelles, comme la configuration des places de marché 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 place les valeurs par défaut gérées au-dessus de la configuration locale au démarrage.

Exemple de 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" ; cela ne fait pas de approval_policy = "untrusted" un paramètre explicite pris en charge.

Migrer 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 en lecture seule ou un profil de permissions 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 commandes plus strictes, omettez tout paramètre approval_policy explicite et définissez trust_level = "untrusted" dans l’entrée du projet du fichier utilisateur ~/.codex/config.toml, puis 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 en matière de sécurité.

Configurer la politique de vérification automatique

Pour activer la vérification automatique par défaut, utilisez Global > Valeurs par défaut > Exécution des commandes > Responsable des approbations. Une valeur par défaut permet aux utilisateurs de choisir un autre responsable autorisé. Pour imposer la vérification automatique ou fournir les instructions de vérification de votre organisation, utilisez plutôt Modifier en TOML et modifiez le fichier requirements.toml de Global. Ces exigences sont distinctes des commandes de vérification automatique du navigateur.

Utilisez allowed_approvals_reviewers pour imposer ou autoriser la vérification automatique. Définissez ce paramètre sur ["auto_review"] pour imposer la vérification automatique, ou incluez "user" lorsque les utilisateurs peuvent choisir l’approbation manuelle.

Définissez guardian_policy_config pour remplacer la section propre au locataire de la politique de vérification automatique. L’environnement d’exécution local utilise toujours le modèle intégré du responsable de la vérification et le contrat de sortie. Le paramètre géré guardian_policy_config est prioritaire sur le paramètre local [auto_review].policy.

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

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

Contrôler les profils d’autorisation disponibles

Utilisez Valeurs par défaut > Exécution des commandes > Permissions par défaut pour choisir le profil intégré initial des utilisateurs. Pour imposer les profils que les utilisateurs peuvent sélectionner ou définir des profils personnalisés, utilisez Modifier en TOML et configurez requirements.toml pour la portée Global applicable ou celle d’un environnement d’exécution pris en charge. Le choix d’un profil par défaut ne restreint pas à lui seul les profils disponibles.

Utilisez allowed_permission_profiles pour contrôler les profils d’autorisation intégrés et personnalisés que les utilisateurs peuvent sélectionner. C’est l’équivalent de allowed_sandbox_modes pour les profils d’autorisation ; utilisez la liste d’autorisation qui correspond à la manière dont vos utilisateurs sélectionnent les autorisations.

Les listes d’autorisation des profils d’autorisation 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 default_permissions géré.

N’utilisez les exemples de profils d’autorisation ci-dessous qu’une fois que chaque client géré exécute une version compatible. Ne déployez pas de profils personnalisés gérés tant que la mise à niveau du parc n’est pas terminée.

Lorsqu’elle est présente, la table constitue la liste complète des profils autorisés. Elle autorise les profils définis sur true et refuse les profils 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’espace de travail, mais pas 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 une valeur par défaut gérée appliquant le principe du moindre privilège

Les administrateurs peuvent définir un profil personnalisé dans la même source d’exigences. Utilisez des noms de profils propres à l’organisation qui n’entreront pas en conflit avec ceux de la configuration chargée des utilisateurs. Les noms personnalisés ne peuvent pas commencer par : ni utiliser 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 pas la valeur par défaut gérée qui en sélectionne un.

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 lorsque les utilisateurs ne doivent sélectionner que des 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 étendre :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 d’autorisation des profils se combinent par nom de profil. Les exigences cloud ayant une priorité supérieure aux exigences système, elles peuvent utiliser false pour désactiver un profil autorisé par 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é. S’il est omis, l’environnement d’exécution local utilise :workspace par défaut uniquement lorsque :workspace et :read-only sont tous deux explicitement autorisés. Lorsque allowed_permission_profiles est absent, les exigences gérées ne limitent pas les noms de profils que les utilisateurs peuvent sélectionner. Chaque entrée doit nommer 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 afin de contrôler leur comportement de manière centralisée.

Appliquer les exigences d’interdiction de lecture

Utilisez Modifier en TOML pour ajouter des restrictions du système de fichiers au fichier requirements.toml de Global ou de l’environnement d’exécution pris en charge applicable. Ces restrictions bloquent la lecture des chemins sensibles ; une valeur par défaut en lecture seule ne masque pas les fichiers à elle seule.

Les administrateurs peuvent interdire la lecture de chemins exacts ou de motifs glob avec [permissions.filesystem]. Les utilisateurs ne peuvent pas assouplir ces exigences au moyen de la 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.
]

Lorsque des exigences d’interdiction de lecture sont présentes, l’environnement d’exécution local refuse les permissions d’accès complet et maintient l’exécution locale dans un bac à sable en lecture seule ou limité à l’espace de travail afin de pouvoir les appliquer. Sous Windows natif, le paramètre géré deny_read s’applique aux outils d’accès direct aux fichiers ; les lectures des sous-processus du shell n’utilisent pas cette règle de bac à sable.

Remplacer les exigences de sandbox selon l’hôte

Utilisez Modifier en TOML dans Sécurité des agents pour rédiger des exigences propres à chaque hôte. Les commandes d’environnement sélectionnent un environnement d’exécution ; les motifs d’hôte sélectionnent les machines correspondantes au sein de l’environnement d’exécution pris en charge.

Utilisez [[remote_sandbox_config]] lorsqu’une même politique gérée doit appliquer des exigences de sandbox différentes selon les hôtes. Par exemple, vous pouvez conserver une valeur par défaut plus stricte pour les ordinateurs portables tout en autorisant les écritures dans l’espace de travail sur les machines de développement ou les runners CI correspondants. Les entrées propres à un hôte ne remplacent actuellement que 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"]

L’environnement d’exécution local compare chaque entrée hostname_patterns au nom d’hôte résolu au mieux. Il privilégie le nom de domaine complet lorsqu’il est disponible et utilise à défaut le nom d’hôte local. La correspondance n’est pas sensible à la casse ; * correspond à n’importe quelle séquence de caractères et ? à un seul caractère.

La première entrée [[remote_sandbox_config]] correspondante est retenue au sein de la même source d’exigences. Si aucune entrée ne correspond, l’environnement d’exécution local conserve le allowed_sandbox_modes de niveau supérieur. La correspondance du nom d’hôte sert uniquement à sélectionner la politique ; ne la considérez pas comme une preuve authentifiée de l’appareil.

Appliquer les règles de commande définies dans les exigences

Utilisez Modifier en TOML dans Sécurité des agents pour ajouter des règles de commande et des restrictions relatives aux MCP servers au fichier requirements.toml de Global. Les règles de commande définissent les décisions d’approbation ou de refus pour les commandes correspondantes ; les restrictions MCP limitent les identités de serveurs que le client peut activer. La commande Politiques d’approbation ne permet de créer 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 sont fusionnées avec les fichiers .rules habituels, et la décision la plus restrictive reste prioritaire.

Contrairement à .rules, les règles des exigences doivent préciser decision, et cette décision 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 restreindre les MCP servers qu’un client local peut activer, ajoutez une liste d’autorisation mcp_servers. Pour les serveurs stdio, faites correspondre command ; pour les serveurs HTTP en streaming, faites correspondre url :

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

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

La forme chaîne de identity.command ne vérifie que la correspondance avec command configuré. Elle n’examine pas args, cwd, env ni env_vars.

Pour contraindre une invocation stdio complète, faites correspondre l’exécutable et 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’arguments et d’URL prennent en charge les correspondances exact, prefix et regex sur la valeur entière. Les règles de commande structurées n’examinent toujours pas cwd, env ni env_vars. Les MCP servers fournis avec les plugins 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 MCP servers.

Configurer l’accès réseau

L’accès réseau des commandes et celui de l’application de bureau utilisent des commandes de contrôle différentes. Commencez par Contrôles d’utilisation du réseau pour le trafic des commandes pris en charge, vérifiez les limites de l’environnement et du moteur d’exécution, puis utilisez les exigences distinctes de l’application de bureau si nécessaire. Les règles relatives aux sites du navigateur restent dans Contrôler le navigateur et Computer Use.

Configurer les exigences d’accès au réseau

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

1. Réglez Mise en réseau gérée sur Activé pour appliquer les règles de domaine au trafic des commandes gérées. L’ajout de règles de domaine seul n’active pas le proxy géré.
2. Sous Règles réseau, sélectionnez Ajouter une règle réseau. Saisissez un Domaine tel que 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 d’autorisation gérée. Incluez les entrées d’autorisation nécessaires ; une liste composée uniquement de refus n’autorise aucune autre destination.
4. Examinez Autoriser l’accès au réseau local pour les workflows nécessitant des services en écoute locaux ou des destinations privées. Les connexions locales directes peuvent contourner les règles de domaine du proxy. Consultez les limites de connectivité de Codex Cloud ci-dessous avant de modifier ce paramètre.
5. Examinez les règles héritées et les messages de validation, puis sélectionnez Enregistrer les modifications. Testez une requête qui doit aboutir et une autre qui doit être bloquée dans chaque environnement d’exécution concerné.

Régler Mise en réseau gérée sur Désactivé efface les règles réseau définies pour cette portée et enregistre une valeur de désactivation explicite ; cela ne désactive pas l’accès à Internet. Non défini supprime les paramètres réseau définis pour cette portée afin que la politique applicable ou les valeurs par défaut de l’environnement d’exécution puissent s’appliquer. La suppression des paramètres d’environnement peut faire réapparaître les règles héritées de Global. Utilisez Modifier en TOML pour les champs réseau avancés ou les anciennes listes de domaines existantes que l’éditeur visuel ne peut pas représenter.

Utilisez [experimental_network] dans requirements.toml lorsque les administrateurs doivent définir de manière centralisée les exigences d’accès au réseau. Ces exigences sont distinctes de l’option utilisateur features.network_proxy : elles permettent de configurer la mise en réseau du bac à sable sans cet indicateur de fonctionnalité, mais n’accordent pas aux commandes un accès au réseau lorsque le bac à sable actif maintient la mise en réseau désactivée. Définissez experimental_network.enabled = true pour activer le proxy géré ; les règles de domaine seules n’activent pas le proxy.

[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" administrées par les administrateurs dans [experimental_network.domains] et souhaitez que ces règles soient exclusives. Si cette valeur est true sans règles d’autorisation gérées, les règles d’autorisation de domaine ajoutées par les utilisateurs ne restent pas 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 de refus correspondante l’emporte sur une règle d’autorisation.

La syntaxe des domaines, les règles relatives aux destinations locales ou privées, la priorité des refus sur les autorisations et les limites liées à la réaffectation DNS sont identiques au comportement réseau de la sandbox décrit dans Approbations et sécurité des agents.

Le proxy achemine les commandes locales exécutées dans la sandbox. Les outils de navigation vérifient également les refus réseau gérés et les listes d’autorisation exclusives avant d’accéder à une origine. Il s’agit d’un contrôle de politique distinct, qui n’achemine pas le trafic du navigateur via le proxy de commandes. Il ne filtre pas la recherche web, les applications et connecteurs, les MCP servers, le trafic des applications natives, les requêtes au service Codex ni les autres trafics propres à chaque fonctionnalité. 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 d’approbation gérée mcp_servers pour restreindre les MCP servers.
• Utilisez des exigences de fonctionnalités telles que browser_use, in_app_browser et computer_use pour restreindre les fonctionnalités de navigation et d’utilisation de l’ordinateur.
• Pour les commandes Codex Cloud gérées prises en charge, configurez séparément les exigences Agent Security et les paramètres Internet de l’environnement Cloud.

Une liste de domaines autorisés pour les commandes ne remplace pas ces contrôles propres aux fonctionnalités.

Dans les modes d’exécution gérés pris en charge par Codex Cloud, les exigences Agent Security limitent l’accès réseau des commandes. Les paramètres Internet de l’environnement Codex Cloud s’appliquent séparément. Un domaine autorisé dans Agent Security ne lève pas une restriction définie dans les paramètres Internet de l’environnement Cloud. Ces contrôles réseau des commandes ne désactivent pas, à eux seuls, la recherche web hébergée, les applications ou MCP. ChatGPT Work Cloud dispose d’autorisations de fonctionnalités distinctes et n’hérite pas de ces exigences Agent Security.

Une liste d’autorisation gérée pour les commandes s’applique aux commandes qui utilisent le proxy géré. Lorsque la politique permet une élévation complète des privilèges hors de la sandbox et que celle-ci est approuvée, cette exécution peut contourner le proxy de commandes. Une autorisation réseau limitée diffère d’une élévation complète des privilèges hors de la sandbox. Configurez les exigences imposées en matière d’approbation et de sandbox en fonction du périmètre souhaité, et testez les commandes ordinaires ainsi que celles exécutées avec élévation des privilèges.

Aucune destination effectivement autorisée : Lorsque Mise en réseau gérée et Autoriser uniquement les domaines ajoutés par les administrateurs sont activés, les commandes gérées ordinaires ont besoin de destinations effectivement autorisées. Si aucune entrée d’autorisation n’est configurée ou héritée, ces commandes ne disposent d’aucune destination autorisée. Une politique composée uniquement de refus n’autorise pas implicitement le reste d’Internet. Ajoutez les entrées d’autorisation nécessaires et vérifiez les règles héritées avant d’enregistrer. Cette restriction s’applique au proxy des commandes gérées, et non à tous les outils ni aux élévations complètes approuvées hors du bac à sable.

Connectivité locale/privée de Codex Cloud : Une valeur Off explicite pour la connectivité locale/privée peut empêcher Codex Cloud d’atteindre son proxy en amont, même lorsque le domaine de destination est autorisé. Vérifiez la valeur finale de allow_local_binding et identifiez la politique ou le paramètre qui la fournit. Pour le chemin de proxy Cloud pris en charge, cette valeur est true par défaut uniquement lorsqu’aucune exigence applicable, aucun profil réseau sélectionné ni aucun paramètre de fonctionnalité du proxy ne fournit de valeur. Une valeur false héritée compte également comme un paramètre explicite. Lorsque cette possibilité est prise en charge, définissez une dérogation Cloud de priorité supérieure pour modifier cette valeur pour Codex Cloud sans changer la valeur Global utilisée par Local. Cela n’ajoute aucune entrée Allow pour les domaines. Vérifiez que l’exécuteur prend en charge cette dérogation avant de vous y fier. N’appliquez pas cette valeur par défaut de Cloud à Local.

Lorsque les exigences d’environnement sont vides, les exigences de Global s’appliquent. Le réglage de Mise en réseau gérée sur Désactivé est distinct du paramètre d’accès à Internet de l’environnement Cloud. Consultez Contrôles d’exécution de la sécurité des agents pour en savoir plus sur la portée d’exécution.

Priorité des politiques réseau et limites de l’environnement d’exécution

Au sein d’une même politique, l’ordre de priorité décroissant est le suivant : remplacement d’environnement propre au système d’exploitation → remplacement d’environnement pour tous les systèmes d’exploitation → Global. Une politique de priorité supérieure l’emporte toujours sur une politique de priorité inférieure, même lorsque cette dernière est plus spécifique. Certaines exigences suivent des règles de fusion propres à chaque champ. L’environnement d’exécution applique ensuite les exigences résultantes. Examinez les cas réseau propres à chaque champ ci-dessous séparément de la priorité des politiques.

Ces exemples comparent les paramètres d’environnement et de Global au sein d’une même politique, avec la mise en réseau gérée déjà configurée et sans qu’une politique de priorité supérieure modifie les valeurs. Ils décrivent la fusion propre à chaque champ et le 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, un remplacement d’environnement défini par un administrateur peut autoriser un domaine refusé dans Global ou refuser un domaine autorisé dans Global. Sans remplacement d’environnement, la règle de Global est héritée. D’autres règles de refus ou contrôles d’accès effectifs peuvent toujours bloquer une requête.

Combinaison des règles de domaine

Ces résultats comparent une même clé de domaine au sein d’une politique, sans qu’une politique de priorité supérieure modifie le résultat. Une valeur de priorité supérieure remplace la même clé. Les autres clés héritées sont conservées. Une autorisation ne contourne pas une autre règle de refus correspondante, telle qu’une règle générique héritée. Une table d’environnement vide n’efface pas les règles héritées.

Exemple : Refusez packages.example.com dans Global et autorisez-le dans Development. Development peut l’autoriser dans les conditions ci-dessus. Production hérite du refus de Global, sauf en cas de remplacement.

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 ordinaires reste à valider.

Limites d’Orchestrator. Les ports d’écoute HTTP/SOCKS gérés et les services d’écoute du proxy hors interface de bouclage ne sont pas pris en charge par l’environnement d’exécution cloud ; la prise en charge des règles de socket dépend du chemin d’exécution. Un paramètre d’exécution locale figurant dans le tableau ci-dessous ne constitue pas une configuration prise en charge par Orchestrator.

Autres limites réseau de l’environnement d’exécution

Tous les noms de champs ci-dessous se trouvent sous experimental_network dans requirements.toml. Les flèches indiquent une valeur de Global suivie d’une valeur d’environnement au sein d’une même politique. Ces cas d’exécution locale ne démontrent pas la prise en charge des mêmes paramètres par Orchestrator.

L’activation du proxy, l’exclusivité, le comportement du proxy en amont et les règles de socket Unix ont un comportement propre à chaque exécuteur. Ne généralisez pas la composition des clés de domaine à ces paramètres. Vérifiez les valeurs effectives et testez l’environnement d’exécution déployé. Pour la connectivité locale/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 réelles, les services en écoute locaux, le comportement du proxy et les chemins de socket utilisés par vos workflows. Vérifiez une action qui doit aboutir et une autre qui doit être bloquée dans chaque environnement concerné. Vérifiez que la version déployée de l’environnement d’exécution prend en charge chaque paramètre que vous utilisez.

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

Utilisez Modifier en TOML dans la 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 la mise en 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 associé à la valeur "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 des règles réseau des commandes et des règles d’origine du navigateur. Elle n’impose aucune restriction de destination aux modules natifs ni aux processus lancés, et ne régit pas l’exécution de Work Cloud.

Configurer les plugins et les hooks gérés

Pour ces tâches, utilisez Modifier en TOML dans la sécurité des agents ou une source de configuration locale prise en charge. Les valeurs par défaut des places de marché, les restrictions imposées aux plugins et les hooks gérés ont des objectifs différents ; choisissez la tâche correspondant à la politique dont vous avez besoin.

Configurer les places de marché de plugins et les valeurs par défaut

Utilisez Sécurité des agents > Modifier en TOML pour définir des places de marché 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 des places de marché et des plugins, sans imposer de politique. Pour limiter les sources que les membres peuvent utiliser, configurez les exigences relatives aux sources des places de marché.

Consultez la Référence de configuration pour les clés de configuration, Priorité des configurations pour les remplacements, et les paramètres des 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 en TOML dans la sécurité des agents pour imposer les paramètres des fonctionnalités de plugins dans le fichier requirements.toml de Global, ou distribuez-les au moyen d’exigences locales pour les clients gérés au niveau de l’appareil. Valeurs par défaut > Applications et outils > Applications/connecteurs définit les valeurs par défaut des outils des applications ; il ne s’agit pas du commutateur features.plugins imposé. Pour les autorisations des plugins de l’espace de travail, consultez Applications et connecteurs.

Pour désactiver les plugins dans les clients locaux pris en charge, 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 API key. Consultez la référence features.plugins pour connaître la configuration prise en charge.

Restreindre les sources des marketplaces de plugins

Utilisez Modifier en TOML pour configurer les exigences relatives aux sources de places de marché dans le fichier global requirements.toml, ou distribuez-les au moyen d’exigences locales. Ces règles limitent les sources locales ou Git que les utilisateurs peuvent ajouter et utiliser. Elles sont distinctes des paramètres par défaut de la place de marché.

Pour restreindre les sources des places de marché 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 établissent la correspondance avec l’URL normalisée du dépôt et, le cas échéant, un ref exact. Les motifs d’hôte sont des expressions régulières comparées à l’hôte Git en minuscules ; utilisez ^ et $ pour une correspondance avec l’hôte entier. Les règles locales nécessitent un chemin absolu normalisé. Consultez la référence requirements.toml pour connaître le schéma complet et le comportement de fusion.

Ces exigences rejettent les opérations d’ajout de places de marché, d’installation de plugins et d’actualisation de places de marché Git configurées dont la source ne correspond à aucune règle. Elles filtrent également les places de marché configurées et leurs plugins lors de l’exécution.

Les places de marché Git sélectionnées par OpenAI, y compris le catalogue API key, doivent également correspondre à la liste des sources autorisées. Pour les autoriser, ajoutez la source Git suivante sans contrainte ref :

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

Pour exclure les catalogues sélectionnés, omettez cette source et assurez-vous qu’aucune règle d’hôte plus large ne l’autorise. Les plugins intégrés et les plugins de l’espace de travail installés à distance sont indépendants de cette politique relative à la source Git des catalogues sélectionnés.

Ces restrictions de source s'appliquent uniquement lorsqu'un client local prend en charge les opérations de place de marché 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 les appareils mobiles, et elles n'ajoutent pas de plugins à l'extension IDE.

Imposer des hooks gérés au moyen des exigences

Les hooks gérés exécutent des actions définies par l’administrateur lors des événements de tâche ou d’outil pris en charge. Utilisez Modifier en TOML dans Agent Security pour les configurer dans le fichier global requirements.toml ; les paramètres ne proposent pas d’éditeur dédié aux hooks. Les modes d’exécution ci-dessous déterminent les types de hooks qui peuvent s’exécuter.

Lorsque la politique gérée et les hooks distants sont activés, Work Cloud avec accès local et dots utilisent des hooks MCP distants gérés par l’administrateur sur l’orchestrateur cloud. Configurez les gestionnaires mcp_tool dans le fichier global requirements.toml. Work Cloud sans accès local et les comptes personnels n’utilisent pas ces hooks d’entreprise. Les gestionnaires de commande/shell, de prompt et d’agent ; les hooks provenant de la configuration locale, de plugins ou de répertoires locaux ; les hooks propres à un environnement ; et les hooks MCP SessionEnd ne sont pas pris en charge avec l’orchestration cloud, même lorsque les outils s’exécutent localement. Lorsque l’orchestration et l’exécution sont toutes deux locales, les hooks existants pris en charge continuent de fonctionner dans les fils Work et Codex entièrement locaux. Les administrateurs peuvent toujours configurer les hooks gérés pris en charge dans Agent Security pour ces workflows.

Avant de vous appuyer sur ces hooks, testez la connectivité des rappels, les événements requis et le comportement en cas d’échec. Un refus explicite pris en charge peut bloquer une action, mais une erreur de rappel PreToolUse, un délai d’attente dépassé ou une réponse mal formée peuvent faire échouer le hook sans bloquer l’outil. Les hooks MCP ne fournissent pas de piste d’audit complète via la Compliance API. Les exemples de scripts et de répertoires qui suivent restent propres à Codex.

Les administrateurs peuvent également définir des hooks de cycle de vie gérés directement dans requirements.toml. Utilisez [hooks] pour la configuration du hook lui-même et faites pointer managed_dir vers le répertoire dans lequel votre MDM ou vos outils de gestion des terminaux installent les scripts référencés.

Pour imposer les hooks gérés même aux utilisateurs qui ont désactivé les hooks localement, fixez [features].hooks = true en plus de [hooks]. Pour ignorer les hooks utilisateur, de projet, de session et de plugin tout en autorisant les hooks gérés, définissez allow_managed_hooks_only = true.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

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

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

Remarques :

• L’environnement d’exécution local applique la configuration des hooks provenant de requirements.toml, mais ne distribue pas les scripts présents dans managed_dir.
• Distribuez ces scripts avec votre MDM ou votre solution de gestion des appareils.
• Les commandes des hooks gérés doivent référencer des chemins de scripts absolus dans le répertoire géré configuré.
• allow_managed_hooks_only = true ignore les hooks provenant des sources utilisateur, de projet, de session et de plugin, mais charge toujours les hooks provenant de requirements.toml et des autres couches de configuration gérées.

Comprendre la portée et la priorité des politiques

Cette section vous permet de vérifier 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 dots, la politique Global prise en charge régit 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 Work conservent les politiques Work Cloud existantes, et les contrôles des appareils pris en charge continuent de s’appliquer à l’exécution locale. Codex conserve son comportement de configuration existant. La configuration gérée n’accorde ni place dans un espace de travail ni accès aux fonctionnalités. Consultez Rôles et autorisations de l’espace de travail pour ces contrôles.

Agent Security et accès à l’ordinateur local avec Work Cloud

Utilisez Agent Security dans la console d’administration pour gérer les politiques et la configuration. Cette interface remplace Politiques et configuration. Agent Security est disponible dans la console d’administration, indépendamment de l’accès à l’ordinateur local avec Work Cloud. Les politiques, les affectations et leur ordre existants sont conservés. Examinez vos politiques existantes dans Agent Security. L’accès à l’ordinateur local avec Work Cloud nécessite une activation distincte. Consultez Agent Security pour obtenir des conseils sur la migration.

Avant de migrer l’automatisation des politiques vers Agent Security :

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

2. Utilisez l’API des politiques pour gérer les paramètres Global. Pour gérer les paramètres Local ou Codex Cloud, utilisez l’interface Agent Security. Les workflows existants utilisant l’API pour Global restent disponibles après la migration. Testez vos scripts et vos intégrations Terraform, et vérifiez que les affectations des politiques et leur ordre n’ont pas changé.

3. Apportez les modifications nécessaires et testez l’automatisation. Vérifiez qu’une mise à jour prévue atteint la bonne politique Agent Security et que les contrôles qui en résultent sont appliqués.

La migration des politiques n’accorde pas l’accès à l’ordinateur local pour Work ou dots. Il est recommandé d’examiner ou de créer des politiques avant le déploiement, mais le processus 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, examinez 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 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 ou dots.

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

Lorsque la politique gérée et les hooks distants sont activés, Work Cloud avec accès local et dots utilisent des hooks MCP distants gérés par l’administrateur sur l’orchestrateur cloud. Configurez les gestionnaires mcp_tool dans le fichier global requirements.toml. Work Cloud sans accès local et les comptes personnels n’utilisent pas ces hooks d’entreprise. Les gestionnaires de commande/shell, de prompt et d’agent ; les hooks provenant de la configuration locale, de plugins ou de répertoires locaux ; les hooks propres à un environnement ; et les hooks MCP SessionEnd ne sont pas pris en charge avec l’orchestration cloud, même lorsque les outils s’exécutent localement. Lorsque l’orchestration et l’exécution sont toutes deux locales, les hooks existants pris en charge continuent de fonctionner dans les fils Work et Codex entièrement locaux. Les administrateurs peuvent toujours configurer les hooks gérés pris en charge dans Agent Security pour ces workflows. Avant de vous appuyer sur ces hooks, testez la connectivité des rappels, les événements requis et le comportement en cas d’échec. Un refus explicite pris en charge peut bloquer une action, mais une erreur de rappel PreToolUse, un délai d’attente dépassé ou une réponse mal formée peuvent faire échouer le hook sans bloquer l’outil. Les hooks MCP ne fournissent pas de piste d’audit complète via la Compliance API. Consultez la Référence de configuration.

Emplacements et priorité

Pour l’exécution locale, les exigences sont appliquées par ordre de priorité croissant comme suit. Cet ordre s’applique également aux étapes locales de l’accès à l’ordinateur local avec Work Cloud :

1. Fichier système requirements.toml (/etc/codex/requirements.toml sur les systèmes Unix, y compris Linux et macOS, ou %ProgramData%\OpenAI\Codex\requirements.toml sur Windows).
2. Exigences Agent Security 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 inférieures. Les tables fusionnent par clé, tandis que les exigences telles que les règles, les hooks et les restrictions du système de fichiers ont un comportement de composition propre à chaque champ. Consultez la référence de requirements.toml pour connaître le schéma actuel, plutôt que de supposer que tous les champs fusionnent de la même manière.

Pour assurer la rétrocompatibilité, les clients locaux pris en charge réinterprètent les anciens champs approval_policy, approvals_reviewer et sandbox_mode comme des exigences. Cette conversion ajoute des choix de compatibilité lorsque cela est nécessaire ; utilisez requirements.toml pour définir des listes d’autorisation explicites.

Priorité pour l’accès à l’ordinateur local avec Work Cloud

Pour Work avec accès local et dots, distinguez la politique Global de l’orchestrateur de la politique d’exécution. Les exigences locales applicables régissent l’ordinateur connecté. Les conteneurs cloud Work et les ordinateurs cloud dots utilisent leur propre configuration et leurs propres exigences d’exécution, plutôt que le 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 au niveau de l’appareil sont prioritaires sur Agent Security. Le fichier d’exigences système de l’appareil a une priorité inférieure à celle d’Agent Security. Au sein de chaque politique, appliquez d’abord les substitutions d’environnement propres au système d’exploitation, puis celles communes à tous les systèmes d’exploitation, puis Global. Entre les politiques, la priorité l’emporte sur la spécificité.

Les exigences imposent des contraintes, tandis que les valeurs de configuration par défaut fournissent les valeurs initiales. Pour Work avec accès local et dots, la politique Global prise en charge s’applique par l’intermédiaire de 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 un ordinateur connecté. Les conteneurs cloud de Work et les ordinateurs cloud de dots utilisent leur propre configuration et leurs propres exigences d’exécution, plutôt que l’ensemble d’environnement géré utilisé par les autres types d’exécuteurs. Les restrictions d’exécution locales ne s’appliquent pas automatiquement à ces ordinateurs cloud. Examinez 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, y compris les approbations et la recherche web, dans Global. Utilisez les contrôles dédiés Politiques d’approbation autorisées et Modes de recherche web autorisés lorsqu’ils 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 prise en charge, les clients locaux pris en charge peuvent recevoir des exigences imposées par l’administrateur et associées à l’espace de travail. Il s’agit d’un canal de distribution de politiques compatibles avec requirements.toml. Il n’accorde pas d’accès à l’espace de travail et ne remplace pas son contrôle d’accès basé sur les rôles (RBAC). Les exigences d’authentification doivent être gérées localement.

Configurez les exigences courantes avec les contrôles de sécurité des agents. Pour une politique qui autorise uniquement les approbations on-request et les bacs à sable read-only ou workspace-write, utilisez Politiques d’approbation et Modes de bac à sable sous Garde-fous des politiques. Pour demander également une approbation avant l’exécution d’un point d’entrée shell pris en charge, utilisez Modifier en TOML pour ajouter la table [rules] au fichier Global requirements.toml.

L’équivalent TOML complet est le suivant :

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 de client géré prend en charge les clés que vous sélectionnez. Attribuez la politique aux utilisateurs ou groupes concernés et vérifiez qu’elle prend effet dans leurs clients pris en charge. Consultez la référence de configuration pour connaître le schéma actuel et l’interface d’administration pour connaître le comportement actuel des attributions.

Le service sélectionne les couches d’exigences gérées par l’entreprise qui s’appliquent à l’identité connectée. Le client local évalue ces couches avec les autres sources d’exigences décrites dans Emplacements et ordre de priorité. Utilisez l’interface d’administration actuelle pour la création et l’attribution au niveau de l’espace de travail. Ne vous fiez pas à une copie d’un algorithme de correspondance des groupes ; le service d’administration contrôle ce comportement et peut le modifier indépendamment du format local des exigences.

Pour connaître les clés prises en charge et consulter des exemples, reportez-vous à Exemple de requirements.toml et à la référence de requirements.toml.

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

Le comportement de chargement local et de mise en cache décrit ci-dessous concerne les clients locaux pris en charge. Il ne précise pas à quel moment une politique cloud modifiée prend effet dans une tâche déjà en cours qui utilise l’accès à l’ordinateur local avec Work Cloud. Vérifiez la politique effective avant de vous appuyer sur une restriction modifiée.

Lorsqu’un utilisateur lance un client local pris en charge et se connecte avec ChatGPT dans le cadre d’une offre prise en charge, le client recherche d’abord une entrée de cache valide correspondant à son identité. Si aucune entrée valide n’est disponible, le client récupère l’ensemble applicable avec des tentatives supplémentaires et écrit une entrée de cache signée en cas de succès. Si la requête échoue ou expire et qu’aucun cache valide n’est disponible, le chargement de l’ensemble de configuration cloud renvoie une erreur au lieu de démarrer silencieusement sans la couche d’exigences gérées dans le cloud.

Une fois le cache résolu, le client combine les exigences cloud avec les autres couches d’exigences décrites ci-dessus. Une actualisation en arrière-plan met à jour l’ensemble mis en cache et le rend disponible pour les chargements de configuration suivants. Cela ne garantit pas qu’une tâche déjà en cours utilise immédiatement une politique modifiée. Certains paramètres de l’application de bureau nécessitent un redémarrage ; suivez toute invite de redémarrage et vérifiez les paramètres effectifs avant de vous appuyer sur la modification.

Vérifier l’expérience des administrateurs et des employés

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

Testez un flux de travail autorisé et un flux de travail bloqué avec un utilisateur disposant des autorisations prévues. Vérifiez les paramètres effectifs dans le client pris en charge. Un rôle ou un groupe d’espace de travail ne suffit pas à lui seul à imposer une restriction d’exécution locale.

Utilisez Tester les politiques dans Agent security pour vérifier quelles politiques correspondent à une sélection de membre, de groupe ou de rôle. Dans une session modifiable, cette fonction vérifie le brouillon actuel sans l’enregistrer. Le résultat indique les politiques sélectionnées, et non la configuration finale fusionnée ni si un client applique une restriction. Après l’enregistrement, testez les flux de travail autorisés et bloqués sur chaque client et chaque mode d’exécution concernés.

Déployer une configuration gérée au niveau de l’appareil

Utilisez les exigences système locales ou MDM pour les restrictions d’authentification et les politiques gérées au niveau de l’appareil. L’ancien mécanisme managed_config.toml suit un ordre de priorité au démarrage différent de celui des Valeurs par défaut d’Agent security. Le flux de travail 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 système local requirements.toml 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 ne récupère la politique cloud.

Pour exiger une connexion ChatGPT à un espace de travail approuvé et stocker les identifiants dans le gestionnaire d’identifiants du système d’exploitation, utilisez :

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 ce paramètre est omis, il ne restreint pas les méthodes de connexion. S’il est défini, la liste doit contenir au moins une méthode. api autorise l’authentification par API, y compris via Amazon Bedrock. La restriction liée à l’espace de travail s’applique également 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. Lorsqu’un utilisateur sélectionne un espace de travail, celui-ci doit également figurer dans la liste gérée des espaces de travail autorisés. Si aucun espace de travail ne correspond, la connexion ChatGPT est indisponible. L’authentification par API reste disponible lorsqu’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 connaître les modes de stockage des identifiants et la configuration de l’URL du service.

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

Utilisez les Valeurs par défaut d’Agent security pour les valeurs initiales prises en charge gérées dans le cloud. Cette section couvre l’ancien mécanisme géré au niveau de l’appareil managed_config.toml et son ordre de priorité différent au démarrage. La modification des Valeurs par défaut dans Agent security 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 avec laquelle démarre un client local pris en charge. Au démarrage, elles remplacent le fichier local config.toml de l’utilisateur et toute substitution CLI --config. Les utilisateurs peuvent toujours modifier ces paramètres pendant l’exécution en cours, et les valeurs par défaut s’appliquent de nouveau au prochain démarrage du client.

GPT-5.5 est retiré de Codex avec une connexion via 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 pour 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’OpenAI API et les sessions Codex authentifiées avec une API key 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 conseils de migration de GPT-5.4.

Assurez-vous que vos valeurs par défaut gérées respectent vos exigences ; l’environnement d’exécution local rejette les valeurs interdites.

Ordre de priorité et superposition des couches

L’environnement d’exécution local assemble la configuration effective dans l’ordre suivant (les éléments du haut remplacent ceux du bas) :

• 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 remplacements CLI --config key=value s’appliquent à la base, mais les couches gérées les remplacent. Chaque exécution commence donc avec les valeurs par défaut gérées, même si vous fournissez des indicateurs locaux.

Le fichier config.toml du cloud utilise l’ordre de priorité normal de la configuration, et non l’ancien ordre ci-dessus. Le fichier requirements.toml du cloud utilise l’ordre de priorité des exigences.

Emplacements

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

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

Exemple de 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"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

Garde-fous recommandés

• Privilégiez workspace-write avec des approbations pour la plupart des utilisateurs ; réservez l’accès complet aux conteneurs contrôlés.
• Conservez network_access = false sauf si votre examen de sécurité autorise un collecteur ou les domaines nécessaires à vos workflows.
• Utilisez la configuration gérée pour fixer les paramètres OTel (exportateur, environnement), mais conservez log_user_prompt = false sauf si votre politique autorise explicitement le stockage du contenu des prompts.
• Auditez régulièrement les différences entre le fichier local config.toml et la politique gérée pour détecter les écarts ; les couches gérées doivent prévaloir sur les options et fichiers locaux.

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

Sous macOS, les administrateurs peuvent déployer un profil d’appareil fournissant des charges utiles TOML encodées en base64 à l’emplacement suivant :

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

L’environnement d’exécution local interprète ces charges utiles de « 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] côté exigences fonctionne dans requirements_toml_base64 ; utilisez également les clés canoniques des fonctionnalités à cet endroit.

Procédure de configuration MDM

L’environnement d’exécution local prend en charge les charges utiles MDM macOS standard. Vous pouvez donc distribuer les paramètres avec des outils comme Jamf Pro, Fleet ou Kandji. Un déploiement simple se déroule comme suit :

1. Créez la charge utile TOML gérée et encodez-la avec base64 (sans retour à la ligne).
2. Insérez la chaîne dans votre profil MDM sous le domaine com.openai.codex, à la clé config_toml_base64 (valeurs par défaut gérées) ou requirements_toml_base64 (exigences).
3. Déployez le profil, puis demandez aux utilisateurs de redémarrer le client local pris en charge et de vérifier que le résumé de la configuration au démarrage reflète les valeurs gérées.
4. Lorsque vous révoquez ou modifiez une politique, mettez à jour la charge utile gérée ; le client lit la préférence actualisée à son prochain lancement.

Évitez d’intégrer des secrets ou des valeurs dynamiques changeant fréquemment dans la charge utile. Soumettez le TOML géré au même contrôle des modifications que tout autre paramètre MDM.