Se connecter avec ChatGPT via une passerelle

Pourquoi choisir cette configuration

Si vous disposez déjà d’une passerelle de modèles et utilisez Codex avec l’API Platform, vous pouvez conserver votre passerelle tout en passant à Se connecter avec ChatGPT. Vous accédez ainsi aux fonctionnalités et aux contrôles de l’espace de travail ChatGPT auxquels vous êtes éligible (par exemple, le mode vocal), tout en conservant votre passerelle de modèles. Comparez les méthodes de connexion dans Disponibilité des fonctionnalités.

Comment la configurer

L’authentification par commande existante place la clé de la passerelle dans Authorization. Avec la connexion via ChatGPT, cet en-tête contient le jeton ChatGPT. Choisissez comment fournir les informations d’authentification distinctes de la passerelle :

• Option A : réutilisez votre commande d’obtention des informations d’authentification à l’aide d’un petit utilitaire de lancement. Envoyez la même clé de passerelle dans un en-tête distinct.
• Option B : laissez Codex obtenir les informations d’authentification de la passerelle via OAuth natif.

Ajoutez la configuration du fournisseur choisi au fichier requirements.toml de votre espace de travail, géré dans le cloud, dans Configuration gérée. Ces exigences s’appliquent après la connexion des utilisateurs avec ChatGPT ; elles ne limitent pas les autres méthodes de connexion. L’URL de base de la passerelle compatible avec Codex doit relayer /models et /responses vers https://chatgpt.com/backend-api/codex.

Option A : réutiliser votre commande d’obtention des informations d’authentification avec un utilitaire

Conservez votre commande existante d’obtention des informations d’authentification. Un petit utilitaire l’exécute avant de lancer Codex et exporte sa sortie sous la forme de GATEWAY_KEY. Il s’agit de la même clé de passerelle que celle que vous utilisez aujourd’hui ; seul l’en-tête qui la transmet change.

Par exemple, votre configuration API/fournisseur existante peut contenir :

# config.toml — existing API/provider setup
model_provider = "enterprise_gateway"

