Zugriffstokens

Codex-Zugriffstokens sind Anmeldedaten eines ChatGPT-Arbeitsbereichs, deren Geltungsbereich auf Codex-Berechtigungen beschränkt ist. Sie authentifizieren vertrauenswürdige, nicht interaktive lokale Workflows, darunter Codex CLI und App-Server-basierte Automatisierungen, mit einer ChatGPT-Arbeitsbereichsidentität. Verwenden Sie sie, wenn ein Skript, ein geplanter Auftrag oder ein CI-Runner wiederholbaren lokalen Zugriff benötigt.

Erstellen Sie persönliche Zugriffstokens in der ChatGPT-Administrationskonsole unter Access tokens. Jedes Token gehört der Person, die es erstellt hat, und dem ChatGPT-Workspace dieser Person. Tokens dienen bei programmatischen lokalen Workflows als Agentenidentitäten. Informationen zu Tokens, die über die Detailseite einer dedizierten nicht menschlichen Workspace-Identität erstellt werden, finden Sie unter Dienstkonten.

Funktionsweise von Zugriffstokens

Verwenden Sie ein Zugriffstoken, wenn Codex CLI oder ein App-Server-Client ohne eine vom Benutzer abgeschlossene Browseranmeldung ausgeführt werden muss. Das Token repräsentiert den ChatGPT-Arbeitsbereichsbenutzer, der es erstellt hat. Deshalb können Ausführungen dessen Zugriff verwenden und in den Governance-Daten des Arbeitsbereichs erscheinen.

Der Client prüft das Token beim Start einer Ausführung und verknüpft die Ausführung mit dieser Workspace-Identität. Behandeln Sie das Token wie jedes andere Automatisierungsgeheimnis: Speichern Sie es in einem Geheimnismanager, halten Sie es aus Protokollen heraus und rotieren Sie es gemäß den Richtlinien Ihrer Organisation.

Verwenden Sie Zugriffstokens für:

• codex exec-Jobs, die über eine vertrauenswürdige Automatisierung ausgeführt werden.
• Lokale Skripte, die wiederholbare, nicht interaktive Ausführungen von Codex CLI benötigen.
• Vertrauenswürdige App-Server-basierte Automatisierung.
• Unternehmensworkflows, die die Nutzung einem ChatGPT-Workspace-Benutzer statt dem Schlüssel einer API-Organisation zuordnen.

Zu vermeidende Hauptrisiken:

• Offengelegte Geheimnisse: Jeder, der über das Token verfügt, kann über Codex CLI oder einen App-Server-Client lokale Ausführungen im Namen der Person starten, die das Token erstellt hat. Speichern Sie Tokens in einem Geheimnismanager, halten Sie sie aus Protokollen heraus und rotieren Sie sie gemäß den Richtlinien Ihrer Organisation.
• Vertrauenswürdigkeit des Runners: Öffentliche CI, Pull Requests aus Forks oder gemeinsam genutzte Computer können Tokens gegenüber Personen außerhalb Ihres Workspace offenlegen. Verwenden Sie Zugriffstokens nur auf vertrauenswürdigen Runnern.
• Gemeinsam genutzte Identitäten: Wenn das Token einer Person in voneinander unabhängigen Teams wiederverwendet wird, sind Eigentümerschaft und Audit-Trails weniger eindeutig. Erstellen Sie Tokens jeweils für einen bestimmten Workflow-Verantwortlichen.
• Veraltete Anmeldedaten: Langlebige Tokens können aktiv bleiben, nachdem sich der Workflow geändert hat. Bevorzugen Sie zeitlich begrenzte Tokens und widerrufen Sie Tokens, die nicht mehr verwendet werden.
• Falscher Scope oder Anmeldedatentyp: Die Codex-Automatisierung erfordert Codex-Zugriff, das Auslösen von Workspace-Agenten erfordert Zugriff auf Workspace Agents und allgemeine OpenAI-API-Aufrufe erfordern Platform API keys. Wenn Bereiche angezeigt wird, gewähren Sie nur die Berechtigungen, die der Workflow benötigt.

Erstellung von Zugriffstokens aktivieren

Aktivieren Sie über die Zugriffstokenberechtigung in den Arbeitsbereichseinstellungen die Erstellung von Zugriffstokens für berechtigte Mitglieder.

Die Zugriffstokenberechtigung steuert die Erstellung von Tokens. Sie gewährt keinen Zugriff auf die ChatGPT-Desktop-App, Codex CLI oder die IDE-Erweiterung und ändert weder den Lizenztyp oder die integrierte Workspace-Rolle eines Mitglieds noch dessen lokales Laufzeitberechtigungsprofil. Mit Tokens authentifizierte Workflows von Codex CLI und App-Server-Workflows erfordern außerdem die lokale Codex-Berechtigung des Benutzers.

