Documentation ChatGPT
Français
Contact goolvyouyou@gmail.com

Configuration gérée

Configuration gérée

Distribuez les paramètres de configuration par défaut et imposez des exigences sur les clients locaux pris en charge

La configuration gérée contrôle le comportement pris en charge de 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 la version. La configuration gérée n’accorde pas l’accès à l’espace de travail ChatGPT, n’attribue pas de licences et ne remplace pas le contrôle d’accès fondé sur les rôles (RBAC) de l’espace de travail. Utilisez 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 d’exécution locale.

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 auxquelles les utilisateurs ne peuvent pas déroger.
  • Paramètres de configuration par défaut : paramètres config.toml gérés par le système ou dans le cloud que les utilisateurs peuvent remplacer.
  • Anciens paramètres par défaut gérés : 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.

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

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

Consultez la référence de configuration pour les clés de configuration, l’ordre de priorité de la configuration 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.

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, serveurs MCP 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 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 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.

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 une sandbox ou un profil d’autorisations en lecture seule autorisé par vos exigences gérées. Les commandes autorisées par cette sandbox peuvent s’exécuter sans approbation.

Pour conserver des approbations de commandes plus strictes, ne définissez pas explicitement approval_policy 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é.

Emplacements et ordre de priorité

Chaque client local pris en charge compose les exigences des niveaux de priorité les plus faibles aux plus élevés :

  1. Fichier système requirements.toml (/etc/codex/requirements.toml sur les systèmes Unix, notamment Linux et macOS, ou %ProgramData%\OpenAI\Codex\requirements.toml sous Windows).
  2. Exigences gérées par l’entreprise fournies dans le bundle de configuration cloud.
  3. Champs hérités managed_config.toml que le client local réinterprète comme des exigences.
  4. Préférences macOS gérées (MDM) fournies 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 sont fusionnées par clé, tandis que les exigences telles que les règles, les hooks et les restrictions du système de fichiers suivent un comportement de composition propre à chaque champ. Consultez la référence requirements.toml pour connaître le schéma actuel au lieu de supposer que tous les champs sont fusionnés de la même manière.

Pour assurer la rétrocompatibilité, les clients locaux pris en charge réinterprètent les champs hérités 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 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 prise en charge, les clients locaux compatibles peuvent recevoir les exigences imposées par l’administrateur 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.

Ouvrez la page 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 confirmation avant l’exécution d’un point d’entrée d’interpréteur de commandes 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 sélectionnées et testez la politique avec un petit groupe avant de l’attribuer à l’ensemble de l’organisation. Consultez la référence de configuration pour connaître le schéma actuel et l’interface d’administration pour le comportement d’attribution actuel.

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 côté espace de travail. Ne vous appuyez pas sur une copie de l’algorithme de correspondance des groupes ; le service d’administration est responsable de ce comportement et peut le modifier indépendamment du format des exigences locales.

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

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

Lorsqu’un utilisateur démarre 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 à l’identité. Si aucune entrée valide n’est disponible, le client récupère le bundle applicable avec plusieurs tentatives et é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 bundle de configuration cloud renvoie une erreur au lieu de démarrer silencieusement sans la couche d’exigences gérée dans le cloud.

Après la résolution du cache, le client compose les exigences 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 actuel.

Vérifier 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 qui doivent la recevoir, et documentez le motif opérationnel de toute restriction liée au système de fichiers, au réseau, à l’approbation ou au profil d’autorisation.

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

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 du cloud.

Pour imposer 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. S’il est omis, ce paramètre ne limite 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 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ésactiver Appshots

Pour désactiver Appshots pour les utilisateurs gérés, définissez l’exigence de niveau supérieur allow_appshots :

allow_appshots = false

