Configuration gérée

La configuration gérée contrôle le comportement pris en charge par l’environnement d’exécution local pour les fonctionnalités concernées dans l’application de bureau ChatGPT, Codex CLI et l’extension IDE. Les exigences prises en charge peuvent varier selon le client et sa version. La configuration gérée n’accorde pas l’accès à un espace de travail ChatGPT, n’attribue pas de licences et ne remplace pas le contrôle d’accès basé sur les rôles (RBAC) de l’espace de travail. Consultez Rôles et autorisations de l’espace de travail pour l’accès aux fonctionnalités de l’espace de travail, et cette page pour la politique de l’environnement d’exécution local.

Les administrateurs d’entreprise peuvent contrôler le comportement des clients locaux compatibles à l’aide des éléments suivants :

• Exigences : contraintes imposées par les administrateurs auxquelles les utilisateurs ne peuvent pas déroger.
• Paramètres 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 remplacer.
• Anciens paramètres gérés par défaut : valeurs initiales de managed_config.toml appliquées au lancement d’un client compatible. Les utilisateurs peuvent toujours modifier les paramètres en cours d’exécution ; le client réapplique ces valeurs par défaut au démarrage suivant.

Configurez les marketplaces et les paramètres par défaut des plugins

Définissez des marketplaces locales ou Git et les paramètres par défaut des plugins dans le fichier config.toml du système ou dans la section config.toml de Configuration gérée. Ces paramètres sont des valeurs par défaut, et non une politique imposée.

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 gérées séparément.

Exigences imposées par les administrateurs (requirements.toml)

Les exigences encadrent les paramètres sensibles pour la sécurité (politique d’approbation, responsable de la révision des approbations, politique de révision automatique, mode du 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). Lors de la résolution de la configuration, par exemple à partir de config.toml, de fichiers de profils ou de paramètres de remplacement de 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 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 également encadrer les indicateurs de fonctionnalité via la table [features] de requirements.toml. Les fonctionnalités ne sont pas toujours sensibles pour la sécurité, mais les entreprises peuvent en imposer les 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’autorisations avec allowed_permission_profiles et le paramètre géré default_permissions. Utilisez allowed_sandbox_modes uniquement pour les anciens déploiements 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.

Migrez depuis la politique d’approbation untrusted, désormais retirée

Codex et ChatGPT Work ne prennent plus en charge approval_policy = "untrusted". Supprimez ce paramètre des valeurs gérées par défaut, 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 commandes plus strictes, ne définissez pas explicitement 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 Migrez depuis la politique d’approbation untrusted, désormais retirée pour des exemples et les compromis en matière de sécurité.

Emplacements et ordre de priorité

Chaque client local compatible combine les exigences dans l’ordre de priorité croissant suivant :

1. Fichier requirements.toml du système (/etc/codex/requirements.toml sur les systèmes Unix, dont Linux et macOS, ou %ProgramData%\OpenAI\Codex\requirements.toml sur Windows).
2. Exigences gérées par l’entreprise et transmises dans le paquet de configuration cloud.
3. Anciens champs de managed_config.toml que le client local réinterprète comme des exigences.
4. Préférences gérées de macOS (MDM) transmises 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é, tandis que les exigences telles que 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 façon.

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 des options de compatibilité si nécessaire ; utilisez requirements.toml pour définir des listes d’autorisation explicites.

Exigences gérées dans le cloud

Lorsqu’un utilisateur se connecte avec ChatGPT dans le cadre d’une offre compatible, les clients locaux compatibles peuvent recevoir les exigences imposées par les administrateurs 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 l’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.

Ouvrez Configuration gérée pour créer et attribuer des exigences gérées dans le cloud. Par exemple, cette politique limite les choix d’approbation et de bac à sable, et demande une approbation avant l’exécution d’un point d’entrée shell pris en charge :

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 choisies, et testez la politique auprès d’un petit groupe avant de l’attribuer à toute l’organisation. Consultez la référence de configuration pour connaître le schéma actuel et l’interface d’administration pour connaître le fonctionnement 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 créer et attribuer les exigences dans l’espace de travail. Ne vous fiez pas à une copie de l’algorithme de correspondance des groupes : le service d’administration gère ce comportement et peut le modifier indépendamment du format des exigences locales.