Informationen zum Zusammenhang zwischen diesen Kontrollen finden Sie unter Rollen und Arbeitsbereichsberechtigungen.

1. Lassen Sie einen Workspace-Eigentümer Workspace settings > Permissions & roles öffnen.
2. Wenn der Bereich Access tokens angezeigt wird, aktivieren Sie Allow users to create personal access tokens. Wenn dieser Bereich nicht verfügbar ist, aktivieren Sie Allow members to use Codex access tokens unter Codex and Work Local oder Codex Local.
3. Aktivieren Sie die entsprechende lokale Codex-Berechtigung für den Workflow-Verantwortlichen: Allow members to use Codex and Work Locally unter Codex and Work Local oder Allow members to use Codex locally unter Codex Local. Wenn Work Local einen eigenen Bereich hat, steuert Use Work locally den Zugriff auf Work und ist für Codex-Tokens nicht erforderlich.

Erlauben Sie nur Personen oder Dienstverantwortlichen das Erstellen von Zugriffstokens, die den Speicherort des Tokens, die vorgesehene Automatisierung und den Rotationsplan kennen.

Durch das Deaktivieren der lokalen Codex-Berechtigung werden aktive Codex-Tokens der betroffenen Mitglieder ausgesetzt, jedoch nicht widerrufen. Wenn der lokale Codex-Zugriff wiederhergestellt wird, werden diese Tokens reaktiviert. Widerrufen Sie Tokens, wenn der Zugriff dauerhaft beendet werden muss.

Ablaufgrenze für Zugriffstokens festlegen

Ein Workspace-Eigentümer kann das längste Gültigkeitsfenster festlegen, das Mitglieder für neue Zugriffstokens auswählen können. Öffnen Sie Workspace settings > Permissions & roles. Wenn der Bereich Access tokens angezeigt wird, legen Sie dort Access token expiration limit fest. Suchen Sie andernfalls unter Codex and Work Local oder Codex Local nach dieser Einstellung.

Das Limit gilt für neue Zugriffstokens. Bestehende Tokens behalten ihr derzeitiges Gültigkeitsfenster.

Zugriffstoken erstellen

Benennen Sie das Token auf der Seite Access tokens, prüfen Sie alle verfügbaren Produktberechtigungsbereiche und wählen Sie ein geeignetes Gültigkeitsfenster aus.

1. Wechseln Sie zu Zugriffstokens.
2. Wählen Sie Erstellen.

3. Geben Sie einen aussagekräftigen Namen ein, beispielsweise release-ci oder nightly-docs-check.

4. Wenn das Dialogfeld Bereiche anzeigt, wählen Sie Codex aus. Wählen Sie Workspace Agents nur aus, wenn derselbe Workflow auch einen Workspace-Agent auslösen muss. Wenn das Dialogfeld keine Bereichsauswahl enthält, wird ein reines Codex-Token erstellt.
5. Wählen Sie einen begrenzten Gültigkeitszeitraum aus, beispielsweise 7, 30, 60 oder 90 Tage. Bereichsgebundene persönliche Zugriffstokens müssen ablaufen. Ein älteres, ausschließlich für Codex vorgesehenes Dialogfeld kann Kein Ablaufdatum anbieten. Vermeiden Sie diese Option, sofern Ihre Organisation sie nicht genehmigt und das Token nach einem festgelegten Zeitplan rotiert.
6. Wählen Sie Erstellen aus.
7. Kopieren Sie das generierte Zugriffstoken sofort. Nachdem Sie das Dialogfeld geschlossen haben, können Sie es nicht erneut anzeigen.
8. Speichern Sie das Token in Ihrem Secret Manager oder CI-Secretspeicher.

Der kürzeste benutzerdefinierte Gültigkeitszeitraum beträgt einen Tag. Mit widerrufenen oder abgelaufenen Tokens können Sie keine neuen authentifizierten Ausführungen starten.

Zugriffstoken mit Codex CLI verwenden

Wenn im Dialogfeld zur Token-Erstellung eine erforderliche Codex CLI-Version aufgeführt ist, aktualisieren Sie die CLI auf diese oder eine neuere Version, bevor Sie das Token verwenden.

Speichern Sie das Token für kurzlebige Automatisierungen in CODEX_ACCESS_TOKEN und führen Sie Codex CLI wie gewohnt aus:

