Codex Cloud oder lokal: Arbeitsteilung fürs Team

In vielen Teams läuft Codex heute auf zwei Wegen gleichzeitig: Eine Entwicklerin arbeitet im Terminal mit der Codex CLI, ein Kollege schickt Aufgaben aus dem Browser an Codex Cloud. Beides funktioniert, aber ohne Absprache entstehen zwei getrennte Welten mit eigenen Zugangsdaten, eigenen Netzwerkfreigaben und eigenen Vorstellungen davon, wann ein Ergebnis fertig ist. Die Frage ist deshalb nicht, welcher Weg besser ist, sondern welche Arbeit wohin gehört und wer die Grenzen festlegt.

Zwei Ausführungsorte, zwei Sicherheitsmodelle

Lokal arbeitet Codex direkt im Repository auf dem eigenen Rechner. Es liest Dateien, ändert Code und ruft die Werkzeuge auf, die dort ohnehin installiert sind. Die Grenzen setzen zwei Schichten: eine vom Betriebssystem erzwungene Sandbox, die den Zugriff typischerweise auf den aktuellen Workspace beschränkt, und eine Approval Policy, die festlegt, wann der Agent anhalten und fragen muss. Im Preset Auto (--sandbox workspace-write --ask-for-approval on-request) darf Codex im Arbeitsverzeichnis lesen, editieren und Befehle ausführen. Für Dateien außerhalb des Workspace oder Befehle mit Netzwerkzugriff fragt er nach. Netzwerk ist standardmäßig aus und wird erst per Konfiguration eingeschaltet:

[sandbox_workspace_write]
network_access = true

Codex Cloud dagegen startet jede Aufgabe in einem eigenen, isolierten Workspace. Grundlage ist eine sogenannte Cloud-Umgebung: Repositories, Abhängigkeiten, Tools und Zugriffseinstellungen, die Codex selbst untersucht, einrichtet und testet, bevor sie veröffentlicht wird. Die Aufgabe läuft weiter, während der eigene Rechner schläft, und lässt sich aus Web, Mobile oder Desktop-App prüfen und fortsetzen.

Wofür der lokale Agent taugt

Die lokale Variante ist die enge Schleife: Code erkunden, einen Plan abstimmen, Diffs und Befehle verfolgen, während sie entstehen, und in derselben Session nachsteuern. Mit codex resume lässt sich eine frühere Sitzung im Repository wieder aufnehmen. Wer nur planen oder fragen will, schaltet mit /permissions auf read-only. Für wiederholbare Abläufe gibt es codex exec, das sich in Skripte und CI-Pipelines einbauen lässt. Ein dediziertes Review gegen uncommittete Änderungen, einen Commit oder einen Base-Branch liefert priorisierte Befunde, ohne den Working Tree zu verändern.

Damit eignet sich der lokale Weg für alles, bei dem ein Mensch dicht daneben sitzt und jeder Schritt kurz geprüft wird. Das passt zu einem gemeinsamen Ablauf aus Planen, Umsetzen und Testen, wie ihn der Beitrag Plan, Umsetzung, Test beschreibt.

Wofür Codex Cloud gedacht ist

OpenAI nennt selbst drei Situationen: Die Arbeit soll entfernt laufen, mehrere Aufgaben brauchen dasselbe Setup, oder der Workflow benötigt Zugangsdaten zu Diensten. Der entscheidende Baustein für Teams ist die Umgebung. Codex hält das getestete Setup in zwei Feldern fest, einem Install-Skript für Abhängigkeiten und einem Start-Skill, der Dienste startet und prüft, ob sie bereit sind. Änderungen am Setup werden neu veröffentlicht. Neue Tasks nutzen dann die neue Version, laufende Tasks behalten ihren eigenen Stand.

Wichtig ist ein Satz aus der Dokumentation: Gespeicherter Zustand ersetzt keine Versionskontrolle. Ergebnisse werden committet oder als Pull Request geöffnet. Auch aus dem Terminal lässt sich mit codex cloud eine Aufgabe an eine konfigurierte Umgebung schicken und das Ergebnis ins lokale Repository übernehmen. Die beiden Wege schließen sich also nicht aus.

Zugangsdaten und Netzwerk in der Cloud

Hier liegt der größte Unterschied für Teams. Werte gelangen auf zwei Arten in eine Umgebung: als Umgebungsvariable, die Programme direkt lesen, oder als Network Secret. Beim Network Secret erhalten Programme nur einen Platzhalter, und ein Proxy setzt den echten Wert ausschließlich für erlaubte Domains über HTTPS auf Port 443 ein. Der rohe Schlüssel landet so nicht in einem lokalen Prozess oder einer Datei.

Eine geteilte Umgebung kann außerdem Werte anfordern, die jede Person aus dem eigenen Personal vault beisteuert. Geteilt werden dann die Anforderungen, nicht die persönlichen Zugangsdaten. Beim Netzwerk wählt das Team zwischen vollem öffentlichem Internetzugang und einer Einschränkung auf ein Preset für Paketmanager plus gezielt ergänzte Domains. Private Dienste lassen sich über Tailscale als VPN anbinden, Cloud-Ressourcen über OIDC mit kurzlebigen Credentials. Auch hier gilt: Eine erlaubte Domain liefert keine Zugangsdaten und keine Rechte in diesem Dienst.

Wer Freigaben für externe Tools ohnehin im Team regelt, kann dieselbe Logik übertragen, wie sie der Beitrag zu MCP-Servern im Team beschreibt.

Was das für Ihr Entwicklerteam bedeutet

Die Arbeitsteilung lässt sich in wenigen Teamregeln festhalten:

• Lokal für interaktive Arbeit am Code, bei der jemand Diffs und Befehle live verfolgt. Ein gemeinsamer Standard für Sandbox und Approval Policy gehört ins Repository, nicht in persönliche Gewohnheiten.
• Cloud für Aufgaben, die ein gleiches, getestetes Setup brauchen oder länger laufen dürfen. Jede veröffentlichte Umgebung hat einen klaren Owner, denn wer sie bearbeiten darf, steuert ein eigenes Recht (Manage workspace environments).
• Secrets in der Cloud bevorzugt als Network Secret mit festen Domains. Vor dem Teilen einer Umgebung prüft jemand die vorbereiteten Dateien und die enthaltenen Zugangsdaten.
• Ergebnisse beider Wege landen als Commit oder Pull Request und durchlaufen dasselbe Review, etwa mit der Review-Checkliste für KI-Pull-Requests.

Ein Detail für bestehende Konfigurationen: approval_policy = "untrusted" wird nicht mehr unterstützt und kann den Start verhindern. Wer projektweit strengere Freigaben will, setzt stattdessen in der nutzerweiten ~/.codex/config.toml für das Projekt trust_level = "untrusted". Welche Daten dabei das Repository verlassen, ordnet die Seite Sicherheit ein.

Fazit

Lokal und Cloud sind bei Codex keine konkurrierenden Produkte, sondern zwei Ausführungsorte mit unterschiedlichen Grenzen. Teams, die festlegen, welche Arbeit wohin gehört, wer Umgebungen pflegt und wie Zugangsdaten hineinkommen, vermeiden zwei parallele Schattenwelten.

Sie wollen diese Arbeitsteilung für Ihren Stack und Ihre Repositories festlegen, statt sie jedem Einzelnen zu überlassen? Inhouse-Training anfragen.