Pour les clés prises en charge et des exemples, consultez 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

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é. Si aucune entrée valide n’est disponible, le client récupère le paquet applicable, avec de nouvelles tentatives si nécessaire, puis écrit une entrée de cache signée en cas de réussite. Si la requête échoue ou expire et qu’aucun cache valide n’est disponible, le chargement du paquet de configuration cloud renvoie une erreur au lieu de démarrer sans avertissement en l’absence de la couche d’exigences gérées dans le cloud.

Une fois le cache résolu, le client combine les exigences du cloud avec les autres couches d’exigences décrites ci-dessus. Une actualisation en arrière-plan peut mettre à jour le cache pour un démarrage ultérieur ; elle ne remplace pas les exigences déjà chargées dans le processus en cours.

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

Désignez une personne responsable de chaque politique gérée, consignez les utilisateurs ou groupes auxquels elle doit être attribuée, et documentez la justification métier de toute restriction concernant le système de fichiers, le réseau, les approbations ou les profils d’autorisations.

Avant d’étendre le déploiement, testez un workflow approuvé et un workflow volontairement interdit avec un utilisateur représentatif. Vérifiez les paramètres effectifs dans le client compatible, sans supposer qu’un rôle ou un groupe de l’espace de travail suffit à imposer la restriction locale.

Gérez 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 récupère la politique du cloud.

Pour imposer la connexion via 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. S’il est omis, ce paramètre 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 avec Amazon Bedrock. La restriction d’espace de travail s’applique également aux jetons d’accès Codex.

Les paramètres forced_login_method et forced_chatgpt_workspace_id définis 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 via 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 les modes de stockage des identifiants et la configuration de l’URL du service.

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.

Désactivez les captures d’application

Pour désactiver les captures d’application pour les utilisateurs gérés, définissez l’exigence allow_appshots à la racine de la configuration :

allow_appshots = false

Lorsque les captures d’application sont disponibles, allow_appshots = false les désactive. Si vous omettez cette clé, les exigences ne restreignent pas les captures d’application 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 dans allowAppshots ; une valeur allowAppshots omise ou définie sur null ne désactive pas les captures d’application.

Désactivez le contrôle à distance des appareils

Pour désactiver le contrôle à distance des appareils pour les utilisateurs gérés, définissez l’exigence allow_remote_control à la racine de la configuration :

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 distantes SSH.

Contrôlez les profils d’autorisations disponibles

Utilisez allowed_permission_profiles pour contrôler quels profils d’autorisations intégrés et personnalisés les utilisateurs peuvent sélectionner. Il s’agit de l’équivalent de allowed_sandbox_modes pour les profils d’autorisations ; utilisez la liste d’autorisation qui correspond à la façon dont vos utilisateurs sélectionnent leurs autorisations.

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 que lorsque tous les clients gérés exécutent 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 interdit ceux qui sont omis ou définis sur false, y compris les profils intégrés ajoutés dans les futures versions de Codex.

Autorisez les profils standard

Cette politique autorise l’accès en lecture seule et l’accès à 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.

Ajoutez un profil géré par défaut respectant 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 les noms présents dans 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 du profil, mais pas le paramètre géré par défaut qui le sélectionne.

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"

Autorisez 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 les administrateurs :

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ésactivez un profil autorisé par une autre source

Les listes d’autorisations se combinent par nom de profil. Les exigences du cloud étant prioritaires sur les exigences système, elles peuvent utiliser false pour désactiver un profil autorisé par le fichier système.

Exigences du 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 ce paramètre est omis, l’environnement d’exécution local utilise :workspace par défaut uniquement si :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 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 manière centralisée.

Redéfinissez les exigences du bac à sable par hôte

Utilisez [[remote_sandbox_config]] lorsqu’une même politique gérée doit appliquer différentes exigences de bac à sable selon les hôtes. Vous pouvez, par exemple, conserver des paramètres par défaut plus stricts pour les ordinateurs portables tout en autorisant les écritures dans l’espace de travail sur les machines de développement ou les exécuteurs CI correspondants. Pour le moment, les entrées propres à un hôte redéfinissent 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"]

