ChatGPT-Dokumentation
Deutsch
Kontakt goolvyouyou@gmail.com

Codex-Kontoauthentifizierung in CI/CD aufrechterhalten (fortgeschritten)

Verwenden Sie den integrierten Aktualisierungsablauf von Codex, damit auth.json auf vertrauenswürdigen CI/CD-Runnern funktionsfähig bleibt

Dieser Leitfaden zeigt, wie Sie die von ChatGPT verwaltete Codex-Authentifizierung auf einem vertrauenswürdigen CI/CD-Runner funktionsfähig halten, ohne den OAuth-Token-Endpunkt selbst aufzurufen.

Für die Authentifizierung von Automatisierungen ist ein API key die richtige Wahl. Verwenden Sie diesen Leitfaden nur, wenn Sie den Workflow ausdrücklich mit Ihrem Codex-Konto ausführen müssen.

Das Vorgehen sieht wie folgt aus:

  1. Erstellen Sie auth.json einmalig auf einem vertrauenswürdigen Computer mit codex login.
  2. Legen Sie diese Datei auf dem Runner ab.
  3. Führen Sie Codex wie gewohnt aus.
  4. Lassen Sie Codex die Sitzung aktualisieren, sobald sie veraltet ist.
  5. Bewahren Sie die aktualisierte Datei auth.json für den nächsten Lauf auf.

Dies ist ein fortgeschrittener Workflow für Unternehmen und andere vertrauenswürdige private Automatisierungsumgebungen. API keys werden weiterhin für die meisten CI/CD-Aufträge empfohlen.

Warum dies funktioniert

Codex kann eine von ChatGPT verwaltete Sitzung bereits selbst aktualisieren.

Im aktuellen Open-Source-Client gilt:

  • Codex lädt den lokalen Authentifizierungscache aus auth.json
  • wenn last_refresh älter als ungefähr 8 Tage ist, aktualisiert Codex das Token-Paket, bevor der Lauf fortgesetzt wird
  • nach einer erfolgreichen Aktualisierung schreibt Codex die neuen Token und einen neuen last_refresh zurück nach auth.json
  • wenn eine Anfrage einen 401 erhält, verfügt Codex außerdem über einen integrierten Ablauf zum Aktualisieren und erneuten Versuchen

Die unterstützte CI/CD-Strategie lautet daher nicht „Rufen Sie die Aktualisierungs-API selbst auf“. Sie lautet: „Führen Sie Codex aus und speichern Sie die aktualisierte Datei auth.json dauerhaft.“

Wann Sie dieses Verfahren verwenden sollten

Verwenden Sie diesen Leitfaden nur, wenn alle folgenden Bedingungen erfüllt sind:

  • Sie benötigen eine von ChatGPT verwaltete Codex-Authentifizierung anstelle eines API key
  • codex login kann auf dem Remote-Runner nicht ausgeführt werden
  • der Runner ist eine vertrauenswürdige private Infrastruktur
  • Sie können die aktualisierte Datei auth.json zwischen Läufen aufbewahren
  • nur ein Computer oder ein serialisierter Auftragsstrom verwendet jeweils eine bestimmte Kopie von auth.json

Dieser Leitfaden gilt für die von Codex verwaltete ChatGPT-Authentifizierung (auth_mode: "chatgpt").

Er gilt nicht für:

  • Authentifizierung per API key
  • Host-Integrationen mit externen Token (auth_mode: "chatgptAuthTokens")
  • generische OAuth-Clients außerhalb von Codex

Wenn Ihre Anmeldedaten im Schlüsselbund des Betriebssystems gespeichert sind, wechseln Sie zunächst zur dateibasierten Speicherung. Weitere Informationen finden Sie unter Speicherung von Anmeldedaten.

auth.json einmalig als Ausgangsdatei erstellen

Auf einem vertrauenswürdigen Computer, auf dem die Browseranmeldung möglich ist:

  1. Konfigurieren Sie Codex so, dass Anmeldedaten in einer Datei gespeichert werden:
cli_auth_credentials_store = "file"
  1. Führen Sie Folgendes aus:
codex login
  1. Prüfen Sie, ob die Datei wie eine verwaltete ChatGPT-Authentifizierung aussieht:
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"

Fahren Sie nur fort, wenn:

  • auth_mode den Wert "chatgpt" hat
  • has_refresh_token den Wert true hat

Übertragen Sie anschließend den Inhalt von auth.json in Ihre CI/CD-Geheimnisverwaltung oder kopieren Sie ihn auf einen vertrauenswürdigen persistenten Runner.

Empfohlenes Muster: GitHub Actions auf einem selbst gehosteten Runner

Die einfachste vollständig automatisierte Einrichtung ist ein selbst gehosteter GitHub Actions-Runner mit einem persistenten CODEX_HOME.

Warum dieses Muster gut funktioniert:

  • der Runner kann auth.json zwischen Aufträgen auf dem Datenträger behalten
  • Codex kann die Datei direkt aktualisieren
  • spätere Aufträge übernehmen die aktualisierten Token automatisch
  • Sie benötigen das ursprüngliche Geheimnis nur zur Ersteinrichtung oder erneuten Initialisierung

