ki-codex/06-teams-enterprise-ci.md

Kapitel 6

Teams, Enterprise und CI – wenn aus „mein Agent“ „unser System“ wird

Kern in einem Satz: Team-Baseline im Git, least privilege in CI und Cloud, harte Org-Grenzen wo nötig – und Merge bleibt menschlich.

---

6.1 Vom Laptop zum gemeinsamen System

Szene: Drei Entwickler, drei YOLO-Defaults auf dem Laptop. Der vierte pushte gestern danger-full-access in .codex/config.toml – und wunderte sich, warum CI und Cloud „irgendwie anders“ reagieren. Team braucht gemeinsame Normen im Git und klare Ownership für Automation und Org – nicht nur „jeder hat codex installiert“.

Lokal steuerst du eine Session. Im Team teilst du Normen (AGENTS.md), optional Project-Config (trusted), Skills/Hooks und irgendwann CI und Cloud. Was lokal per Deny greift, greift remote nicht automatisch – Ownership und Policy der Environment sind eigene Hebel.

{width=90%}

Die Schichten stapeln sich – weich unten, Org oben:

Schicht	Artefakt	Review?
Weich	Root-AGENTS.md, nested Overrides	PR
Project hard (trusted)	.codex/config.toml, .codex/rules/, Hooks	PR + Trust
User	~/.codex/	lokal
Automation	codex exec, GitHub Action	Pipeline-Review
Org	Managed requirements.toml / MDM	Admin

---

6.2 Team-Baseline etablieren

Problem: Ohne gemeinsame Baseline fährt jeder Session mit anderen Never-Listen und Verify-Commands – Review wird Lotterie.

Minimum, das jedes Repo verträgt:

1. AGENTS.md mit Build/Test, 2–3 Immer/Nie, Verify-Command (Kap. 2).
2. Kein Secret in Git – Platzhalter YOUR_TOKEN.
3. Branch Protection + menschlicher Merge.
4. Optional: shared Skill verify, enge Project-config.toml, dokumentierte MCP-Liste.

Vorlagen: vorlagen/AGENTS.md.team.md, vorlagen/config.permissions.toml.

Team Config vs. Managed requirements

Hebel	Wer	Wirkung
Team-Baseline im Repo	Entwickler per PR	AGENTS.md, optional trusted .codex/ – gilt, wenn Project trusted
Team Config (Enterprise/Admin)	Org-Admin	geteilte Defaults, Rules, Skills über Org-Pfade (Admin-Doku Team Config) – nicht dasselbe wie „eine Datei im Repo“
Managed requirements.toml	Org-Admin / MDM	erzwingt Grenzen (Full Access sperren, Hooks managed-only, …) – schlägt lokale Bequemlichkeit

Lokal bleibt Project Trust die Tür für Repo-.codex/. Managed schlägt User- und Project-Wünsche, wenn die Org es so setzt (Kap. 6.3).

Kern: Baseline im PR reviewen ist billiger als „jeder hat seine YOLO-Defaults“.

---

6.3 Managed configuration und Full Access sperren

Problem: Laptop-YOLO und CI least privilege kollidieren – ohne Org-Hebel gewinnt oft die Bequemlichkeit.

Enterprise kann Constraints per requirements.toml (und verwandten Managed-Layern) erzwingen – z. B. approval_policy = "never" oder sandbox_mode = "danger-full-access" verbieten, erlaubte MCP-Server whitelisten, Hooks managed-only, Guardian/Auto-Review-Policy.

Ziel	Richtung
Kein Laptop-YOLO in der Org	Full Access / never in requirements sperren
Nur Admin-Hooks	allow_managed_hooks_only + managed Scripts
Netzwerk eng	Managed network / Domain-Allowlists
Telemetry	Org-OTel, nicht User-Experimente

Details und exakte Keys: Managed configuration. Buch liefert die Fehlerklasse (Org schlägt lokale Bequemlichkeit), nicht dein MDM-Runbook.

