Codex im Team einführen: Ein Praxisleitfaden zu Berechtigungen, Konventionen und dem Bedrock-Pfad

Wenn ein Team Codex gemeinsam einführt, kommt die erste Frage von Security und Operations meist nicht auf das Preismodell. Sie lautet eher: Wer bekommt Full Access, was darf .env lesen und wo sehen wir Nutzung und Audit-Logs? Diese Fragen bestimmen den ersten Schritt beim Team-Rollout. Die Antwort ist nicht, zuerst einen API Key zu wählen. Die Antwort ist, zuerst die Berechtigungsgrenze festzulegen. Dieser Artikel liefert einen Entscheidungsrahmen für den Unternehmenseinsatz: requirements.toml und Permission Profiles definieren die Rechte der Mitglieder, gemeinsame AGENTS.md-Regeln vereinheitlichen die Arbeitsweise, danach wählen Sie einen Pfad wie ChatGPT Workspace, API Key oder Amazon Bedrock, und am Ende verbinden Sie Analytics und Compliance. Ein Punkt sollte von Anfang an klar sein: AWS hat am 2026-06-03 die Verfügbarkeit von GPT-5.4 in GovCloud angekündigt, aber der Codex Bedrock Provider unterstützt derzeit keine GovCloud-Endpunkte. Das sind zwei unterschiedliche Fakten.

1. Framework für Unternehmensberechtigungen: Full Access darf nicht auf jedem lokalen Rechner landen

Wenn ein Unternehmen Codex standardisieren will, kann es cloud-managed requirements nutzen, um das lokale Verhalten zu begrenzen. requirements.toml ist die Policy-Konfigurationsdatei für Codex. Administratoren können je nach Benutzergruppe unterschiedliche Policies zuweisen, statt jedem Mitglied seine eigene Umgebung zu überlassen.

1.1 Wichtige Felder in requirements.toml

Die folgenden Felder werden in der Praxis am häufigsten verwendet:

Feld	Zweck	Empfohlener Wert
approval_policy	Steuert, ob menschliche Freigabe nötig ist	"suggest" oder "auto-edit"; "never" nicht als Team-Standard verwenden
approvals_reviewer	Legt fest, wer freigibt	Team-Owner oder Security-Owner
automatic_review_policy	Regeln für automatische Reviews	Nach Projektrisiko festlegen
permission profiles	Neueres Berechtigungsmodell (0.138.0+)	Für neue Rollouts empfohlen
sandbox_mode	Älteres Berechtigungsmodell	Nur für Legacy-Migrationen nutzen
web_search_mode	Ob Websuche erlaubt ist	Optional, bei sensiblen Projekten einschränken
managed_hooks	Einheitliche Hook-Konfiguration	lint-check, test-runner und ähnliche Hooks
MCP servers allowlist	Welche MCP-Server genutzt werden dürfen	Nur freigegebene Server wie filesystem und github

Codex 0.138.0 und höher empfiehlt Permission Profiles mit allowed_permission_profiles und default_permissions. Ältere Installationen sollten weiterhin allowed_sandbox_modes nutzen.

1.2 Verbotene Kombinationen

Die folgende Kombination darf nicht als Team-Standard verwendet werden:

danger-full-access + approval_policy = "never"

Das ist die Kombination mit höchster Berechtigung und ohne Freigabe. Sie sollte in cloud-managed requirements blockiert werden, damit sie nicht in lokalen Einzelkonfigurationen auftaucht.

1.3 Konfigurationsbeispiel

# requirements.toml
[managed]
approval_policy = "suggest"
allowed_permission_profiles = ["suggest", "auto-edit"]
default_permissions = "suggest"

[mcp]
allowed_servers = ["filesystem", "github"]

[hooks]
managed_hooks = ["lint-check", "test-runner"]

Dieses Beispiel begrenzt Mitglieder auf "suggest" oder "auto-edit", setzt "suggest" als Standard, erlaubt für MCP nur filesystem und github und hält den Hook-Satz konsistent. Wenn Sie einer Kernentwicklungsgruppe "auto-edit" geben und Praktikanten auf "suggest" lassen wollen, ist das der richtige Ort dafür.

