For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Theme

Collaboration et partage

Hébergez la configuration Codex de votre équipe sur votre propre serveur

Distribuez à Codex les paramètres par défaut et les paramètres obligatoires depuis un point de terminaison HTTPS que vous administrez.

Nous recommandons aux membres de votre équipe de se connecter à Codex avec ChatGPT. Si votre abonnement le permet, vous pouvez utiliser la configuration gérée pour définir les paramètres par défaut et imposer des exigences dans la rubrique Agent security de la console d’administration, sans avoir à gérer votre propre serveur.

Si vos utilisateurs ne se connectent pas à Codex avec ChatGPT, vous pouvez distribuer la configuration à Codex CLI et à l’application de bureau ChatGPT depuis un serveur HTTPS que vous administrez. Codex charge vos paramètres au démarrage, que les utilisateurs se connectent à leur fournisseur de modèles directement ou via une passerelle.

Limites des clients Codex

L’application de bureau ChatGPT ne peut pas vous inviter à vous connecter au serveur de configuration. Si votre serveur exige une nouvelle connexion, exécutez codex login dans un terminal sur le même ordinateur, puis rouvrez l’application. Si l’application ne parvient pas à charger les paramètres obligatoires, le démarrage est suspendu.

Configurez Codex pour utiliser le serveur

Sur un ordinateur de test, créez ou mettez à jour le fichier système requirements.toml. Ajoutez une table [config_server] contenant l’URL de base de votre serveur de configuration. Utilisez le chemin /etc/codex/requirements.toml sur Linux et macOS, ou %ProgramData%\OpenAI\Codex\requirements.toml sur Windows. Sur macOS, vous pouvez aussi distribuer cette table via les préférences gérées.

[config_server]
base_url = "https://codex-config.example.com/team"

Seules les exigences locales définies par un administrateur peuvent déterminer quel serveur utiliser. Conservez cette table sur l’ordinateur lorsque vous transférez le reste de votre politique vers le point de terminaison.

Configurez l’authentification auprès du serveur de configuration (facultatif)

Par défaut, Codex tente de récupérer la configuration sans fournir d’identifiants. Si votre serveur exige une connexion, ajoutez [config_server.oauth] au même fichier requirements.toml. Codex utilise le flux OAuth par code d’autorisation avec le mécanisme Proof Key for Code Exchange (PKCE).

[config_server.oauth]
authorization_url = "https://login.example.com/oauth/authorize"
token_url = "https://login.example.com/oauth/token"
client_id = "codex-policy"
redirect_port = 43127

Dans cet exemple, l’URI de redirection est http://127.0.0.1:43127/callback. Vous pouvez omettre redirect_port si votre fournisseur accepte les redirections vers l’adresse de bouclage sur n’importe quel port disponible. Codex envoie le jeton d’accès dans l’en-tête Authorization. Votre serveur doit vérifier ce jeton avant de renvoyer le paquet de configuration.

Distribuez la configuration Codex

Hébergez votre configuration gérée sur un point de terminaison HTTPS. Pour récupérer le paquet de configuration, Codex CLI envoie une requête GET à partir de l’URL de base définie dans le fichier requirements.toml local :

GET {config_server.base_url}/codex/config/bundle

Avec la valeur de base_url définie dans l’exemple de configuration initiale ci-dessus, Codex envoie la requête suivante :

GET https://codex-config.example.com/team/codex/config/bundle

Renvoyez le statut 200 OK et incluez un paquet de configuration JSON dans le corps de la réponse.

Format du paquet de configuration

Le paquet répartit les entrées TOML dans deux tableaux :

  • config_toml.enterprise_managed contient les paramètres par défaut à appliquer. Le champ contents de chaque entrée contient du texte au format config.toml.
  • requirements_toml.enterprise_managed contient les exigences à faire respecter. Le champ contents de chaque entrée contient du texte au format requirements.toml.

Chaque entrée d’un tableau comporte trois champs de type chaîne de caractères : id, name (le nom affiché) et contents. Utilisez un tableau vide pour toute catégorie dont vous n’avez pas besoin.

Cet exemple définit disabled comme valeur par défaut pour la recherche web et impose cette valeur avec allowed_web_search_modes.

{
  "config_toml": {
    "enterprise_managed": [
      {
        "id": "search-default",
        "name": "Default web search",
        "contents": "web_search = 'disabled'"
      }
    ]
  },
  "requirements_toml": {
    "enterprise_managed": [
      {
        "id": "search-policy",
        "name": "Allowed web search modes",
        "contents": "allowed_web_search_modes = ['disabled']"
      }
    ]
  }
}

Vérifiez la configuration dans Codex

  1. Sur un ordinateur de test, ouvrez un terminal dans le répertoire de votre projet et exécutez codex. Si vous y êtes invité, connectez-vous avec votre compte d’entreprise.
  2. À l’invite interactive de Codex CLI, saisissez /debug-config, puis appuyez sur Entrée.
  3. Si votre serveur distribue des paramètres par défaut, repérez leurs noms et leurs identifiants dans la section Config layer stack. Pour l’exemple ci-dessus, recherchez enterprise-managed (Default web search, search-default) (enabled).
  4. Si votre serveur distribue des exigences, repérez un paramètre que vous imposez dans la section Requirements et vérifiez la source de la politique indiquée à côté de ce paramètre.

Codex peut démarrer avec les paramètres en cache et les actualiser en arrière-plan. Après avoir modifié une politique sur le serveur, attendez que Codex l’actualise, puis ouvrez une nouvelle session et répétez la vérification avant de déployer la politique sur d’autres ordinateurs.