---

6.4 codex exec und CI

Non-interactive: codex exec (Alias codex e). Default oft read-only-Sandbox – für Automation explizit setzen.

# Nur lesen / zusammenfassen
codex exec "Summarize risky areas in this repo. No file changes."

# Mit Writes im Workspace (bewusste Isolation voraussetzen)
codex exec --sandbox workspace-write "Fix the failing unit tests only."

# JSONL für Pipelines
codex exec --json "List top 5 risks" | tee codex-events.jsonl

# Nur finale Message in Datei
codex exec -o summary.md "Draft release notes for last 10 commits"

Flag / Muster	Nutzen
--ephemeral	keine Session-Rollouts persistieren
--ignore-user-config	ohne $CODEX_HOME/config.toml
--ignore-rules	ohne User/Project-Rules (kontrollierte Env)
--output-schema schema.json	strukturiertes JSON
codex exec resume --last "…"	zweistufige Pipeline
stdin + Prompt	Logs pipen als Kontext
codex exec -	gesamter Prompt von stdin
--skip-git-repo-check	nur wenn Env wirklich safe (Default: Git-Repo nötig)

{width=90%}

{width=90%}

Auth und zwei CI-Pfade

Pfad	Wann	Auth
A) Action (openai/codex-action@v1)	GitHub Actions, Default	Secret OPENAI_API_KEY nur als Input openai-api-key – Action startet Proxy, installiert CLI
B) Bare CLI	andere Runner / eigene Images	CODEX_API_KEY=… codex exec … nur am Prozess; Key nicht job-weit neben npm install / untrusted Steps

CODEX_API_KEY gilt laut Doku nur für codex exec. ChatGPT-auth.json in CI ist advanced (private Runner, Secure Storage) – nicht der Alltagspfad.

Non-interactive braucht Sandbox und Approval explizit: enge Sandbox (oft read-only) plus --ask-for-approval never (bzw. Action-Input sandbox: read-only). never allein ist kein Freibrief – ohne enge Sandbox und least privilege ist das YOLO in der Pipeline.

Achtung: API-Keys im selben Job wie npm install/untrusted Actions = Exfil-Risiko. Least privilege: Codex-Job oft nur contents: read, Ergebnis als Artifact oder Job-Output, separater Job mit Write für PR-Kommentar – siehe Non-interactive-Doku und Action-Security-Guide.

Gerüst (beide Pfade kommentiert): beispiele/configs/github-actions-codex.yml – Inputs und Action-Version an aktuelle Doku anpassen.

# Auszug Action-Pfad – vollständig unter beispiele/configs/
jobs:
  codex_review:
    permissions:
      contents: read          # kein write im Codex-Job
    steps:
      - uses: actions/checkout@v5
        with:
          persist-credentials: false
      - uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          sandbox: read-only
          prompt: |
            Review the PR diff. List risks only. No file changes.
  # post_feedback: needs: codex_review; permissions: pull-requests: write

# Auszug CLI-Pfad – Key nur am Prozess, nie job-level env
CODEX_API_KEY=YOUR_TOKEN codex exec \
  --sandbox read-only \
  --ask-for-approval never \
  --ephemeral \
  "Review the PR diff. List risks only. No file changes."

Kein Auto-Merge durch den Agenten. CI schlägt vor; Mensch merged.

---

6.5 Codex Cloud

Cloud = async Tasks in OpenAI-managed Environments, oft PR-orientiert.

	Lokal	Cloud
Isolation	deine Sandbox	Container/Env der Cloud
Internet	default oft eng	Setup-Phase vs. Agent-Phase (Secrets nur Setup)
Du	live steuern	weiterarbeiten; Ergebnis reviewen
Policy	Laptop-Config	Environment-Settings + Org

codex cloud
codex cloud list
codex cloud exec "Add integration tests for the auth edge cases"
codex apply   # Cloud-Diff lokal – nach Review