2. Least Privilege und Sandbox-Design: konkrete Regeln, Deny-Globs und Schutz sensibler Dateien

Security-Verantwortliche brauchen kein Schlagwort zu Least Privilege. Sie brauchen konkrete Regeln: Welche Dateien dürfen gelesen werden, welche dürfen geschrieben werden und was ist vollständig gesperrt?

2.1 Drei filesystem-Werte

Codex kennt für filesystem drei Werte:

• read: nur lesen, keine Änderungen
• write: lesen und schreiben, Änderungen erlaubt
• deny: vollständig blockiert

Die Prioritätsregel ist einfach: Spezifischere Regeln gewinnen, und deny hat die höchste Priorität. Wenn Sie zum Beispiel sowohl "**/*.env" = "deny" als auch ":workspace_roots" = "write" konfigurieren, bleiben .env-Dateien gesperrt, auch wenn der Workspace-Root schreibbar ist.

2.2 Begrenzung des Workspace-Bereichs

Nutzen Sie :workspace_roots, um den Arbeitsbereich einzuschränken:

[permissions.filesystem]
":workspace_roots" = "write"

Damit kann Codex nur innerhalb des aktuellen Workspace-Roots und seiner Unterordner arbeiten. Dateien außerhalb dieses Bereichs sind nicht erreichbar.

2.3 Schutz sensibler Dateien

Mit Deny-Globs können Sie Umgebungsdateien und Secret-Verzeichnisse zuverlässig schützen:

[permissions.filesystem]
":workspace_roots" = "write"
"**/*.env" = "deny"
"**/secrets/**" = "deny"
"**/*.log" = "read"

Das bedeutet:

• der Workspace-Root und seine Unterordner sind schreibbar
• alle .env-Dateien sind überall gesperrt
• secrets/ und ihre Unterordner sind gesperrt
• .log-Dateien sind nur lesbar

2.4 Netzwerkberechtigung

Netzwerkzugriff kann per Domain-Allow/Deny gesteuert werden:

[permissions.network]
enabled = true
allow = ["github.com", "api.openai.com"]
deny = ["localhost", "127.0.0.1"]

So erreicht Codex github.com und api.openai.com, während localhost und Loopback blockiert sind. Für lokale und private Netze gibt es zusätzliche Schutzmechanismen, sodass Teams auch eigene Domain-Listen definieren können.

2.5 permission profiles versus sandbox mode

Vergleich	Permission Profiles	Sandbox Mode
Release-Stufe	Neueres Modell	Älteres Modell
Granularität	Feiner	Grober
Konfigurationsfelder	allowed_permission_profiles + default_permissions	allowed_sandbox_modes
Empfehlung	Für neue Rollouts bevorzugen	Vor allem für Legacy-Migrationen

Neue Rollouts sollten Permission Profiles bevorzugen. Sandbox Mode kann schrittweise abgelöst werden.

3. Gemeinsame Team-Konventionen: ein AGENTS.md, nicht ein eigenes File pro Person

Teams brauchen einen gemeinsamen Prompt, gemeinsame Kontextregeln und gemeinsame Review-Instruktionen. Sie brauchen nicht, dass jede Person ihre eigene Version pflegt und die Wartung auf viele Dateien verteilt. AGENTS.md ist Codex’ Instruktionsdatei. Sie unterstützt gestufte Regeln und Prioritäten.

3.1 Reihenfolge der Instruktionskette

Wenn Codex startet, baut es diese Kette auf:

globale Regeln (~/.config/codex/AGENTS.md)
  -> Projektregeln (project AGENTS.md)
  -> Regeln aus dem nächstliegenden Verzeichnis

Die näher liegende Datei gewinnt bei Überschneidungen.

3.2 Gestufte Architektur

Packen Sie nicht alle Regeln in eine einzige Riesendatei. Arbeiten Sie in Schichten:

• ~/.config/codex/AGENTS.md: globale Regeln, Stil, Test-Erwartungen, generelle Verbote
• Projekt-AGENTS.md: Architektur, Abhängigkeiten, Deployment-Stil
• Modul-AGENTS.md: modulbezogene Anforderungen