Entscheidend ist, auth.json nur dann mit der Ausgangsdatei zu befüllen, wenn die Datei fehlt. Wenn Sie die Datei bei jedem Lauf mit dem ursprünglichen Geheimnis überschreiben, verwerfen Sie die aktualisierten Token, die Codex gerade gespeichert hat.

Beispiel für einen geplanten Workflow:

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

Dieser Workflow bewirkt Folgendes:

  • beim ersten Lauf wird auth.json mit der Ausgangsdatei befüllt
  • spätere Läufe verwenden dieselbe Datei erneut
  • sobald die zwischengespeicherte Sitzung alt genug ist, aktualisiert Codex sie während des normalen Schritts codex exec
  • die aktualisierte Datei verbleibt für den nächsten Workflow-Lauf auf dem Datenträger

Ein wöchentlicher Zeitplan reicht normalerweise aus, da Codex die Sitzung im aktuellen Open-Source-Client nach ungefähr 8 Tagen als veraltet behandelt.

Flüchtige Runner: Wiederherstellen, Codex ausführen und die aktualisierte Datei dauerhaft speichern

Wenn Sie von GitHub gehostete Runner, gemeinsam genutzte GitLab-Runner oder eine andere flüchtige Umgebung verwenden, wird das Dateisystem des Runners nach jedem Auftrag verworfen. In dieser Konfiguration ist ein vollständiger Hin- und Rücklauf erforderlich:

  1. Stellen Sie die aktuelle Datei auth.json aus einem sicheren Speicher wieder her
  2. führen Sie Codex aus
  3. schreiben Sie die aktualisierte Datei auth.json in den sicheren Speicher zurück

Generischer Aufbau für 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"

Entscheidend ist, dass der Rückschreibeschritt die aktualisierte Datei speichert, die Codex während des Laufs erzeugt hat, und nicht die ursprüngliche Ausgangsdatei.

Sie benötigen keinen separaten Aktualisierungsbefehl

Jeder normale Codex-Lauf kann die Sitzung aktualisieren.

Damit stehen Ihnen zwei gute Möglichkeiten zur Verfügung:

  • Lassen Sie Ihren vorhandenen CI/CD-Auftrag mit Codex die Datei automatisch aktualisieren
  • Fügen Sie einen schlanken geplanten Wartungsauftrag wie im obigen GitHub Actions-Beispiel hinzu, wenn Ihre eigentlichen Aufträge nicht häufig genug ausgeführt werden

Der erste Codex-Lauf, nachdem die Sitzung veraltet ist, aktualisiert auth.json.

Wichtige Betriebsregeln

  • Verwenden Sie eine Datei auth.json pro Runner oder pro serialisiertem Workflow-Strom.
  • Verwenden Sie dieselbe Datei nicht gleichzeitig in mehreren Aufträgen oder auf mehreren Computern.
  • Überschreiben Sie die aktualisierte Datei eines persistenten Runners nicht bei jedem Lauf mit der ursprünglichen Ausgangsdatei.
  • Speichern Sie auth.json weder im Repository noch in Protokollen oder öffentlichen Artefaktspeichern.
  • Initialisieren Sie die Datei erneut von einem vertrauenswürdigen Computer aus, wenn die integrierte Aktualisierung nicht mehr funktioniert.

Vorgehen, wenn die Aktualisierung nicht mehr funktioniert

Dieser Ablauf reduziert den manuellen Aufwand, garantiert jedoch nicht, dass dieselbe Sitzung unbegrenzt gültig bleibt.

Initialisieren Sie den Runner mit einer neuen Datei auth.json, wenn:

  • Codex beginnt, 401 zurückzugeben, und der Runner die Sitzung nicht mehr aktualisieren kann
  • das Aktualisierungstoken widerrufen wurde oder abgelaufen ist
  • ein anderer Computer oder ein gleichzeitig ausgeführter Auftrag das Token zuerst rotiert hat
  • der Hin- und Rücklauf zu Ihrem sicheren Speicher fehlgeschlagen ist und eine alte Datei wiederhergestellt wurde

So initialisieren Sie die Datei erneut:

  1. Führen Sie codex login auf einem vertrauenswürdigen Computer aus.
  2. Ersetzen Sie die in CI/CD gespeicherte Kopie von auth.json.
  3. Lassen Sie den nächsten Runner-Auftrag weiterhin den integrierten Aktualisierungsablauf von Codex verwenden.

Prüfen, ob der Runner die Sitzung aufrechterhält

Prüfen Sie, ob der Runner weiterhin verwaltete Authentifizierungstoken besitzt und ob last_refresh vorhanden ist:

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"

Wenn Ihr Runner persistent ist, sollte dieselbe Datei zwischen den Läufen weiterhin vorhanden sein. Wenn Ihr Runner flüchtig ist, prüfen Sie, ob der Rückschreibeschritt die aktualisierte Datei aus dem letzten Auftrag speichert.

Quellenverweise

Wenn Sie dieses Verhalten im Open-Source-Client überprüfen möchten:

  • codex-rs/core/src/auth.rs behandelt die Erkennung veralteter Token, die automatische Aktualisierung, die Wiederherstellung durch Aktualisieren nach einem 401-Fehler sowie die dauerhafte Speicherung aktualisierter Token
  • codex-rs/core/src/auth/storage.rs behandelt die dateibasierte Speicherung von auth.json