Zwei-Phasen-Modell (konzeptionell): Setup darf Dependencies/Netz für Provisioning; Agent-Phase oft offline bzw. mit explizitem Internet/Allowlist. Secrets der Cloud sind in der Agent-Phase typisch entfernt – so designed; Details: Cloud-Internet-Doku.

Achtung: Laptop-deny und enge workspace-write reisen nicht als magische Garantie mit. Cloud-Ownership: wer darf Environments anlegen, Internet anschalten, Secrets binden?

Local vs. Cloud als Surface (Kap. 3): Cloud ist Parallelität und Isolation, kein Review-Ersatz.

---

6.6 Kosten, Limits, Observability

• /usage und Kontingente im Blick; Subagents und hohe Reasoning-Stufen multiplizieren.
• CI: Timeouts, enge Prompts, read-only wo möglich.
• Optional OTel ([otel] in User-Config) – opt-in, Prompts default redacted; Collector unter Kontrolle halten (Kap. Approvals/Telemetry-Doku).
• Analytics/Feedback per Config abschaltbar, wo Policy es verlangt.

---

6.7 Compliance-Orientierung (knapp)

Kein Rechtsrat – nur Engineering-Hebel:

Thema	Praxis
Audit	wer hat wann welche Policy; OTel/Logs mit Retention
Secrets	nie im Repo; CI-Job-Trennung
Datenresidenz	Provider/Base-URL laut Org (openai_base_url / DR-Prefix)
Training/Retention	Org- und Produkt-Settings, nicht Buch-Default
Mensch im Loop	Merge, Production-Deploy, Break-Glass Full Access

---

Häufige Fehler (Team / CI)

Symptom	Typische Ursache	Fix
„Lokal eng, CI weit“	andere Auth/Policy in der Pipeline	Action/CLI-Pfad lesen; Sandbox+Approval explizit
Key in Job-Logs / untrusted Step	OPENAI_API_KEY/CODEX_API_KEY job-weit	nur Action-Input bzw. prozesslokal am codex exec
Project-.codex/ greift bei Kollege nicht	untrusted; andere Trust-Entscheidung	Trust-Policy im Team; User-Layer dokumentieren
Managed „blockt meine Config“	Org-requirements.toml	Admin/Runbook – nicht YOLO umgehen
Auto-Merge durch Agent	zu weite CI-Rechte + freier Prompt	Write-Job trennen; Merge bleibt Mensch
Cloud-YOLO trotz Laptop-Deny	Deny reist nicht mit	Environment-Ownership und Cloud-Internet-Policy

---

Jetzt selbst machen: Team-Baseline (ca. 20 Min)

1. Root-AGENTS.md aus Team-Vorlage kürzen und committen.
2. Optional trusted .codex/config.toml mit Auto-Preset (kein YOLO).
3. Lokal: codex exec --sandbox read-only "Summarize test layout. No edits."
4. CI-Gerüst kopieren, Secrets nur in GitHub Secrets, kein Auto-Merge.
5. Checkliste: Branch Protection an? Diff-Review Pflicht?

---

Was du jetzt kannst

• Eine Team-Baseline (Memory + optionale Project-Hardening) skizzieren
• Team Config vs. Managed requirements und CI-Fehlerklassen benennen
• codex exec mit least privilege und JSON/Schema nutzen
• CI-Risiken (Key-Leak, zu weite Permissions, Auto-Merge) benennen
• Cloud als eigene Surface mit Ownership erklären
• Menschlichen Merge als harte Kante behalten

Nächste Schritte

• Kapitel 7: Context, Sessions, Symptom→Fix, Drift
• Action- und Managed-Doku parallel zum Gerüst lesen
• Cheatsheets: Kapitel 8

Primärquellen: Non-interactive mode, GitHub Action, Managed configuration, Cloud-/Internet-Seiten unter learn.chatgpt.com/codex.