Jede Schicht sollte etwa 10-15 KiB groß bleiben, damit die Wartung beherrschbar bleibt und keine Kürzungen entstehen.

3.3 Umgang mit dem 32-KiB-Limit

Codex setzt project_doc_max_bytes standardmäßig auf 32 KiB. Wenn AGENTS.md zu groß wird, kann es gekürzt werden.

Es gibt zwei Wege damit umzugehen:

1. project_doc_max_bytes erhöhen
2. das Dokument in verschachtelte Verzeichnisse aufteilen

Das Aufteilen ist meist besser, weil Zuständigkeiten und Wartung klarer bleiben.

3.4 Wofür AGENTS.override.md gedacht ist

AGENTS.override.md überschreibt das übergeordnete AGENTS.md und hat die höchste Priorität. Verwenden Sie es, wenn:

• ein bestimmtes Unterverzeichnis vorübergehend andere Regeln braucht
• ein experimentelles Modul lockerere Grenzen benötigt
• ein Modul von der Projektpolitik abweicht

Dokumentieren Sie den Grund für die Abweichung, damit das Team nicht ins Schleudern gerät.

3.5 Wartungsempfehlung für Teams

Wenn Sie AGENTS.md pflegen, sollten Sie klar benennen:

• Ownership: Wer pflegt welche Schicht?
• Wartungsbudget: Wie viel Review-Zeit bekommt jedes Sprint?
• Review-Zyklus: Wie oft werden globale und Projektregeln geprüft?

So wird AGENTS.md zu einer lebenden gemeinsamen Referenz statt zu einer privaten Datei, die jede Person neu schreibt.

4. Wahl des Bereitstellungspfads: ChatGPT Workspace, API Key oder Bedrock?

Organisationen müssen entscheiden, welchen Abrechnungs-, Compliance- und Kontrollpfad sie wählen. Die drei Wege haben unterschiedliche Vorteile, Grenzen und Einsatzszenarien.

4.1 Vergleichstabelle

Dimension	ChatGPT Business/Enterprise	API Key	Amazon Bedrock
Authentifizierung	ChatGPT Sign-in	OPENAI_API_KEY	Bedrock API Key oder AWS IAM
Rechnungsinhaber	OpenAI Workspace	OpenAI API Account	AWS-Konto
Team-Governance	Analytics Dashboard, managed requirements	Keine native Team-Governance	AWS IAM und CloudTrail
Funktionsumfang	Am vollständigsten	Am flexibelsten	Teilweiser Funktionssatz (siehe 4.2)
Compliance / Region	OpenAI-Regionen	OpenAI-Regionen	AWS-Regionen und Data Residency
GovCloud-Unterstützung	Nein	Nein	Modell möglicherweise verfügbar, Provider-Unterstützung getrennt betrachten (siehe 4.3)
Geeignet für	Kleine/mittlere Teams mit Workspace-Verwaltung	Entwickler mit flexibler Integration	AWS-zentrierte Teams mit Billing, IAM und Compliance-Kontrollen

4.2 Fehlende Bedrock-Fähigkeiten

Stand 2026-06-08 sind folgende Funktionen auf diesem Pfad nicht verfügbar:

• Fast Mode
• gehostete Web-/Dateisuche
• Computer Use
• Shell Tool
• Bildgenerierung
• Remote-MCP-Server
• On-demand inference only ist nicht unterstützt; verwenden Sie stattdessen Provisioned Throughput

Diese Fähigkeiten hängen von OpenAI-gehosteten Cloud-Services, gehosteten Tools oder cloud-managed discovery ab und liegen daher außerhalb dieses Pfads. Wenn Ihr Team darauf angewiesen ist, nehmen Sie stattdessen ChatGPT Workspace oder API Key.

4.3 GovCloud-Klärung

Hier müssen Sie zwei Fakten auseinanderhalten:

1. AWS GPT-5.4 in GovCloud (US-West) ist verfügbar

   • das Modell selbst ist in GovCloud verfügbar
   • GPT-5.4 kann über die Bedrock API aufgerufen werden