L’environnement d’exécution local compare chaque entrée hostname_patterns au nom d’hôte qu’il a pu résoudre au mieux. Il privilégie le nom de domaine pleinement qualifié lorsqu’il est disponible et utilise sinon le nom d’hôte local. La correspondance ne tient pas compte de 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 l’emporte au sein d’une même source d’exigences. Si aucune entrée ne correspond, l’environnement d’exécution local conserve le paramètre allowed_sandbox_modes de premier niveau. La correspondance du nom d’hôte sert uniquement à sélectionner la politique ; ne la considérez pas comme une preuve d’authentification de l’appareil.

Vous pouvez également restreindre le mode de recherche web :

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.

Configurez les exigences d’accès réseau

Utilisez [experimental_network] dans requirements.toml lorsque les administrateurs doivent définir les exigences d’accès réseau de manière centralisée. Ces exigences sont indépendantes du paramètre utilisateur features.network_proxy : elles permettent de configurer le réseau du bac à sable sans cet indicateur de fonctionnalité, mais n’accordent pas aux commandes un accès réseau lorsque le bac à sable actif maintient le réseau désactivé. Définissez experimental_network.enabled = true pour activer le proxy géré ; les règles de domaine ne suffisent pas à elles seules à activer 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" contrôlées par les administrateurs dans [experimental_network.domains] et souhaitez que seules ces règles s’appliquent. Si ce paramètre vaut true sans règles d’autorisation gérées, les règles d’autorisation de domaines ajoutées par les utilisateurs cessent de s’appliquer. Ne combinez pas la table de correspondance 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 au DNS rebinding suivent les mêmes principes que le réseau du bac à sable, décrits dans Autorisations de l’agent et sécurité.

Le proxy achemine le trafic des commandes locales exécutées dans le bac à sable. Les outils de navigation vérifient également les refus réseau gérés et les listes exclusives d’autorisations avant d’accéder à une origine ; il s’agit d’une vérification distincte de la politique, et non d’un acheminement du trafic du navigateur via le proxy des commandes. Ce proxy ne filtre ni la recherche web, ni les applications et les connecteurs, ni les serveurs MCP, ni le trafic des applications natives, ni les requêtes au service Codex, ni le trafic de Codex Cloud. Utilisez les contrôles propres à 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’autorisations gérée mcp_servers pour restreindre les serveurs MCP.
• Utilisez des exigences de fonctionnalités telles que browser_use, in_app_browser et computer_use pour restreindre les capacités de navigation et d’utilisation de l’ordinateur.
• Configurez l’accès réseau de Codex Cloud dans les paramètres de son environnement cloud.

Une liste de domaines autorisés pour les commandes ne remplace pas ces contrôles propres à chaque capacité.

Contrôlez le navigateur et l’Utilisation de l’ordinateur

Utilisez les tables [browser_use] et [computer_use] dans requirements.toml pour restreindre les clients de bureau pris en charge. Validez la politique sur les versions des clients et les systèmes d’exploitation de votre déploiement. Configurer une règle d’autorisation n’installe pas de plugin, n’accorde pas d’autorisation du système d’exploitation et n’approuve pas une action qui nécessite encore une révision.

Pour l’accès au navigateur, configurez une politique d’origine. Une origine comprend le schéma, l’hôte et un port facultatif, par exemple https://example.com ou https://*.example.com:8443. N’incluez ni chemin, ni chaîne de requête, ni fragment. Contrairement aux règles de domaine régissant l’accès réseau des commandes, les règles d’origine du navigateur distinguent HTTP de HTTPS et vérifient la correspondance du port.

Cet exemple limite l’accès du navigateur à un site approuvé et y empêche l’envoi de fichiers ainsi que l’accès complet au Chrome DevTools Protocol (CDP) :

