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. 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 de requirements.toml pour connaître le schéma actuel, plutôt que de supposer que tous les champs fusionnent de la même manière.

Pour assurer la rétrocompatibilité, les clients locaux pris en charge réinterprètent les 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 et dispose d’un forfait compatible, 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 de politiques compatibles 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). Les exigences d’authentification doivent être gérées localement.

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

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

Vérifiez que chaque version de client géré prend en charge les clés 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 connaître le schéma actuel et l’interface d’administration pour connaître le fonctionnement actuel de l’attribution.

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

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

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

Lorsqu’un utilisateur démarre un client local pris en charge et se connecte avec ChatGPT en disposant d’un forfait compatible, le client recherche d’abord une entrée de cache valide correspondant à son identité. Si aucune entrée valide n’est disponible, le client récupère le bundle applicable en réessayant si nécessaire, puis écrit une entrée de cache signée en cas de succès. Si la requête échoue ou expire et qu’aucun cache valide n’est disponible, le chargement 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.

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

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

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

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

Gérez l’authentification localement

Définissez allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store et chatgpt_base_url dans le fichier système local requirements.toml ou dans les exigences MDM de macOS. Codex ignore ces quatre champs dans les exigences gérées dans le cloud. Les exigences d’authentification locales s’appliquent avant le chargement des identifiants et avant que Codex récupère la politique cloud.

Pour imposer la connexion avec ChatGPT à un espace de travail approuvé et stocker les identifiants dans le magasin 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. Lorsqu’il est omis, ce paramètre ne restreint pas les méthodes de connexion. Lorsqu’il est défini, la liste doit contenir au moins une méthode. api autorise l’authentification par API, y compris avec Amazon Bedrock. La restriction relative à 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 avec ChatGPT est indisponible. L’authentification par API reste disponible lorsqu’elle est autorisée. Si aucune méthode de connexion n’est disponible, Codex refuse de démarrer.

Consultez la référence des exigences pour connaître les modes de stockage des identifiants et la configuration de l’URL du service.

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ésactivez les captures d’application

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

allow_appshots = false

Lorsque les captures d’application sont disponibles, allow_appshots = false les désactive. Si vous omettez la clé, les exigences ne restreignent pas les captures d’application et les vérifications habituelles de disponibilité du produit s’appliquent. Les clients App Server qui lisent les exigences effectives via configRequirements/read reçoivent la même restriction sous la forme de allowAppshots ; si allowAppshots est omis ou vaut null, les captures d’application ne sont pas désactivées.

Désactivez le contrôle à distance des appareils

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

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

Contrôlez les profils d’autorisation disponibles

Utilisez allowed_permission_profiles pour contrôler quels profils d’autorisation intégrés et personnalisés les utilisateurs peuvent sélectionner. Il s’agit de l’équivalent de allowed_sandbox_modes pour les profils d’autorisation ; 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 et le paramètre géré default_permissions.

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

Lorsqu’elle est présente, la table constitue la liste complète des profils autorisés. Elle autorise les profils définis sur true et interdit ceux qui sont omis ou définis sur false, y compris les profils intégrés ajoutés dans de futures versions de Codex.

Autorisez les profils standard

Cette politique autorise l’accès en lecture seule et l’accès à l’espace de travail, mais pas l’accès complet :

default_permissions = ":workspace"

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

Ajoutez un profil géré par défaut respectant le principe du moindre privilège

Les administrateurs peuvent définir un profil personnalisé dans la même source d’exigences. Utilisez des noms de profils propres à l’organisation qui n’entreront pas en conflit avec les noms présents dans la configuration chargée des utilisateurs. Les noms personnalisés ne peuvent pas commencer par : ni utiliser le nom réservé filesystem.

Ne déployez pas de profils personnalisés gérés sur des clients utilisant Codex 0.137.0 ou une version antérieure. Ces clients reconnaissent la table du profil, mais pas le paramètre géré par défaut qui le sélectionne.

Par exemple :

default_permissions = "acme_review_only"

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

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

Autorisez uniquement les profils définis par l’entreprise

Omettez tous les profils intégrés lorsque les utilisateurs doivent pouvoir sélectionner uniquement les profils définis par les administrateurs :

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Le profil personnalisé peut étendre :workspace, même si les utilisateurs ne peuvent pas sélectionner directement le profil intégré :workspace.

Désactivez un profil autorisé par une autre source

Les listes d’autorisation se combinent par nom de profil. Comme les exigences cloud ont priorité sur les 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é. Si ce paramètre est omis, l’environnement d’exécution local utilise :workspace par défaut uniquement si :workspace et :read-only sont tous deux explicitement autorisés. Lorsque allowed_permission_profiles est absent, les exigences gérées ne restreignent 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 configuration ou une source d’exigences chargée. Définissez les profils personnalisés dans les exigences gérées pour contrôler leur comportement de manière centralisée.

Remplacez les exigences du 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 des paramètres par défaut plus stricts pour les ordinateurs portables tout en autorisant l’écriture dans l’espace de travail sur les machines de développement ou les exécuteurs CI correspondants. Les entrées propres à un hôte remplacent actuellement uniquement allowed_sandbox_modes :

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