2. Der Codex Bedrock Provider unterstützt keine GovCloud-Endpunkte

   • der amazon-bedrock-Provider für Codex unterstützt derzeit keine Bedrock-Mantle-Endpunkte in AWS-GovCloud-Regionen
   • Sie können Codex heute nicht gegen Bedrock in GovCloud konfigurieren

Schreiben Sie also nicht „Codex auf Bedrock unterstützt GovCloud“, als wären diese beiden Aussagen identisch.

4.4 Geeignete Szenarien

Wählen Sie den Pfad nach den Anforderungen Ihrer Organisation:

ChatGPT Business/Enterprise

• kleine und mittlere Teams
• möchten Workspace-Verwaltung
• möchten den vollständigsten Funktionsumfang
• brauchen kein AWS-Billing und kein IAM

API Key

• Entwickler, die flexible Integration wollen
• keine Team-Governance nötig
• direkte Abrechnung über ein OpenAI-API-Konto
• keine Compliance-Verwaltung nötig

Amazon Bedrock

• AWS-zentrierte Teams mit bestehenden AWS-Konten, IAM und Billing
• wollen Kosten unter AWS-Commitments bündeln
• brauchen Data Residency oder bestimmte AWS-Regionen
• akzeptieren einen teilweise fehlenden Funktionssatz (siehe 4.2)

5. Bedrock-Konfiguration und Grenzen: AWS-native Auth, fehlende Funktionen und GovCloud-Risiko

Teams, die Bedrock wählen, müssen das Setup, die Authentifizierung, die fehlenden Fähigkeiten und die GovCloud-Grenze genau verstehen.

5.1 Den amazon-bedrock-Provider konfigurieren

Setzen Sie den Provider in der Codex-Konfigurationsdatei:

{
  "provider": "amazon-bedrock",
  "aws_region": "us-east-1",
  "model_id": "openai.gpt-5.5"
}

Model-ID und Region sollten den offiziellen Dokumenten folgen.

5.2 AWS-native Auth

Der Bedrock-Pfad nutzt AWS-native Authentifizierung, nicht OPENAI_API_KEY:

• Bedrock API Key: kurzlebiger Key, maximal 12 Stunden oder Session-Dauer, erbt IAM-principal-Berechtigungen
• AWS IAM credentials: über IAM-Rolle oder IAM-User konfiguriert

Für den produktiven Einsatz werden kurzlebige Keys oder IAM-Rollen empfohlen. Langzeit-Keys sind nur für Exploration gedacht.

5.3 Unterstützte kommerzielle AWS-Regionen

Die offiziellen Dokumente unterstützen derzeit diese kommerziellen AWS-Regionen:

• us-east-1
• us-west-2
• eu-west-1
• ap-northeast-1

Für die aktuelle Liste prüfen Sie die AWS-Bedrock-OpenAI-Modelle-Dokumentation.

5.4 Governance für Bedrock API Keys

Wichtige Regeln für Bedrock API Keys:

• Short-term key: bis zu 12 Stunden oder Session-Dauer, erbt IAM-principal-Berechtigungen, empfohlen für Produktion
• Long-term key: nur für Exploration, nicht für Produktion empfohlen
• CloudTrail-Logging: API-Calls werden in AWS CloudTrail erfasst; der Key selbst wird nicht im Klartext geloggt
• IAM-Actions-Steuerung: IAM-Aktionen können regeln, wer API Keys erzeugen und nutzen darf

5.5 Fehlende Fähigkeiten erneut

Stand 2026-06-08 sind auf Bedrock nicht verfügbar:

• Fast Mode
• gehostete Web-/Dateisuche
• Computer Use
• Shell Tool
• Bildgenerierung
• Remote-MCP-Server
• On-demand inference only ist nicht unterstützt; nutzen Sie Provisioned Throughput

Wenn Ihr Team diese Funktionen braucht, wechseln Sie zu ChatGPT Workspace oder API Key.

5.6 GovCloud-Risiko erneut

Noch einmal die Trennung:

• AWS GPT-5.4 ist in GovCloud (US-West) verfügbar: das Modell selbst ist in GovCloud verfügbar
• Der Codex Bedrock Provider unterstützt keine GovCloud-Endpunkte: Sie können Codex heute nicht gegen Bedrock in AWS-GovCloud-Regionen konfigurieren