[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"

Les règles d’origine correspondantes sont résolues champ par champ. Un refus correspondant l’emporte ; sinon, la politique d’origine par défaut fournit les valeurs des champs non précisés par les règles correspondantes. La configuration locale peut ajouter des restrictions, mais ne peut pas assouplir un refus géré. Les refus réseau et les listes exclusives d’autorisations réseau gérées continuent de s’appliquer.

Définissez browser_use.disable_auto_review = true pour désactiver la révision automatique des approbations pour les actions du navigateur, ou définissez auto_review = "deny" dans une politique d’origine pour la désactiver pour cette origine. Ce paramètre contrôle le traitement des approbations ; il ne désactive pas la surveillance de la sécurité du modèle.

Pour les applications natives, définissez une politique d’accès par défaut et identifiez les applications autorisées. Par exemple, cette politique macOS autorise Calculator et empêche l’enregistrement des approbations :

[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. Utilisez l’identité vérifiée de l’application plutôt que son seul nom d’affichage.

Consultez la référence de configuration pour connaître tous les champs, ainsi que les restrictions d’utilisation lorsque l’ordinateur est verrouillé pour les appareils macOS gérés.

Fixez les indicateurs de fonctionnalités

Vous pouvez également fixer les indicateurs de fonctionnalités pour les utilisateurs qui reçoivent un fichier requirements.toml géré :

[features]
personality = 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 de fonctionnalité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és du fichier de profil.

• in_app_browser = false désactive le volet du navigateur intégré.
• in_app_updates = false désactive, au redémarrage, le programme de mise à jour propre à l’application de bureau ChatGPT 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 des conseils de configuration et de déploiement, consultez Gestion des mises à jour de l’application.
• browser_use = false désactive l’Utilisation de l’ordinateur dans les navigateurs et rend l’agent de navigation indisponible.
• browser_use_full_cdp_access = false désactive l’accès complet au CDP 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 la fonctionnalité Navigateur externe.
• computer_use = false désactive l’Utilisation de l’ordinateur, Enregistrer et rejouer, ainsi que les parcours d’installation ou de configuration associés.

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.

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

Pour empêcher les utilisateurs d’activer l’utilisation lorsque l’ordinateur est verrouillé sur un Mac géré, ajoutez cette exigence :

[computer_use]
allow_locked_computer_use = false

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

Configurez la politique de révision automatique

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

Définissez guardian_policy_config pour remplacer la section propre au tenant dans la politique de révision automatique. L’environnement d’exécution local continue d’utiliser le modèle intégré du réviseur 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.
"""

Imposez des exigences de refus de lecture

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 au moyen de 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’exigences de refus de lecture, l’environnement d’exécution local rejette 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 afin de pouvoir les appliquer. En exécution native sur Windows, le paramètre géré deny_read s’applique aux outils d’accès direct aux fichiers ; les lectures effectuées par les sous-processus du shell n’utilisent pas cette règle du bac à sable.

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

Les administrateurs peuvent également définir des hooks de cycle de vie gérés directement dans requirements.toml. Utilisez [hooks] pour la configuration des hooks eux-mêmes et faites pointer managed_dir vers le répertoire où votre MDM ou votre outil de gestion des terminaux installe 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 complément de [hooks]. Pour ignorer les hooks des utilisateurs, des projets, des sessions et des plugins 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 impose la configuration des hooks définie dans 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 utiliser des chemins absolus vers les scripts situés dans le répertoire géré configuré.
• allow_managed_hooks_only = true ignore les hooks provenant des utilisateurs, des projets, des sessions et des plugins, mais continue de charger ceux de requirements.toml et des autres couches de configuration gérées.

Imposez des règles de commande dans les exigences

Les administrateurs peuvent aussi imposer des règles de commande restrictives dans requirements.toml à l’aide d’une table [rules]. Ces règles sont fusionnées avec celles des fichiers .rules habituels, et la décision la plus restrictive reste prioritaire.

Contrairement aux règles .rules, les règles définies dans les 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 limiter les serveurs MCP qu’un client local peut activer, ajoutez une liste de serveurs autorisés mcp_servers. Pour les serveurs stdio, utilisez command comme critère de correspondance ; pour les serveurs HTTP en streaming, utilisez url :

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

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

La forme chaîne de caractères de identity.command vérifie uniquement la correspondance avec la valeur configurée de command. Elle n’examine ni args, ni cwd, ni env, ni env_vars.

Pour encadrer un appel stdio complet, définissez des critères de correspondance pour 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 portant sur les arguments et les URL prennent en charge les correspondances exact et prefix, ainsi que la correspondance regex sur la valeur entière. Les règles de commande structurées n’examinent pas non plus cwd, env ou env_vars. Les serveurs MCP 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 serveurs MCP.

Contrôlez la disponibilité des plugins

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.

Limitez les sources des marketplaces de plugins

Pour limiter 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 la correspondance avec l’URL normalisée du dépôt et, lorsqu’elle est présente, la valeur exacte de ref. Les motifs d’hôte sont des expressions régulières appliquées au nom d’hôte Git en minuscules ; utilisez ^ et $ pour une correspondance 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 connaître le schéma complet et le comportement de fusion.

Ces exigences rejettent les opérations d’ajout de marketplace, d’installation de plugin et d’actualisation des marketplaces Git configurées qui ne correspondent pas aux règles. 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 destiné aux utilisateurs de clés API, doivent également correspondre à la liste des sources autorisées. Pour les autoriser, ajoutez la source Git suivante sans contrainte sur 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 vérifiez qu’aucune règle d’hôte plus large ne l’autorise. Les plugins intégrés et les plugins d’espace de travail installés à distance ne relèvent pas de cette politique sur les sources Git sélectionnées.

Ces restrictions de source s’appliquent uniquement lorsque le client local prend 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 pas de plugins à l’extension IDE.

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

Les valeurs par défaut gérées définissent la configuration initiale d’un client local compatible. Au démarrage, elles prévalent sur le fichier config.toml local de l’utilisateur et sur les valeurs définies dans la CLI avec --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.

Si une valeur par défaut gérée, un profil MDM macOS ou une configuration enregistrée impose gpt-5.5 aux utilisateurs de Codex connectés avec ChatGPT, remplacez ce modèle par gpt-5.6-sol avant le 14 octobre 2026. À cette date, GPT-5.5 sera retiré de ChatGPT, ChatGPT Work et Codex pour tous les forfaits. L’API OpenAI n’est pas concernée. Consultez la page sur la disponibilité des modèles dans l’espace de travail.

Si une valeur par défaut gérée, un profil MDM macOS ou une configuration enregistrée impose gpt-5.4 ou gpt-5.4-mini aux utilisateurs connectés avec ChatGPT, mettez à jour ce paramètre avant le 31 août 2026. Remplacez gpt-5.4 par gpt-5.6-terra et gpt-5.4-mini par gpt-5.6-luna. L’API OpenAI et Codex authentifié avec votre propre clé API ne sont pas concernés. Consultez la page sur la disponibilité des modèles dans l’espace de travail.

Vérifiez que vos valeurs par défaut gérées respectent vos exigences ; l’environnement d’exécution local rejette les valeurs non autorisées.

Priorité et superposition des couches

L’environnement d’exécution local construit la configuration effective selon l’ordre suivant (les éléments du haut prévalent sur ceux du bas) :

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

Les valeurs définies dans la CLI avec --config key=value prévalent sur la configuration de base, mais les couches gérées restent prioritaires. Ainsi, chaque exécution démarre avec les valeurs par défaut gérées, même si vous fournissez des options locales.

Le fichier config.toml géré dans le cloud suit l’ordre de priorité normal de la configuration, et non l’ancien ordre décrit ci-dessus. Le fichier requirements.toml géré dans le cloud suit 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.

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

Sur macOS, les administrateurs peuvent déployer un profil d’appareil qui fournit 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)

L’environnement d’exécution local analyse ces données de « préférences gérées » au format 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 gérées dans le cloud décrit ci-dessus. La même table [features] des exigences fonctionne dans requirements_toml_base64 ; utilisez là aussi les clés de fonctionnalité canoniques.

Workflow de configuration MDM

L’environnement d’exécution local prend en charge les données de configuration MDM standard de macOS. Vous pouvez donc distribuer les paramètres avec des outils comme Jamf Pro, Fleet ou Kandji. Voici une procédure de déploiement simple :

1. Préparez les données de configuration gérée au format TOML et encodez-les avec base64 (sans retours à la ligne).
2. Insérez la chaîne dans votre profil MDM, sous le domaine com.openai.codex, dans 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 compatible et de vérifier que le récapitulatif de configuration au démarrage reflète les valeurs gérées.
4. Lorsque vous révoquez ou modifiez une politique, mettez à jour les données de configuration gérée ; le client lira la préférence actualisée à son prochain démarrage.

Évitez d’intégrer des secrets ou des valeurs dynamiques qui changent fréquemment dans les données de configuration. Soumettez le TOML géré au même processus de contrôle des modifications que tout autre paramètre MDM.

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 révision de sécurité autorise un collecteur ou des 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.
• Examinez régulièrement les différences entre le fichier config.toml local et la politique gérée pour repérer les dérives ; les couches gérées doivent prévaloir sur les options et les fichiers locaux.