Configuration gérée

La configuration gérée contrôle les comportements d’exécution locale pris en charge 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 à l’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 d’exécution locale.

Les administrateurs d’entreprise peuvent contrôler de deux manières le comportement des clients locaux pris en charge :

• Exigences : contraintes imposées par les administrateurs, auxquelles les utilisateurs ne peuvent pas déroger.
• 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 au démarrage suivant.

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

Les exigences limitent les paramètres sensibles sur le plan de la sécurité : politique d’approbation, responsable de la révision des approbations, politique de révision automatique, mode de bac à sable, profils d’autorisation, mode de recherche web, hooks gérés, serveurs MCP que les utilisateurs peuvent activer et sources de Marketplace de plugins configurées par les utilisateurs qu’ils peuvent ajouter, utiliser pour installer des plugins ou actualiser. Lors de la résolution de la configuration, par exemple à partir de config.toml, de fichiers de profil ou de surcharges de configuration de la CLI, si une valeur contrevient à 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 restreindre les indicateurs de fonctionnalité via la table [features] de requirements.toml. Notez que les fonctionnalités ne sont pas toujours sensibles sur le plan de la sécurité, mais les entreprises peuvent en figer les valeurs si elles le souhaitent. Les clés omises restent sans restriction.

À partir de Codex 0.138.0, privilégiez les profils d’autorisation avec allowed_permission_profiles et le paramètre géré default_permissions. N’utilisez allowed_sandbox_modes que pour les anciens déploiements qui configurent encore sandbox_mode.

Pour consulter la liste exacte des clés, reportez-vous à la section requirements.toml de la Référence de configuration.

Emplacements et ordre de priorité

Chaque client local pris en charge combine les exigences par ordre de priorité croissant :

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 sur Windows).
2. Exigences gérées par l’entreprise fournies dans le bundle de configuration cloud.
3. Champs hérités 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 ordinaires et les listes des couches inférieures. Les tables fusionnent par clé, tandis que les exigences relatives aux règles, aux hooks et aux restrictions du système de fichiers suivent des règles de combinaison propres à chaque champ. Consultez la référence requirements.toml pour connaître le schéma actuel, plutôt que de supposer que tous les champs fusionnent de la même manière.

Pour assurer la rétrocompatibilité, les clients locaux pris en charge réinterprètent les champs hérités approval_policy, approvals_reviewer et sandbox_mode comme des exigences. Cette conversion ajoute si nécessaire des options de compatibilité ; utilisez requirements.toml pour définir 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 des exigences imposées par les administrateurs et associées à l’espace de travail. Il s’agit d’un canal de distribution pour une politique compatible avec requirements.toml. Ce canal 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).

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 confirmation 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 sélectionnées 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 obtenir le schéma actuel et l’interface d’administration pour connaître les modalités actuelles d’attribution.

Le service sélectionne les couches d’exigences gérées par l’entreprise qui s’appliquent à l’identité de l’utilisateur connecté. 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 côté espace de travail. Ne vous fiez pas à une copie de l’algorithme de mise en 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 lance un client local pris en charge et se connecte avec ChatGPT dans le cadre d’une offre prise en charge, le client recherche d’abord une entrée de cache valide correspondant à son identité. Si aucune entrée valide n’est disponible, le client récupère le bundle applicable en effectuant plusieurs tentatives et, en cas de réussite, écrit une entrée de cache signée. 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ées dans le cloud.

Après la résolution du cache, le client combine les exigences gérées dans le 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érifier l’expérience des administrateurs et des collaborateurs

Désignez une personne responsable de chaque politique gérée, consignez les utilisateurs ou groupes auxquels elle doit s’appliquer et documentez la justification métier de toute restriction liée au système de fichiers, au réseau, aux approbations ou aux profils d’autorisation.

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

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 allow_appshots de premier niveau :

allow_appshots = false

Lorsque la fonctionnalité Appshots est disponible, allow_appshots = false la désactive. Si vous omettez la clé, les exigences n’imposent aucune restriction à Appshots et les vérifications habituelles de disponibilité du produit s’appliquent. Les clients App Server qui lisent les exigences effectives via configRequirements/read reçoivent la même restriction sous la forme de allowAppshots ; une valeur omise ou égale à null pour allowAppshots ne désactive pas Appshots.

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