Wenn Ihr Team GovCloud braucht, gehen Sie nicht davon aus, dass Codex dort bereits auf Bedrock gezeigt werden kann.

6. Governance und Audit: Wo sieht man Nutzung und Compliance-Logs?

Manager müssen Adoption, Nutzung und den Einfluss von Code Reviews verfolgen, und dafür brauchen sie Analytics- und Audit-Ausgaben.

6.1 Vergleich der drei Governance-Pfade

Pfad	Funktion	Verzögerung	Geeignet für
Analytics Dashboard	Adoption, Nutzung, Code-Review-Feedback	Nutzungsdaten können bis zu 12 Stunden verzögert sein	Tracking des Rollout-Erfolgs
Analytics API	Daily/weekly buckets, Workspace-/User-Nutzung, Aufschlüsselung nach Client, Code-Review-Metriken	Nahe Echtzeit bis wenige Stunden	Kosten-Governance und tiefere Analyse
Compliance API	Export von Codex-Aktivitäten und Audit-Metadaten	Hängt von SIEM/eDiscovery-Integration ab	Compliance-Audit

6.2 Nutzungsszenarien

6.2.1 Rollout-Tracking

Nutzen Sie das Analytics Dashboard, um Team-Adoption und Nutzung zu sehen:

• Aktivierungsrate der Mitglieder
• Qualität des Code-Review-Feedbacks
• Nutzungsverteilung nach Client

Die Dashboard-Daten können bis zu 12 Stunden hinterherhinken, daher eignen sie sich eher für Wochen- oder Monatsberichte als für Echtzeit-Monitoring.

6.2.2 Kosten-Governance

Verwenden Sie die Analytics API für tiefere Analysen:

• Nutzung nach Workspace/User/Model aufteilen
• Daily- und Weekly-Buckets vergleichen
• Nutzung nach Client aufschlüsseln (Codex App/CLI/IDE/Cloud)
• Code-Review-Metriken zusammenfassen

Das ist der richtige Weg für interne Kostensteuerung und Optimierung.

6.2.3 Compliance-Audit

Nutzen Sie die Compliance API, um Audit-Logs zu exportieren:

• Codex-Aktivitätsdatensätze
• Audit-Metadaten
• SIEM/eDiscovery-Integration
• Unterstützung für Compliance-Reviews

Dieser Pfad eignet sich für regulierte Organisationen wie Finanzwesen, öffentliche Verwaltung und Gesundheitswesen.

6.3 Empfehlung für den Governance-Pfad

• Analytics Dashboard: am besten für technische Verantwortliche und Projektmanager, die den Rollout verfolgen
• Analytics API: am besten für Plattform-Engineers, die Kosten-Governance und tiefere Analysen machen
• Compliance API: am besten für Sicherheits- und Compliance-Teams mit SIEM und eDiscovery

Die drei Pfade können je nach Organisation kombiniert werden.

7. Rollout-Pfad im Team: vom Einzeltest zur Organisations-Governance

Teams wissen oft nicht, wo sie anfangen sollen, wie sie Adoption stufenweise aufbauen oder wie sie die ersten Pilotaufgaben auswählen.

7.1 Drei-Stufen-Rollout

Stufe 1: Individuelle Kontrolle (Berechtigungsgrenze definieren)

Ziel: Sicherstellen, dass die Berechtigungsgrenze jedes Mitglieds kontrollierbar ist und sensible Dateien nicht auf lokale Rechner verteilt werden.

Kernaktionen:

• danger-full-access + approval_policy = "never" nicht als Team-Standard erlauben
• .env und secrets/ mit Deny-Globs schützen
• :workspace_roots setzen, um den Arbeitsbereich zu begrenzen

Erfolgskriterium: Niemand kann ohne Freigabe auf sensible Dateien zugreifen.

Stufe 2: Kleines Team-Pilotprojekt (gemeinsame Konventionen + risikoarme Aufgaben)

Ziel: AGENTS.md und Skills im kleinen Team vereinheitlichen und dann mit risikoarmen Aufgaben prüfen, ob der Workflow funktioniert.

Kernaktionen:

