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_managedcontient les paramètres par défaut à appliquer. Le champcontentsde chaque entrée contient du texte au formatconfig.toml.requirements_toml.enterprise_managedcontient les exigences à faire respecter. Le champcontentsde chaque entrée contient du texte au formatrequirements.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
- 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. - À l’invite interactive de Codex CLI, saisissez
/debug-config, puis appuyez sur Entrée. - 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). - 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.