Documentation ChatGPT
Français
Contact goolvyouyou@gmail.com

Maintenir l’authentification du compte Codex dans les pipelines CI/CD (avancé)

Utilisez le mécanisme d’actualisation intégré de Codex pour maintenir le fonctionnement d’auth.json sur des exécuteurs CI/CD de confiance

Ce guide explique comment maintenir le fonctionnement de l’authentification Codex gérée par ChatGPT sur un exécuteur CI/CD de confiance sans appeler vous-même le point de terminaison du jeton OAuth.

La méthode appropriée pour authentifier une automatisation consiste à utiliser une API key. N’utilisez ce guide que si vous devez expressément exécuter le workflow avec votre compte Codex.

Le principe est le suivant :

  1. Créez auth.json une seule fois sur une machine de confiance avec codex login.
  2. Placez ce fichier sur l’exécuteur.
  3. Exécutez Codex normalement.
  4. Laissez Codex actualiser la session lorsqu’elle devient obsolète.
  5. Conservez le fichier auth.json actualisé pour l’exécution suivante.

Il s’agit d’un workflow avancé destiné aux entreprises et aux autres automatisations privées de confiance. Les API keys restent l’option recommandée pour la plupart des tâches CI/CD.

Pourquoi cela fonctionne

Codex sait déjà comment actualiser une session gérée par ChatGPT.

Dans la version actuelle du client open source :

  • Codex charge le cache d’authentification local depuis auth.json
  • si last_refresh date de plus de 8 jours environ, Codex actualise le jeu de jetons avant la poursuite de l’exécution
  • après une actualisation réussie, Codex réécrit les nouveaux jetons et un nouveau last_refresh dans auth.json
  • si une requête reçoit un 401, Codex dispose également d’un mécanisme intégré d’actualisation et de nouvelle tentative

Cela signifie que la stratégie CI/CD prise en charge n’est pas « appeler vous-même l’API d’actualisation ». Elle consiste à « exécuter Codex et conserver le fichier auth.json mis à jour ».

Quand utiliser cette méthode

N’utilisez ce guide que lorsque toutes les conditions suivantes sont remplies :

  • vous avez besoin de l’authentification Codex gérée par ChatGPT plutôt que d’une API key
  • codex login ne peut pas s’exécuter sur l’exécuteur distant
  • l’exécuteur appartient à une infrastructure privée de confiance
  • vous pouvez conserver le fichier auth.json actualisé entre les exécutions
  • une seule machine ou un seul flux de tâches sérialisé utilisera une copie donnée de auth.json

Ce guide s’applique à l’authentification ChatGPT gérée par Codex (auth_mode: "chatgpt").

Il ne s’applique pas aux éléments suivants :

  • authentification par API key
  • intégrations hôtes utilisant des jetons externes (auth_mode: "chatgptAuthTokens")
  • clients OAuth génériques externes à Codex

Si vos identifiants sont stockés dans le trousseau du système d’exploitation, passez d’abord à un stockage sur fichier. Consultez Stockage des identifiants.

Initialiser auth.json une seule fois

Sur une machine de confiance où la connexion par navigateur est possible :

  1. Configurez Codex pour stocker les identifiants dans un fichier :
cli_auth_credentials_store = "file"
  1. Exécutez :
codex login
  1. Vérifiez que le fichier correspond à une authentification ChatGPT gérée :
AUTH_FILE="${CODEX_HOME:-$HOME/.codex}/auth.json"