Lorsqu’Appshots est disponible, allow_appshots = false le désactive. Si vous omettez la clé, les exigences ne limitent pas Appshots et les vérifications normales de disponibilité du produit s’appliquent. Les clients app-server qui lisent les exigences effectives via configRequirements/read reçoivent la même restriction que allowAppshots ; une valeur allowAppshots omise ou définie sur null 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 gérés, définissez l’exigence de niveau supérieur allow_remote_control :

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 la clé, les exigences ne limitent pas le contrôle à distance des appareils et les vérifications normales de disponibilité du produit s’appliquent. Cette exigence ne désactive pas les connexions SSH distantes.

Contrôler les profils d’autorisation 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.

Remplacer les exigences de sandbox selon l’hôte

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.

Vous pouvez également limiter 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.

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

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 le bac à sable. Les outils de navigateur 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, et non d’un acheminement du trafic du navigateur via le proxy de commandes. Il ne filtre ni la recherche Web, ni les apps et connecteurs, ni les serveurs MCP, ni le trafic des apps natives, ni les requêtes adressées 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 sur le 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 lorsqu’ils sont pris en charge.
  • Utilisez la liste d’approbation 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 fonctionnalités de navigateur et de computer-use.
  • 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 aux fonctionnalités.

Contrôler le navigateur et Computer Use

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. Une règle d’autorisation configurée n’installe pas de plugin, n’accorde pas d’autorisation au niveau du système d’exploitation et n’approuve pas une action qui nécessite encore un examen.

Pour l’accès par navigateur, configurez une politique d’origine. Une origine comprend le schéma, l’hôte et, éventuellement, le port, par exemple https://example.com ou https://*.example.com:8443. N’incluez ni chemin, ni requête, ni fragment. Contrairement aux règles de domaine du réseau de commandes, les règles d’origine du navigateur distinguent HTTP de HTTPS et tiennent compte du port.

Cet exemple limite l’accès du navigateur à un site approuvé et y empêche les téléversements 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 champs que les règles correspondantes ne précisent pas. La configuration locale peut ajouter des restrictions, mais ne peut pas assouplir un refus géré. Les refus réseau et les listes d’autorisation réseau gérées exclusives continuent de s’appliquer.

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

Pour les apps natives, définissez une politique d’accès par défaut et identifiez les apps 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 apps empaquetées avec computer_use.windows.aumids ou les exécutables avec computer_use.windows.exes. Les règles relatives aux exécutables nécessitent publisher_name, product_name et access ; binary_name est facultatif. Utilisez l’identité vérifiée de l’app plutôt que son seul nom d’affichage.

Consultez la référence de configuration pour connaître tous les champs et les restrictions relatives à Locked Use pour les appareils macOS gérés.

Figer les indicateurs de fonctionnalité

Vous pouvez également figer les indicateurs de fonctionnalité pour les utilisateurs recevant un 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é de référence provenant 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 afin de respecter ces valeurs figées et rejette les écritures conflictuelles dans config.toml ou dans les paramètres de fonctionnalité des fichiers de profil.

  • in_app_browser = false désactive le volet de 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 fonctionnalité est prise en charge. Cela n’affecte pas le déploiement par des packages externes et ne prolonge pas la prise en charge des anciennes versions de l’application. Pour obtenir des conseils sur la configuration et le déploiement, consultez Gérer les mises à jour des applications.
  • browser_use = false désactive Computer Use dans les navigateurs et la disponibilité de Browser Agent.
  • browser_use_full_cdp_access = false désactive l’accès CDP complet dans l’environnement d’exécution local, notamment le mode Browser Developer, et empêche l’application de bureau ChatGPT d’activer le paramètre correspondant.
  • browser_use_external = false désactive Browser Use externe.
  • computer_use = false désactive Computer Use, Record & Replay ainsi que les workflows 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é normale selon le client, la plateforme et le déploiement.

Restreindre l’utilisation d’un ordinateur verrouillé

Pour empêcher les utilisateurs d’activer Locked Use sur un Mac géré, ajoutez cette exigence :

