Documentation ChatGPT
Français
Contact goolvyouyou@gmail.com

Configuration gérée

Appliquez des exigences d’exécution aux clients locaux pris en charge et distribuez des valeurs par défaut gérées

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 pris en charge des clients locaux de deux manières :

  • Exigences : contraintes imposées par l’administrateur que les utilisateurs ne peuvent pas remplacer.
  • Valeurs par défaut gérées : valeurs initiales appliquées au lancement d’un client pris en charge. Les utilisateurs peuvent toujours modifier les paramètres pendant une exécution ; le client réapplique les valeurs par défaut gérées à son prochain démarrage.

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

Les exigences limitent les paramètres sensibles pour la sécurité (politique d’approbation, réviseur des approbations, politique de revue automatique, mode sandbox, profils d’autorisation, mode de recherche web, hooks gérés, serveurs MCP que les utilisateurs peuvent activer et sources de marketplaces de plugins configurées par l’utilisateur qu’ils peuvent ajouter, depuis lesquelles ils peuvent installer ou qu’ils peuvent actualiser). Lors de la résolution de la configuration (par exemple depuis config.toml, des fichiers de profil ou des remplacements de configuration CLI), si une valeur entre en conflit avec une règle imposée, le client local revient à une valeur compatible et avertit 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.

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 pris en charge peuvent recevoir les exigences imposées par l’administrateur associées à l’espace de travail. Il s’agit d’un canal de distribution pour une politique compatible avec requirements.toml. Il n’accorde pas l’accès à l’espace de travail et ne remplace pas le RBAC de celui-ci.

Ouvrez Managed configuration pour créer et attribuer des exigences gérées dans le cloud. Par exemple, cette politique exige que les clients pris en charge utilisent la résidence des données aux États-Unis, limite les choix d’approbation et de sandbox, et demande une confirmation avant l’exécution d’un point d’entrée shell pris en charge :

enforce_residency = "us"
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.

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

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

Lorsque 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 du commutateur utilisateur features.network_proxy : elles peuvent configurer la mise en réseau de la sandbox sans cet indicateur de fonctionnalité, mais n’accordent pas aux commandes l’accès au réseau lorsque la sandbox active maintient la mise en réseau désactivée.

experimental_network.enabled = true
experimental_network.allowed_domains = [
  "api.openai.com",
  "*.example.com",
]
experimental_network.denied_domains = [
  "blocked.example.com",
  "*.exfil.example.com",
]

Utilisez experimental_network.managed_allowed_domains_only = true uniquement lorsque vous définissez également des règles d’autorisation allowed_domains appartenant à l’administrateur et souhaitez que cette liste soit exclusive. Si cette option est définie sur true sans règles d’autorisation gérées, les règles d’autorisation de domaines ajoutées par les utilisateurs ne restent pas actives.

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.

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 Computer Use de fonctionner après le verrouillage d’un Mac géré, ajoutez cette exigence :

[computer_use]
allow_locked_computer_use = false

Cette exigence n’active pas Computer Use. Elle empêche uniquement son utilisation sur un appareil verrouillé sous macOS. Si vous l’omettez, les exigences ne limitent pas l’utilisation sur un appareil verrouillé ; 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 opérations sur les sources de marketplaces configurées par l’utilisateur, définissez restrict_to_allowed_sources = true et 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 marketplace, d’installation de plugin et d’actualisation d’une marketplace Git configurée qui ne correspondent à aucune règle pour les sources configurées par l’utilisateur. Les marketplaces OpenAI gérées par Codex restent disponibles lorsque leur source et leur nom réservé correspondent. Les exigences ne filtrent pas à l’exécution les marketplaces utilisateur déjà configurées ni leurs plugins.

Ces restrictions de sources s’appliquent uniquement lorsqu’un client local prend en charge les opérations de marketplace de plugins : ChatGPT Work et Codex dans l’application de bureau, ainsi que Codex CLI. Elles n’ajoutent pas de plugins à Chat, à l’extension IDE ou aux appareils mobiles.

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

Les valeurs par défaut gérées sont fusionnées par-dessus le fichier config.toml local d’un utilisateur et sont prioritaires sur tout remplacement CLI --config, ce qui définit les valeurs initiales au lancement d’un client local pris en charge. Les utilisateurs peuvent toujours modifier ces paramètres pendant une exécution ; le client réapplique les valeurs par défaut gérées à son prochain démarrage.

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.

Les exigences gérées dans le cloud affectent la couche des exigences (et non les valeurs par défaut gérées). Consultez la section Exigences imposées par l’administrateur ci-dessus pour connaître l’ordre de priorité.

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.