export CODEX_ACCESS_TOKEN="<access-token>"
codex exec --json "review this repository and summarize the top risks"

Leiten Sie das Token für eine dauerhafte lokale Anmeldung an codex login --with-access-token weiter:

printf '%s' "$CODEX_ACCESS_TOKEN" | codex login --with-access-token
codex exec "summarize the last release diff"

codex login --with-access-token speichert die Anmeldedaten einer Agentenidentität im Authentifizierungsspeicher von Codex CLI. Wenn Sie keine Anmeldedaten dauerhaft auf dem Computer speichern möchten, verwenden Sie stattdessen die Umgebungsvariable CODEX_ACCESS_TOKEN.

codex app-server kann für die Authentifizierung seiner OpenAI-Anfragen dieselben Anmeldedaten über CODEX_ACCESS_TOKEN oder eine mit codex login --with-access-token erstellte Anmeldung verwenden. Diese Anmeldedaten sind von der Client-zu-App-Server-Transportauthentifizierung getrennt. Konfigurieren Sie für eine Remote-WebSocket-Verbindung ein separates Bearer- oder Capability-Token, wie unter App-Server beschrieben. Verwenden Sie das Codex-Zugriffstoken nicht als Transporttoken. Siehe Umgebungsvariablen für Authentifizierung und Netzwerk.

Token rotieren oder widerrufen

Rotieren Sie Zugriffstokens genauso wie andere Automatisierungsgeheimnisse:

1. Erstellen Sie ein Ersatztoken.
2. Aktualisieren Sie das Geheimnis im Runner, Scheduler oder Geheimnismanager.
3. Führen Sie mit dem neuen Token einen Smoke-Test durch.
4. Widerrufen Sie das alte Token unter Zugriffstokens.

Auf der Seite „Zugriffstokens“ können Arbeitsbereichseigentümer und -administratoren jedes Token des Arbeitsbereichs widerrufen. Mitglieder mit Zugriffstokenberechtigung können nur die von ihnen erstellten Tokens widerrufen.

Berechtigungsmodell

Die Zugriffstoken-Berechtigung des Workspace steuert die Token-Erstellung. Je nach Aufbau des Workspace steuert Mitgliedern die lokale Nutzung von Codex und Work erlauben unter Codex und Work Local oder Mitgliedern die lokale Nutzung von Codex erlauben unter Codex Local den lokalen Codex-Zugriff. Wenn Work Local einen eigenen Abschnitt hat, steuert Work lokal verwenden den Zugriff auf Work und gewährt keinen Codex-Zugriff. Ein Mitglied benötigt sowohl lokalen Codex-Zugriff als auch die Zugriffstoken-Berechtigung für tokenauthentifizierte Codex-Workflows. Ein Mitglied kann lokalen Codex-Zugriff haben, ohne zum Erstellen von Zugriffstokens berechtigt zu sein.

Kurz gesagt: Arbeitsbereichseigentümer und -administratoren verwalten den Zugriff auf Arbeitsbereichsebene. Mitglieder benötigen die Zugriffstokenberechtigung, um eigene Tokens zu erstellen und zu verwalten. Diese Berechtigung gewährt jedoch weder Administratorrechte noch Zugriff auf die Tokens anderer Mitglieder.

Fehlerbehebung

Die Seite „Zugriffstokens“ gibt 404 oder „Verboten“ zurück

Bitten Sie einen Workspace-Inhaber, zu bestätigen, dass Ihre Rolle je nach verfügbarer Oberfläche Benutzern das Erstellen persönlicher Zugriffstokens erlauben oder Mitgliedern die Verwendung von Codex-Zugriffstokens erlauben umfasst. Vergewissern Sie sich bei einem tokenauthentifizierten Codex-Workflow außerdem, dass Mitgliedern die lokale Nutzung von Codex und Work erlauben oder Mitgliedern die lokale Nutzung von Codex erlauben aktiviert ist.

codex login --with-access-token schlägt fehl

Vergewissern Sie sich, dass Sie das generierte Zugriffstoken kopiert haben und nicht ein Browser-Sitzungstoken oder einen Platform API key. Vergewissern Sie sich außerdem, dass das Token aktiv und nicht abgelaufen ist und einem Benutzer mit der erforderlichen lokalen Codex-Berechtigung gehört.

Verwandte Dokumentation

• Authentifizierung
• Dienstkonten
• Nicht interaktiver Modus
• Leitfaden für die Einführung durch Administratoren
• Gruppen und Bereitstellung
• Verwaltung des Benutzerlebenszyklus
• Rollen und Workspace-Berechtigungen
• Governance