jq '{
  auth_mode,
  has_tokens: (.tokens != null),
  has_refresh_token: ((.tokens.refresh_token // "") != ""),
  last_refresh
}' "$AUTH_FILE"

Ne poursuivez que si :

  • auth_mode vaut "chatgpt"
  • has_refresh_token vaut true

Placez ensuite le contenu de auth.json dans votre gestionnaire de secrets CI/CD ou copiez-le sur un exécuteur persistant de confiance.

Modèle recommandé : GitHub Actions sur un exécuteur auto-hébergé

La configuration entièrement automatisée la plus simple repose sur un exécuteur GitHub Actions auto-hébergé doté d’un CODEX_HOME persistant.

Pourquoi ce modèle fonctionne bien :

  • l’exécuteur peut conserver auth.json sur le disque entre les tâches
  • Codex peut actualiser le fichier sur place
  • les tâches ultérieures utilisent automatiquement les jetons actualisés
  • vous n’avez besoin du secret d’origine que pour l’amorçage ou la réinitialisation

Le point essentiel consiste à initialiser auth.json uniquement s’il est absent. Si vous réécrivez le fichier à partir du secret d’origine à chaque exécution, vous perdez les jetons actualisés que Codex vient d’enregistrer.

Exemple de workflow planifié :

name: Keep Codex auth fresh

on:
  schedule:
    - cron: "0 9 * * 1"
  workflow_dispatch:

jobs:
  keep-codex-auth-fresh:
    runs-on: self-hosted
    steps:
      - name: Bootstrap auth.json if needed
        shell: bash
        env:
          CODEX_AUTH_JSON: ${{ secrets.CODEX_AUTH_JSON }}
        run: |
          export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
          mkdir -p "$CODEX_HOME"
          chmod 700 "$CODEX_HOME"

          if [ ! -f "$CODEX_HOME/auth.json" ]; then
            printf '%s' "$CODEX_AUTH_JSON" > "$CODEX_HOME/auth.json"
            chmod 600 "$CODEX_HOME/auth.json"
          fi

      - name: Run Codex
        shell: bash
        run: |
          codex exec --json "Reply with the single word OK." >/dev/null

Fonctionnement :

  • la première exécution initialise auth.json
  • les exécutions suivantes réutilisent le même fichier
  • lorsque la session en cache devient suffisamment ancienne, Codex l’actualise pendant l’étape normale codex exec
  • le fichier actualisé reste sur le disque pour l’exécution suivante du workflow

Une planification hebdomadaire suffit généralement, car le client open source actuel de Codex considère la session comme obsolète après environ 8 jours.

Exécuteurs éphémères : restaurer, exécuter Codex et conserver le fichier mis à jour

Si vous utilisez des exécuteurs hébergés par GitHub, des exécuteurs partagés GitLab ou tout autre environnement éphémère, le système de fichiers de l’exécuteur disparaît après chaque tâche. Dans cette configuration, vous avez besoin d’un aller-retour :

  1. restaurez le fichier auth.json actuel depuis un stockage sécurisé
  2. exécutez Codex
  3. réenregistrez le fichier auth.json mis à jour dans le stockage sécurisé

Structure générique pour GitHub Actions :

name: Run Codex with managed auth

on:
  workflow_dispatch:

jobs:
  codex-job:
    runs-on: ubuntu-latest
    steps:
      - name: Restore auth.json
        shell: bash
        run: |
          export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
          mkdir -p "$CODEX_HOME"
          chmod 700 "$CODEX_HOME"

          # Replace this with your secret manager or secure storage command.
          my-secret-cli read codex-auth-json > "$CODEX_HOME/auth.json"
          chmod 600 "$CODEX_HOME/auth.json"

      - name: Run Codex
        shell: bash
        run: |
          codex exec --json "summarize the failing tests"

      - name: Persist refreshed auth.json
        if: always()
        shell: bash
        run: |
          # Replace this with your secret manager or secure storage command.
          my-secret-cli write codex-auth-json < "$CODEX_HOME/auth.json"

L’exigence essentielle est que l’étape de réenregistrement stocke le fichier actualisé que Codex a produit pendant l’exécution, et non le fichier d’initialisation d’origine.

Vous n’avez pas besoin d’une commande d’actualisation distincte

Toute exécution normale de Codex peut actualiser la session.

Vous disposez donc de deux bonnes options :

  • laisser votre tâche Codex CI/CD existante actualiser naturellement le fichier
  • ajouter une tâche de maintenance planifiée légère, comme dans l’exemple GitHub Actions ci-dessus, si vos tâches réelles ne s’exécutent pas assez souvent

La première exécution de Codex après l’obsolescence de la session est celle qui actualise auth.json.

Règles opérationnelles importantes

  • Utilisez un fichier auth.json par exécuteur ou par flux de workflow sérialisé.
  • Ne partagez pas le même fichier entre des tâches simultanées ou plusieurs machines.
  • N’écrasez pas à chaque exécution le fichier actualisé d’un exécuteur persistant avec le fichier d’initialisation d’origine.
  • Ne stockez pas auth.json dans le dépôt, les journaux ou un stockage public d’artefacts.
  • Réinitialisez le fichier depuis une machine de confiance si l’actualisation intégrée cesse de fonctionner.

Que faire lorsque l’actualisation ne fonctionne plus

Ce mécanisme réduit les interventions manuelles, mais ne garantit pas que la même session durera indéfiniment.

Réinitialisez l’exécuteur avec un nouveau fichier auth.json si :

  • Codex commence à renvoyer 401 et l’exécuteur ne parvient plus à actualiser la session
  • le jeton d’actualisation a été révoqué ou a expiré
  • une autre machine ou une tâche simultanée a renouvelé le jeton en premier
  • l’aller-retour vers votre stockage sécurisé a échoué et un ancien fichier a été restauré

Pour réinitialiser le fichier :

  1. Exécutez codex login sur une machine de confiance.
  2. Remplacez la copie CI/CD stockée de auth.json.
  3. Laissez la tâche suivante de l’exécuteur continuer à utiliser le mécanisme d’actualisation intégré de Codex.

Vérifier que l’exécuteur maintient la session

Vérifiez que l’exécuteur possède toujours des jetons d’authentification gérée et que last_refresh existe :

AUTH_FILE="${CODEX_HOME:-$HOME/.codex}/auth.json"

jq '{
  auth_mode,
  last_refresh,
  has_access_token: ((.tokens.access_token // "") != ""),
  has_id_token: ((.tokens.id_token // "") != ""),
  has_refresh_token: ((.tokens.refresh_token // "") != "")
}' "$AUTH_FILE"

Si votre exécuteur est persistant, le même fichier doit continuer d’exister entre les exécutions. Si votre exécuteur est éphémère, vérifiez que l’étape de réenregistrement stocke le fichier mis à jour lors de la dernière tâche.

Références des sources

Si vous souhaitez vérifier ce comportement dans le client open source :