Pour désactiver le contrôle à distance de l’appareil pour les utilisateurs gérés, définissez l’exigence allow_remote_control de premier niveau :

allow_remote_control = false

Lorsque le contrôle à distance de l’appareil est pris en charge, allow_remote_control = false le désactive. Si vous omettez la clé, les exigences n’imposent aucune restriction au contrôle à distance de l’appareil et les vérifications habituelles 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. Il s’agit, pour ces profils, du pendant de allowed_sandbox_modes ; utilisez la liste d’autorisation qui correspond à la manière dont vos utilisateurs sélectionnent leurs autorisations.

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

N’utilisez les exemples de profils d’autorisation 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 refuse ceux qui sont omis ou définis sur false, y compris les profils intégrés ajoutés dans de futures versions de Codex.

Autoriser les profils standard

Cette politique autorise l’accès en lecture seule et l’accès à l’espace de travail, mais 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 selon 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 ne risquent pas d’entrer en conflit avec ceux de la configuration chargée des utilisateurs. Les noms personnalisés ne peuvent pas commencer par : ni reprendre filesystem, un nom réservé.

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 sélectionne le profil.

Par exemple :

default_permissions = "acme_review_only"

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

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

Autoriser uniquement les profils définis par l’entreprise

Omettez tous les profils intégrés lorsque les utilisateurs ne doivent pouvoir sélectionner que ceux 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ésactiver un profil autorisé par une autre source

Les listes d’autorisation se combinent par nom de profil. Comme les exigences gérées dans le cloud sont prioritaires sur les exigences système, elles peuvent utiliser false pour désactiver un profil autorisé par le fichier système.

Exigences gérées dans le 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 avec le nom d’un profil autorisé. Si ce paramètre est omis, l’environnement d’exécution local adopte :workspace par défaut uniquement si :workspace et :read-only sont tous deux explicitement autorisés. En l’absence de allowed_permission_profiles, les exigences gérées ne limitent pas les noms de profils que les utilisateurs peuvent sélectionner. Chaque entrée doit désigner un profil intégré ou un profil personnalisé défini dans une configuration chargée ou une source d’exigences. Définissez les profils personnalisés dans les exigences gérées afin de contrôler leur comportement de façon centralisée.

Redéfinir les exigences de bac à sable selon l’hôte

Utilisez [[remote_sandbox_config]] lorsqu’une même politique gérée doit appliquer des exigences de bac à sable 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 l’écriture dans l’espace de travail sur les machines de développement ou les runners CI correspondants. Actuellement, les entrées propres à un hôte ne redéfinissent 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 qu’il parvient à résoudre. Il privilégie le nom de domaine complet lorsqu’il est disponible et utilise à défaut le nom d’hôte local. La correspondance ne tient pas compte de la casse ; * correspond à n’importe quelle suite 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 la valeur 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 authentifiée de l’identité 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 = [] n’autorise que "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 réseau

Utilisez [experimental_network] dans requirements.toml lorsque les administrateurs doivent définir de manière centralisée les exigences d’accès réseau. Ces exigences sont distinctes du paramètre utilisateur features.network_proxy : elles permettent de configurer la connectivité réseau du bac à sable sans cet indicateur de fonctionnalité, mais n’accordent pas d’accès réseau aux commandes lorsque le bac à sable actif maintient l’accès réseau désactivé. Définissez experimental_network.enabled = true pour activer le proxy géré ; une simple liste d’autorisation ne suffit pas à activer le proxy.

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 si vous définissez également une liste allowed_domains contrôlée par les administrateurs et souhaitez que cette liste d’autorisation soit exclusive. Si sa valeur est 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.

La syntaxe des domaines, les règles relatives aux destinations locales ou privées, la priorité des refus sur les autorisations et les limites du rebinding DNS sont les mêmes que pour le fonctionnement réseau du bac à sable décrit dans Autorisations de l’agent et sécurité.