[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/v1"
requires_openai_auth = false

[model_providers.enterprise_gateway.auth]
command = "/usr/local/bin/fetch-gateway-token"

Pour la connexion via ChatGPT, remplacez ce fournisseur par la configuration gérée suivante. Supprimez son bloc auth : l’authentification du fournisseur par commande ne peut pas être combinée avec requires_openai_auth = true.

# requirements.toml
model_provider = "enterprise_gateway"

[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.
env_http_headers = { "X-Gateway-Key" = "GATEWAY_KEY" } # Send the same gateway key separately.

Utilisez un utilitaire de lancement tel que cette fonction shell pour la CLI. Remplacez la commande et les arguments par ceux de votre bloc auth existant :

codex_with_gateway() (
  set -eu
  GATEWAY_KEY=$(/usr/local/bin/fetch-gateway-token)
  test -n "$GATEWAY_KEY"
  export GATEWAY_KEY
  exec codex "$@"
)

codex_with_gateway

Configurez votre passerelle pour qu’elle accepte X-Gateway-Key, valide la clé et supprime cet en-tête avant de transmettre la requête au backend. La requête du client contient désormais :

Authorization: Bearer <ChatGPT token>
ChatGPT-Account-ID: <workspace ID, when available>
X-Gateway-Key: <same gateway key returned by your command>

L’utilitaire s’exécute une fois par lancement. Codex ne le réexécute pas et n’actualise pas cet en-tête ; lorsque la clé expire, obtenez-en une nouvelle et relancez Codex. Pour l’application de bureau, votre intégration de lancement doit fournir GATEWAY_KEY au processus de l’application. Choisissez l’option B si vous souhaitez que Codex gère la connexion à la passerelle et le renouvellement des jetons.

Les schémas présentent une version abrégée des en-têtes de requête et de l’utilitaire de lancement. Utilisez Authorization: Bearer <ChatGPT token> et conservez la vérification de clé vide de l’utilitaire dans les exemples ci-dessus. Si GATEWAY_KEY est vide, Codex omet X-Gateway-Key.

Option B : utiliser OAuth natif pour la passerelle

Utilisez cette option pour remplacer la commande et l’utilitaire de lancement par une connexion à la passerelle gérée par Codex. Votre passerelle doit disposer d’un serveur d’autorisation OAuth. Enregistrez un client public qui prend en charge le flux de code d’autorisation avec PKCE, puis remplacez les URL et l’identifiant client de l’exemple. Supprimez le bloc auth du fournisseur existant et utilisez la configuration gérée suivante.

# requirements.toml
model_provider = "enterprise_gateway"

[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.

[model_providers.enterprise_gateway.gateway_oauth] # Add gateway OAuth.
authorization_url = "https://login.example.com/oauth/authorize"
token_url = "https://login.example.com/oauth/token"
client_id = "YOUR_PUBLIC_CLIENT_ID"
delivery = { kind = "cookie", name = "auth-openid" } # Add gateway auth as a cookie.
# redirect_port = 43127

Codex utilise par défaut un port de bouclage libre. Si votre fournisseur d’identité exige une URI de redirection fixe, définissez redirect_port et enregistrez http://127.0.0.1:43127/callback pour cet exemple.

Ajouter des en-têtes de routage (facultatif)

Avec l’une ou l’autre option, Codex peut envoyer des en-têtes de routage personnalisés à la passerelle. Par exemple, ajoutez ces en-têtes au même fournisseur enterprise_gateway dans votre fichier requirements.toml géré dans le cloud :

[model_providers.enterprise_gateway.http_headers]
x-portkey-config = "<gateway-routing-config-id>"
x-portkey-metadata = '{"tool_id":"codex"}'

Codex envoie les en-têtes avec les requêtes au fournisseur de modèles ; la passerelle applique les règles de routage. Utilisez env_http_headers pour les valeurs lues dans l’environnement du processus Codex. Testez une requête pour confirmer que la passerelle reçoit les deux en-têtes et sélectionne la route prévue. Consultez Fournisseurs de modèles personnalisés pour découvrir d’autres options d’en-têtes.

Garder les informations d’authentification sur leurs chemins respectifs

Codex envoie l’en-tête ChatGPT Authorization, tout en-tête ChatGPT-Account-ID, ainsi que l’en-tête ou le cookie de la passerelle. Configurez la passerelle pour qu’elle vérifie et supprime ses propres informations d’authentification, puis transmette les en-têtes ChatGPT sans les modifier.

Points d’attention et limites

• Utilisez une version de Codex qui prend en charge les exigences gérées relatives aux fournisseurs de modèles et, pour l’option B, OAuth natif pour la passerelle. Les versions plus anciennes peuvent ignorer ou rejeter les champs non pris en charge.
• Cette route couvre les requêtes qui passent par le fournisseur de modèles sélectionné. La connexion via ChatGPT, MCP, les plugins et les autres connexions d’applications peuvent emprunter des chemins différents.
• Votre passerelle peut voir les données des requêtes et les deux jeux d’informations d’authentification. Masquez-les dans les journaux ; ne transmettez jamais les informations d’authentification de la passerelle aux services en amont.
• OAuth natif pour la passerelle nécessite un navigateur et une URL de rappel en boucle locale accessible. Il n’offre aucune solution de repli par code d’appareil. Sans jeton d’actualisation, les utilisateurs doivent se reconnecter dans le navigateur à l’expiration du jeton d’accès.
• Une réponse OpenAI /v1/models générique ne suffit pas : Codex attend un tableau models. Testez la liste des modèles, un prompt et chaque fonctionnalité utilisée par votre déploiement.

La voix via une passerelle

Cette configuration achemine les requêtes Codex destinées au fournisseur de modèles ; elle n’active pas ChatGPT Voice. Pour les sessions vocales WebRTC, la création d’appel et la connexion auxiliaire empruntent des routes distinctes. Le paramètre expérimental experimental_realtime_webrtc_call_base_url dans ~/.codex/config.toml modifie uniquement l’URL de base HTTP utilisée pour la création d’appel. Il ne redirige ni la connexion auxiliaire, ni les médias, ni les requêtes ordinaires aux modèles. Travaillez avec OpenAI pour vérifier la destination des appels et le traitement des informations d’authentification avant d’utiliser ce paramètre de remplacement, puis testez une session vocale complète.

Pour le chemin des informations d’authentification API/fournisseur, consultez Compatibilité des passerelles et Déployer une passerelle. Pour ces paramètres gérés, consultez Configuration gérée et la Référence de configuration.