• ein globales AGENTS.md schreiben (Stil- und Test-Erwartungen)
• ein Projekt-AGENTS.md schreiben (Architektur, Abhängigkeiten, Deployment)
• risikoarme Aufgaben wählen: Dokumentation, Lint-Fixes, Test-Ergänzungen
• direkte Automatisierung von Produktionsdeployments oder Zahlungslogik vermeiden

Erfolgskriterium: Die meisten Mitglieder nutzen das gemeinsame AGENTS.md und es gibt keine größeren Sicherheitsvorfälle.

Stufe 3: Organisations-Governance (managed requirements + Analytics/Compliance API)

Ziel: Berechtigungen und Konventionen auf Organisationsebene heben und Observability sowie Audit anbinden.

Kernaktionen:

• cloud-managed requirements nach Benutzergruppen konfigurieren
• Analytics Dashboard/API für Adoption und Nutzung anbinden
• Compliance API an SIEM anbinden
• Permission Profiles und MCP-Allowlists regelmäßig prüfen

Erfolgskriterium: Das Governance-Dashboard ist online und Audit-Logs sind nachvollziehbar.

7.2 Empfohlene Pilotaufgaben

Zuerst risikoarme Aufgaben

Gute Aufgaben für die erste Pilotgruppe:

• Dokumentation: README, API-Doku, Notizen bereinigen
• Lint-Fixes: eslint, prettier, Formatierung automatisieren
• Test-Ergänzungen: Unit-Tests und Integrationstest-Skelette
• Refactoring-Vorschläge: Strukturverbesserungen mit menschlichem Review

Direkte Automatisierung vermeiden

Schlechte Aufgaben für die erste Pilotgruppe:

• Produktionsdeployments
• Zahlungslogik
• Berechtigungsänderungen
• Datenlöschung

Diese Aufgaben sind hochriskant und sollten erst geöffnet werden, wenn Governance und Audit reif genug sind.

7.3 Beziehung zu den restlichen Artikeln der Reihe

Dieser Artikel ist die Entscheidungsseite für den Team-Rollout; spätere Artikel können tiefer einsteigen:

• AGENTS.md-Schreibweise: gestufte Regeln, Kürzungen vermeiden, Wartung
• persönliche Blockaden und Sandboxes: Berechtigungsprobleme, Sandbox-Setup, häufige Fehler
• Cloud/GitHub-Integration: Remote-Entwicklung, GitHub Review, Cloud-Tasks
• Kosten- und Quotenoptimierung: Token-Reduktions-Tricks und Budgetkontrolle
• Automatisierung und Langläufer: geplante Trigger, Heartbeats und mehrtägige Jobs

Zusammenfassung und nächste Schritte

Wenn Sie als technische Führungskraft Codex im Team ausrollen, sollte die Reihenfolge so aussehen:

1. Zuerst die Berechtigungskonfiguration lesen (Abschnitte 1 und 2), um gefährliche Kombinationen zu blockieren
2. Danach die Konventionen standardisieren (Abschnitt 3), damit AGENTS.md eine gemeinsame Form hat
3. Dann den Bereitstellungspfad wählen (Abschnitte 4 und 5), um Workspace, API Key und Bedrock zu unterscheiden
4. Zum Schluss Governance anbinden (Abschnitt 6) über Analytics und Compliance APIs

Danach können Sie in spezifischere Module eintauchen:

• AGENTS.md-Schreibweise: gestufte Regeln, Kürzungen vermeiden, Wartung
• persönliche Blockaden und Sandboxes: Berechtigungsprobleme, Sandbox-Setup, häufige Fehler
• Cloud/GitHub-Integration: Remote-Entwicklung, GitHub Review, Cloud-Tasks
• Kosten- und Quotenoptimierung: Token-Reduktions-Tricks und Budgetkontrolle
• Automatisierung und Langläufer: geplante Trigger, Heartbeats und mehrtägige Jobs

Verwandte Grundlagen:

• Grundlagen der Team-Git-Zusammenarbeit: Git Flow, Branch-Strategie und Code-Review-Workflow
• CI-Secrets und Berechtigungssicherheit: GitHub-Actions-Secrets, Berechtigungsgrenzen und Sicherheitspraktiken