L’environnement d’exécution local compare chaque entrée de hostname_patterns au nom d’hôte qu’il a pu résoudre. Il privilégie le nom de domaine complet lorsqu’il est disponible et utilise sinon le nom d’hôte local. La correspondance est insensible à la casse ; * correspond à n’importe quelle suite de caractères et ? à un seul caractère.

La première entrée [[remote_sandbox_config]] correspondante prévaut au sein d’une même source d’exigences. Si aucune entrée ne correspond, l’environnement d’exécution local conserve la valeur de premier niveau de allowed_sandbox_modes. 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 = [] autorise uniquement "disabled". Par exemple, allowed_web_search_modes = ["cached"] empêche la recherche web en direct, même dans les sessions danger-full-access.

Configurez les exigences d’accès réseau

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

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

Utilisez experimental_network.managed_allowed_domains_only = true uniquement si vous définissez également des entrées "allow" sous le contrôle des administrateurs dans [experimental_network.domains] et souhaitez que ces règles soient exclusives. Si ce paramètre vaut true sans règles d’autorisation gérées, les règles d’autorisation de domaine ajoutées par les utilisateurs cessent de s’appliquer. Ne combinez pas la table de correspondance canonique domains avec les anciennes listes allowed_domains ou denied_domains.

*.example.com correspond uniquement aux sous-domaines. **.example.com correspond au domaine racine et à ses sous-domaines. Une règle de refus correspondante prévaut sur une règle d’autorisation.

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

Le proxy achemine le trafic des commandes locales exécutées dans le bac à sable. Les outils de navigation vérifient également les refus réseau gérés et les listes d’autorisation exclusives avant d’accéder à une origine ; cette vérification de politique est distincte et ne fait pas passer le trafic du navigateur par le proxy des commandes. Celui-ci ne filtre ni la recherche web, ni les applications et les connecteurs, ni les serveurs MCP, ni le trafic des applications natives, ni les requêtes au service Codex, ni le trafic de Codex Cloud. Utilisez les contrôles propres à chaque interface :

• Utilisez allowed_web_search_modes pour restreindre la recherche web.
• Utilisez features.apps = false pour désactiver les intégrations d’applications et de connecteurs, et features.plugins = false pour désactiver les plugins lorsque cette option est prise en charge.
• Utilisez la liste d’autorisation gérée mcp_servers pour restreindre les serveurs MCP.
• Utilisez des exigences de fonctionnalités telles que browser_use, in_app_browser et computer_use pour restreindre les capacités de navigation et d’utilisation de l’ordinateur.
• Configurez l’accès réseau de Codex Cloud dans les paramètres de son environnement cloud.

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

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

Utilisez les tables [browser_use] et [computer_use] dans requirements.toml pour restreindre les clients de bureau compatibles. 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 du système d’exploitation et n’approuve pas une action qui nécessite encore une révision.

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

Cet exemple limite l’accès du navigateur à un site approuvé et y interdit 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 prévaut ; 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 la révision automatique des approbations pour les actions du navigateur, ou définissez auto_review = "deny" dans une politique d’origine pour la désactiver pour cette origine. Ce paramètre contrôle le traitement des approbations ; il ne désactive pas la surveillance de la sécurité du modèle.

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

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Les politiques Windows peuvent identifier les applications empaquetées avec computer_use.windows.aumids ou les exécutables avec computer_use.windows.exes. Les règles portant sur les exécutables exigent publisher_name, product_name et access ; binary_name est facultatif. Utilisez l’identité vérifiée de l’application plutôt que son seul nom d’affichage.

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

Imposez les valeurs des indicateurs de fonctionnalité

Vous pouvez également imposer les valeurs des indicateurs de fonctionnalité aux 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

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

• in_app_browser = false désactive le volet du navigateur intégré.
• in_app_updates = false désactive le mécanisme de mise à jour propre à l’application de bureau ChatGPT au redémarrage, lorsque cette option est prise en charge. Ce paramètre n’affecte pas le déploiement externe de paquets et ne prolonge pas la prise en charge des anciennes versions de l’application. Pour des conseils de configuration et de déploiement, consultez Gestion des mises à jour de l’application.
• browser_use = false désactive l’utilisation de l’ordinateur dans les navigateurs et rend l’agent de navigation indisponible.
• browser_use_full_cdp_access = false désactive l’accès complet au CDP dans l’environnement d’exécution local, y compris le mode développeur du navigateur, et empêche l’application de bureau ChatGPT d’activer le paramètre correspondant.
• browser_use_external = false désactive la fonctionnalité Navigateur externe.
• computer_use = false désactive 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 politique autorise les fonctionnalités, sous réserve des conditions habituelles de disponibilité liées au client, à la plateforme et au déploiement.

Restreignez l’utilisation sur ordinateur verrouillé

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

[computer_use]
allow_locked_computer_use = false

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

Configurez la politique de révision automatique

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