Ces exigences s’appliquent uniquement aux commandes locales exécutées dans le bac à sable. Elles n’acheminent ni ne filtrent la recherche web, les applications et connecteurs, les serveurs MCP, l’activité du navigateur ou de la fonctionnalité Utilisation de l’ordinateur, les requêtes adressées au service Codex ni le trafic Codex Cloud. Utilisez les contrôles propres à chaque fonctionnalité :

• 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 lorsqu’ils sont pris en charge.
• Utilisez la liste gérée mcp_servers des serveurs approuvés pour restreindre les serveurs MCP.
• Utilisez des exigences relatives aux fonctionnalités, telles que browser_use, in_app_browser et computer_use, pour limiter les capacités liées au navigateur et à l’utilisation de l’ordinateur.
• Configurez l’accès réseau de Codex Cloud dans les paramètres de son environnement cloud.

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

Fixer 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é canoniques de config.toml, dans la table [features], pour les fonctionnalités d’exécution. L’environnement d’exécution local normalise les fonctionnalités reconnues pour respecter ces valeurs imposées et refuse toute écriture incompatible dans config.toml ou dans les paramètres de fonctionnalités des fichiers de profil.

• in_app_browser = false désactive le volet du navigateur intégré.
• in_app_updates = false désactive le programme de mise à jour propre à l’application de bureau ChatGPT au redémarrage, lorsque cette fonctionnalité est prise en charge. Cela n’affecte pas le déploiement externe de paquets et ne prolonge pas la prise en charge des anciennes versions de l’application. Pour obtenir des instructions 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 CDP complet dans l’environnement d’exécution local, y compris le mode développeur du navigateur, et empêche l’application de bureau ChatGPT d’activer le paramètre correspondant.
• browser_use_external = false désactive la fonctionnalité Navigateur externe.
• computer_use = false désactive les fonctionnalités Utilisation de l’ordinateur et Enregistrer et rejouer, ainsi que les parcours d’installation ou de configuration associés.

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

Restreindre l’utilisation lorsque l’ordinateur est verrouillé

Pour empêcher la fonctionnalité Utilisation de l’ordinateur 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 la fonctionnalité Utilisation de l’ordinateur. Elle empêche uniquement son utilisation après verrouillage sur macOS. Si vous l’omettez, les exigences ne limitent pas cette utilisation ; les conditions habituelles de disponibilité du produit et le paramètre local de l’utilisateur continuent de s’appliquer.

Configurer la stratégie de révision automatique

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