[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 celui-ci est déjà activé. Si vous l’omettez, la disponibilité normale du produit et le paramètre local de l’utilisateur continuent de s’appliquer.

Configurer la politique de revue automatique

Utilisez allowed_approvals_reviewers pour imposer ou autoriser la revue automatique. Définissez-la sur ["auto_review"] pour imposer la revue automatique, ou incluez "user" lorsque les utilisateurs peuvent choisir l’approbation manuelle.

Définissez guardian_policy_config pour remplacer la section propre au tenant de la politique de revue automatique. L’environnement d’exécution local continue d’utiliser le modèle de réviseur intégré et le contrat de sortie. Le paramètre guardian_policy_config géré est prioritaire sur le paramètre [auto_review].policy local.

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

Imposer des exigences de refus de lecture

Les administrateurs peuvent refuser les lectures de chemins exacts ou de 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.
]

Lorsque des exigences de refus de lecture sont présentes, l’environnement d’exécution local rejette les autorisations d’accès complet et conserve l’exécution locale dans une sandbox en lecture seule ou limitée à l’espace de travail afin de pouvoir les appliquer. Sous Windows natif, le paramètre deny_read géré s’applique aux outils de fichiers directs ; les lectures par des sous-processus shell n’utilisent pas cette règle de sandbox.

Imposer des hooks gérés à partir 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 elle-même et faites pointer managed_dir vers le répertoire où votre outil MDM ou 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, figez [features].hooks = true avec [hooks]. Pour ignorer les hooks utilisateur, projet, session et 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 dans managed_dir.
  • Distribuez ces scripts à l’aide de votre solution MDM ou de gestion des appareils.
  • Les commandes des hooks gérés doivent référencer des chemins de scripts absolus sous le répertoire géré configuré.
  • allow_managed_hooks_only = true ignore les hooks provenant des sources utilisateur, projet, session et plugin, mais charge toujours ceux provenant de requirements.toml et d’autres couches de configuration gérées.

Imposer des règles de commande à partir des exigences

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 ordinaires, et la décision la plus restrictive reste prioritaire.

Contrairement à .rules, les règles d’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 approuvée mcp_servers. Pour les serveurs stdio, établissez la correspondance sur command ; pour les serveurs HTTP diffusables, établissez-la sur url :

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

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

La forme chaîne de identity.command correspond uniquement au paramètre command configuré. Elle n’inspecte pas args, cwd, env ni env_vars.

Pour limiter une invocation stdio complète, établissez la correspondance sur 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’argument et d’URL prennent en charge les correspondances exact, prefix et regex sur la valeur complète. Les règles de commande structurées n’inspectent toujours pas cwd, env ni env_vars. Les serveurs MCP intégrés aux plugins utilisent les mêmes formes 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ôler la disponibilité des plugins

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

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.

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

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.

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 cette valeur par gpt-5.6-sol avant le 14 octobre 2026. GPT-5.5 sera retiré de ChatGPT, ChatGPT Work et Codex pour toutes les offres à cette date. L’API OpenAI n’est pas concernée. Consultez 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 fige gpt-5.4 ou gpt-5.4-mini pour les utilisateurs connectés avec ChatGPT, mettez-la à jour 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’OpenAI API et Codex authentifié avec votre propre API key ne sont pas concernés. Consultez la disponibilité des modèles dans l’espace de travail.

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

Priorité et superposition

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.

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 analyse 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), l’ordre de priorité suit celui des exigences gérées dans le cloud décrit ci-dessus. La même table [features] côté exigences fonctionne dans requirements_toml_base64 ; utilisez également les clés de fonctionnalité de référence à cet endroit.

Workflow 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.

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

Mesures de protection recommandées

  • 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 revue de sécurité autorise un collecteur ou les domaines requis par vos workflows.
  • Utilisez la configuration gérée pour figer 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 diffs entre le fichier config.toml local et la politique gérée afin de détecter les dérives ; les couches gérées doivent être prioritaires sur les indicateurs et fichiers locaux.