Définissez guardian_policy_config pour remplacer la section propre au tenant dans la politique de révision automatique. L’environnement d’exécution local utilise toujours le modèle d’instructions intégré du réviseur et le contrat de sortie intégré. Le paramètre géré guardian_policy_config prévaut sur le paramètre local [auto_review].policy.

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

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

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

Imposez des exigences d’interdiction de lecture

Les administrateurs peuvent interdire la lecture de chemins précis ou correspondant à des motifs glob avec [permissions.filesystem]. Les utilisateurs ne peuvent pas assouplir ces exigences au moyen de la configuration locale.

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

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

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

Les administrateurs peuvent également définir des hooks de cycle de vie gérés directement dans requirements.toml. Utilisez [hooks] pour la configuration des hooks eux-mêmes et faites pointer managed_dir vers le répertoire où votre solution MDM ou votre outil de gestion des terminaux installe les scripts référencés.

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

allow_managed_hooks_only = true

[features]
hooks = true

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

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

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

Remarques :

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

Imposez des règles de commande au moyen 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 fusionnent avec les fichiers .rules habituels, et la décision la plus restrictive prévaut toujours.

Contrairement aux fichiers .rules, les règles définies dans les exigences doivent préciser decision, et cette décision doit être "prompt" ou "forbidden" (pas "allow").

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

Pour restreindre les serveurs MCP qu’un client local peut activer, ajoutez une liste d’autorisation mcp_servers. Pour les serveurs stdio, utilisez command comme critère de correspondance ; pour les serveurs HTTP en streaming, utilisez url :

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

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

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

Pour restreindre une invocation stdio complète, vérifiez la correspondance de l’exécutable et de 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 sur les arguments et les URL prennent en charge les correspondances exact, prefix et regex portant sur la valeur entière. Les règles de commande structurées n’examinent toujours ni cwd, ni env, ni env_vars. Les serveurs MCP fournis avec les plugins utilisent les mêmes structures d’identité sous plugins.<plugin>.mcp_servers.<server>.

Si mcp_servers est présent mais vide, le client local désactive tous les serveurs MCP.

Contrôlez la disponibilité des plugins

Pour désactiver les plugins dans les clients locaux compatibles, définissez features.plugins sur false dans requirements.toml :

features.plugins = false

Ce paramètre s’applique aussi lorsque les utilisateurs se connectent à Codex avec une clé API. Consultez la référence de features.plugins pour connaître la configuration prise en charge.

Restreignez les sources des marketplaces de plugins

Pour restreindre les opérations sur les sources de marketplaces configurées par les utilisateurs, définissez restrict_to_allowed_sources = true et ajoutez une ou plusieurs règles de source :

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

Les règles Git vérifient l’URL normalisée du dépôt et, le cas échéant, la correspondance exacte de ref. Les motifs d’hôte sont des expressions régulières appliquées au nom d’hôte Git en minuscules ; utilisez ^ et $ pour une correspondance sur le nom d’hôte entier. Les règles locales exigent un chemin absolu et normalisé. Consultez la référence de requirements.toml pour connaître le schéma complet et le comportement de fusion.

Pour les sources configurées par les utilisateurs, ces exigences rejettent les opérations d’ajout de marketplace, d’installation de plugin et d’actualisation de marketplace Git configurée qui ne correspondent pas aux règles. 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 déjà configurées par les utilisateurs ni leurs plugins.

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

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

Les valeurs par défaut gérées définissent la configuration initiale d’un client local compatible. Au démarrage, elles prévalent sur le fichier config.toml local de l’utilisateur et sur toute substitution fournie via --config dans 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 le modèle sur gpt-5.4 ou gpt-5.4-mini pour les utilisateurs connectés avec ChatGPT, mettez ce paramétrage à 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 authentifié avec votre propre clé API ne sont pas concernés. Consultez la page sur la disponibilité des modèles dans l’espace de travail.

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

Priorité et superposition des couches

L’environnement d’exécution local assemble la configuration effective dans cet ordre (les couches du haut prévalent sur celles 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 substitutions fournies via --config key=value dans la CLI s’appliquent à la configuration de base, mais les couches gérées prévalent sur elles. 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). 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 gérées macOS (MDM)

Sur macOS, les administrateurs peuvent déployer un profil d’appareil qui fournit 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 interprète ces charges utiles de « préférences gérées » comme du TOML. Pour les valeurs par défaut gérées (config_toml_base64), les préférences gérées ont la priorité la plus élevée. Pour les exigences (requirements_toml_base64), la priorité suit l’ordre décrit ci-dessus pour les exigences gérées dans le cloud. La même table [features] des exigences fonctionne dans requirements_toml_base64 ; utilisez également les clés de fonctionnalité canoniques à 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. Voici les étapes d’un déploiement simple :

1. Créez la charge utile gérée au format TOML et encodez-la avec base64 (sans retours à 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 compatible et de vérifier que le résumé de la configuration au démarrage affiche bien 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 au prochain démarrage.

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

Exemple de managed_config.toml

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = "otlp-http"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

Garde-fous recommandés

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