Définissez guardian_policy_config pour remplacer la section propre au locataire de la stratégie de révision 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 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.
"""

Imposer les exigences d’interdiction de lecture

Les administrateurs peuvent interdire la lecture pour des chemins exacts ou des motifs glob à l’aide de [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 d’interdiction de lecture sont présentes, l’environnement d’exécution local refuse les autorisations d’accès complet et maintient l’exécution locale dans un bac à sable en lecture seule ou avec accès à l’espace de travail afin de pouvoir les appliquer. Sous Windows en mode natif, le paramètre géré deny_read s’applique aux outils d’accès direct aux fichiers ; les lectures effectuées par des sous-processus shell ne sont pas soumises à cette règle du bac à sable.

Imposer les hooks gérés définis dans les exigences

Les administrateurs peuvent également définir des hooks de cycle de vie gérés directement dans requirements.toml. Utilisez [hooks] pour configurer les hooks et faites pointer managed_dir vers le répertoire dans lequel vos outils MDM ou de gestion des terminaux installent les scripts référencés.

Pour imposer les hooks gérés même aux utilisateurs qui les ont désactivés localement, fixez [features].hooks = true en même temps que [hooks]. Pour ignorer les hooks de l’utilisateur, du projet, de la session 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 applique la configuration des hooks définie dans requirements.toml, mais ne distribue pas les scripts contenus dans managed_dir.
• Déployez ces scripts avec votre solution MDM ou de gestion des appareils.
• Les commandes des hooks gérés doivent référencer des chemins absolus vers des scripts situés dans le répertoire géré configuré.
• allow_managed_hooks_only = true ignore les hooks provenant de l’utilisateur, du projet, de la session et des plugins, mais continue de charger ceux de requirements.toml et des autres couches de configuration gérée.

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

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

Contrairement aux fichiers .rules, les règles définies dans les exigences doivent spécifier decision. 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 mcp_servers de serveurs approuvés. Pour les serveurs stdio, utilisez command comme critère ; pour les serveurs HTTP avec diffusion en continu, utilisez url :

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

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

La forme textuelle de identity.command ne compare que la valeur command configurée. Elle n’examine pas args, cwd, env ni env_vars.

Pour contraindre une invocation stdio complète, faites correspondre l’exécutable et chacun des arguments positionnels :

[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 relatives aux arguments et aux URL prennent en charge les correspondances exact et prefix, ainsi que les correspondances regex portant sur l’intégralité de la valeur. Les règles structurées relatives aux commandes n’examinent toujours pas cwd, env ni env_vars. Les serveurs MCP intégrés aux 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ô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 clé API. Consultez la section features.plugins de la référence pour connaître la configuration prise en charge.

Restreindre les sources de la Marketplace des plugins

Pour restreindre les opérations sur les sources de Marketplace configurées par les utilisateurs, définissez restrict_to_allowed_sources = true et configurez 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 correspondent à l’URL normalisée du dépôt et, le cas échéant, à la valeur exacte de ref. Les motifs d’hôte sont des expressions régulières comparées au nom d’hôte Git en minuscules ; utilisez ^ et $ pour faire correspondre l’intégralité du nom d’hôte. 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 bloquent, pour les sources configurées par les utilisateurs, les opérations d’ajout de Marketplaces, d’installation de plugins et d’actualisation de Marketplaces Git configurées lorsqu’elles ne correspondent à aucune règle. Les Marketplaces OpenAI gérées par Codex restent disponibles lorsque leur source et leur nom réservé correspondent aux valeurs attendues. Ces exigences ne filtrent pas les Marketplaces utilisateur déjà configurées ni leurs plugins lors de l’exécution.

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

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

Les valeurs par défaut gérées définissent la configuration utilisée au démarrage d’un client local pris en charge. Au démarrage, elles prévalent sur le fichier config.toml local de l’utilisateur et sur toutes les substitutions --config de la CLI. 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 fixe gpt-5.4 ou gpt-5.4-mini pour les utilisateurs connectés avec ChatGPT, mettez cette configuration à 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’API OpenAI et Codex, lorsqu’il est authentifié à l’aide de votre propre clé API, ne sont pas concernés. Consultez 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 refuse les valeurs non autorisées.

Ordre de priorité et superposition des couches

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

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

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

Les exigences gérées dans le cloud s’appliquent à la couche des exigences, et non aux valeurs par défaut gérées. Pour connaître leur ordre de priorité, consultez la section « Exigences imposées par les administrateurs » ci-dessus.

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 de macOS (MDM)

Sur macOS, les administrateurs peuvent déployer un profil d’appareil contenant des charges utiles 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 charges utiles 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), l’ordre de priorité suit celui des exigences gérées dans le cloud décrit ci-dessus. La même table [features] dédiée aux exigences fonctionne dans requirements_toml_base64 ; utilisez également les clés canoniques des fonctionnalités.

Workflow de configuration MDM

L’environnement d’exécution local prend en charge les charges utiles MDM standard de macOS. Vous pouvez ainsi distribuer les paramètres à l’aide d’outils tels que Jamf Pro, Fleet ou Kandji. Un déploiement simple se déroule comme suit :

1. Créez la charge utile TOML gérée, puis 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 lira la préférence actualisée à son prochain lancement.

Évitez d’intégrer des secrets ou des valeurs dynamiques fréquemment modifiées dans la charge utile. Traitez le TOML géré comme tout autre paramètre MDM soumis au contrôle des modifications.

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

• Pour la plupart des utilisateurs, privilégiez workspace-write avec des approbations ; 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 flux de travail.
• 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.
• Contrôlez régulièrement les différences entre le fichier config.toml local et la politique gérée afin de détecter toute dérive ; les couches gérées doivent avoir la priorité sur les options et fichiers locaux.