Codex CLI einrichten: Der Einstieg für Entwicklungsteams

Für den Einstieg ist ein Zeitfenster von 15 Minuten sinnvoll, sofern ein lauffähiges Projekt und ein Konto mit Zugang vorhanden sind. Installation, Anmeldung oder eine langsame Testsuite können länger dauern. Ein brauchbares erstes Ergebnis ist eine kleine, überprüfte Änderung – oder eine genaue Erklärung, woran sie scheitert. Die Befehle wurden am 11. Oktober 2026 geprüft.

Codex CLI installieren und die erste Aufgabe abschließen

Codex arbeitet direkt im Projekt: Es kann Dateien untersuchen und bearbeiten sowie lokal installierte Tools ausführen. Das lässt sich mit einem Teammitglied an einer eigenen Werkbank vergleichen. Aufgabe und Grenzen werden vorgegeben; ob das Ergebnis ins Produkt gehört, entscheidet weiterhin ein Mensch. CLI-Anleitung von OpenAI

Minute 0 bis 3: Einen Installationsweg wählen

Unter macOS oder Linux lässt sich der eigenständige Installer so starten:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Passt eine Alternative besser zur vorhandenen Umgebung, bietet sie sich ebenso an. Entscheidend ist, sich für einen Weg zu entscheiden, damit später klar ist, wie Updates eingespielt werden.

Für Windows nennt die Dokumentation diesen genauen Befehl, der in einem neuen PowerShell-Fenster ausgeführt wird: powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex".

Diese Installationswege stehen in der aktuellen CLI-Dokumentation und im offiziellen Repository. Vor dem Start von Codex im Terminal in das Projektverzeichnis wechseln.

Minute 3 bis 5: Anmeldung mit ChatGPT oder API-Schlüssel wählen

Für die erste interaktive Sitzung bietet sich die ChatGPT-Anmeldung an, sofern Tarif und Workspace den Zugang ermöglichen. Dazu codex login ausführen und die Anmeldung im Browser abschließen. Auch beim Start von codex ohne bestehende Anmeldung wird Mit ChatGPT anmelden angeboten.

Ein API-Schlüssel ist passend, wenn das OpenAI-Platform-Konto genutzt werden soll, etwa für programmatische Abläufe. Ist OPENAI_API_KEY bereits in der Shell-Umgebung gesetzt, lautet der dokumentierte Befehl unter macOS/Linux: printenv OPENAI_API_KEY | codex login --with-api-key. Der Schlüssel gehört nicht in Dateien des Repositorys.

Mit codex login status lässt sich prüfen, welche Anmeldemethode aktiv ist. Im Team ist das relevant: Bei der ChatGPT-Anmeldung gelten die Vorgaben des ChatGPT-Workspaces, bei der API-Anmeldung die der API-Organisation. Anleitung zur Authentifizierung

Kosten: Die ChatGPT-Anmeldung nutzt den im berechtigten Tarif enthaltenen Zugang; die Nutzung per API-Schlüssel wird separat über OpenAI Platform zu API-Tarifen abgerechnet. Einen Tarifvergleich bietet unser Codex-Preisüberblick. Für einen Test im Team die manuelle Bearbeitungszeit dem Aufwand für Prompts, Prüfung und Korrekturen gegenüberstellen. Vom Wert der tatsächlich eingesparten Zeit werden anschließend die zusätzlichen Nutzungskosten abgezogen. Ein schnellerer erster Entwurf lohnt sich erst, wenn der gesamte Aufwand bis zur Abnahme sinkt. OpenAI zur Unterscheidung von Anmeldung und Abrechnung

Minute 5 bis 8: Erst untersuchen, dann bearbeiten

Zunächst den aktuellen Stand in Git sichern. Anschließend in der Shell des Projekts mit dem dokumentierten Befehl codex --sandbox read-only --ask-for-approval on-request eine Sitzung zur Untersuchung starten.

Die Untersuchung sollte klar begrenzt sein. Dieser Beispiel-Prompt lässt sich an das eigene Projekt anpassen:

Der Prompt ist ein Vorschlag für den Arbeitsablauf, kein spezieller Codex-Befehl. Anhand der Antwort prüfen, ob Codex den richtigen Teil der Anwendung gefunden hat. Die schreibgeschützte Sandbox erlaubt Untersuchungen und Befehle innerhalb ihrer Grenzen; Aktionen außerhalb dieser Grenzen können eine Freigabe erfordern. Anleitung zu Freigaben und Sandbox

Minute 8 bis 12: Eine kleine Änderung freigeben

Sobald die Bearbeitung beginnen soll, lässt sich über /permissions das Schreiben im Workspace erlauben. Für eine neue Sitzung lautet die dokumentierte Kombination codex --sandbox workspace-write --ask-for-approval on-request.

Danach ein Abnahmekriterium vorgeben:

Für den Anfang eignet sich etwas, dessen Ergebnis schnell zu beurteilen ist. Ein Test für bekanntes Verhalten ist eine bessere erste Aufgabe als der offene Auftrag, die Architektur zu verbessern.

Minute 12 bis 15: Diff und Testergebnisse prüfen

Mit /diff den Patch ansehen und mit /review eine Prüfung anfordern. Dabei die tatsächliche Testausgabe, die geänderten Dateien und die Erfüllung des Abnahmekriteriums kontrollieren. Erst nach der eigenen Prüfung committen. Diese Slash-Befehle werden innerhalb der Codex-Sitzung eingegeben, nicht am Shell-Prompt. CLI-Befehlsreferenz

Erst eine Vergleichsbasis schaffen, dann das Modell wählen

Zum Einstieg genügt das in der Sitzung verfügbare Modell. Über /model lässt sich anschließend ein anderes Modell wählen oder der Denkaufwand anpassen. OpenAI verwendet derzeit dieses Startbeispiel: codex --model gpt-6.1-sol.

Die aktuelle Empfehlung lautet GPT-6.1 Sol für komplexe Programmieraufgaben, sofern Konto und Client Zugriff darauf haben, und GPT-6 Luna für klar umrissene, wiederkehrende Aufgaben. Mehr Denkaufwand kann bei schwierigen Analysen helfen, benötigt aber auch mehr Zeit und Tokens. Für aussagekräftige Vergleiche sollten Ausgangsaufgabe und Einstellung des Denkaufwands gleich bleiben. OpenAIs Modellleitfaden für Codex

Bei der Einführung im Team das verwendete Modell zusammen mit der Aufgabe und dem Testergebnis festhalten. Einen Modellnamen auszuwählen verschafft dem Konto noch keinen Zugriff darauf.

Sandbox-Zugriff und Freigaben getrennt einstellen

Die Sandbox bestimmt, worauf Befehle zugreifen können. Die Freigaberichtlinie legt fest, wann Codex vor einer Aktion nachfragen muss. Bildlich gesprochen sind die Sandbox-Grenzen die Wände des Arbeitsraums; die Freigaberichtlinie regelt, wann eine Tür geöffnet werden darf.

Für interaktive Arbeit eignet sich on-request: Innerhalb der Sandbox erlaubte Aktionen können ausgeführt werden; bei Aktionen, die weitergehenden Zugriff benötigen, kann eine Rückfrage erscheinen. never bedeutet, dass Codex keine Freigabe anfordern kann. Die Sandbox wird dadurch nicht aufgehoben. Eine blockierte Aktion kann also blockiert bleiben.

Ein begrenzter Schreibzugriff bedeutet nicht, dass vor jeder Änderung nachgefragt wird. Mit workspace-write und on-request kann Codex Dateien im Workspace automatisch ändern und erlaubte Befehle ausführen. Die aktiven Einstellungen lassen sich mit /permissions prüfen. OpenAI zum Verhalten von Sandbox und Freigaben

Steht in einer alten Teamvorlage approval_policy = "untrusted", muss sie aktualisiert werden: OpenAI hat diese ausdrückliche Einstellung abgeschafft und weist darauf hin, dass sie den Start verhindern kann. Auch der frühere Aufruf codex exec --full-auto ist veraltet. Stattdessen die dokumentierten Sandbox- und Freigabeeinstellungen verwenden. Aktueller Migrationsleitfaden

Gemeinsame Arbeitsregeln in AGENTS.md festhalten

Mit AGENTS.md muss nicht immer wieder erklärt werden, wie das Repository funktioniert. Codex liest diese Anweisungen zu Beginn eines Durchlaufs. /init kann ein Grundgerüst erzeugen, das ein Maintainer bearbeiten sollte, bevor sich das Team darauf verlässt.

Eine hilfreiche Datei im Repository beantwortet vier Fragen:

• Wie werden Abhängigkeiten installiert und das Projekt gestartet?
• Welche Tests und Prüfungen sind für eine Änderung erforderlich?
• Welche Verzeichnisse enthalten generierte Dateien oder erfordern besondere Vorsicht?
• Was gehört in den Abschlussbericht, etwa geändertes Verhalten, ausgeführte Tests und noch bestehende Fehler?

In die Datei gehören die tatsächlichen Befehle und Konventionen des Projekts, keine allgemeine Wunschliste. Persönliche Vorlieben kommen in ~/.codex/AGENTS.md; gemeinsame Repository-Regeln werden im Projektstamm eingecheckt.

Codex lädt zuerst globale Anweisungen und arbeitet sich dann vom Projektstamm zum aktuellen Verzeichnis vor. Lokalere Anweisungen haben Vorrang vor zuvor geladenen Vorgaben; im selben Verzeichnis hat AGENTS.override.md Vorrang vor AGENTS.md. Nach Änderungen an den Anweisungen die Sitzung neu starten und Codex bitten, die geladenen Vorgaben zusammenzufassen. Regeln zum Laden von AGENTS.md

Die Datei dient als Handbuch für Mitwirkende. Technische Beschränkungen gehören in die Konfiguration und in zentral verwaltete Vorgaben.

config.toml übersichtlich und prüfbar halten

Persönliche Standardeinstellungen stehen in ~/.codex/config.toml. Gemeinsame Projektvorgaben gehören in .codex/config.toml; Codex lädt diese Datei nur bei vertrauenswürdigen Projekten. Die Einstellungen verwenden TOML, ein Textformat für benannte Konfigurationswerte.

Diese Ausgangskonfiguration kombiniert Werte aus OpenAIs Konfigurationsleitfaden. Die Modellzeile sollte nur verwendet werden, wenn das Modell für das eigene Konto verfügbar ist:

model = "gpt-6.1-sol"
model_reasoning_effort = "medium"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

CLI-Flags und Überschreibungen über --config haben Vorrang vor der Projektkonfiguration. Einstellungen vertrauenswürdiger Projekte gehen ausgewählten Profilen und persönlichen Standardwerten vor. Organisationsvorgaben können unabhängig davon einschränken, was zulässig ist. Grundlagen der Konfiguration

web_search = "cached" wählt zwischengespeicherte Websuchergebnisse aus. Diese Einstellung ist vom Netzwerkzugriff für Shell-Befehle getrennt. Der Download einer Abhängigkeit kann eine Freigabe erfordern, auch wenn Codex ein Tool für die Websuche zur Verfügung steht. Diese Unterscheidung gehört in die Einführungsunterlagen, statt bei jedem fehlgeschlagenen Befehl die Berechtigungen zu erweitern.

MCP-Server nur bei konkretem Bedarf hinzufügen

MCP steht für Model Context Protocol und verbindet Codex mit Tools und externem Kontext. Ein lokaler Server läuft als Prozess; ein entfernter Server wird über eine HTTP-Adresse erreicht. Eine solche Verbindung ist sinnvoll, wenn eine Aufgabe Informationen oder eine Aktion benötigt, die das Repository nicht bereitstellen kann.

Das Beispiel in OpenAIs Dokumentation lautet codex mcp add context7 -- npx -y @upstash/context7-mcp. Es startet einen Dokumentationsserver über npx; dieses Startprogramm muss daher verfügbar sein. Mit codex mcp list lassen sich die konfigurierten Server anzeigen, mit /mcp innerhalb einer Sitzung die aktiven Verbindungen prüfen. Unterstützt ein Server OAuth, wird codex mcp login <server-name> verwendet. Der Platzhalter wird dabei durch den konfigurierten Servernamen ersetzt.

Die Serverkonfiguration gehört unter [mcp_servers.<server-name>] in dasselbe TOML-Konfigurationssystem. Über enabled_tools und disabled_tools kann ein Team die bereitgestellten Tools einschränken; die Sperrliste wird nach der Freigabeliste angewendet. Für den Anfang genügt die kleinste sinnvolle Auswahl an Tools. MCP einrichten und konfigurieren

Große Tool-Antworten sind ein eigenes Thema. Dazu gibt es unsere Erklärung der MCP-Ausgabelimits in Codex CLI. Ob ein Server verbunden wird und wie umfangreich seine Ausgaben sein dürfen, sind zwei unterschiedliche Konfigurationsentscheidungen.

Worktrees für Aufgaben mit getrennten Checkouts nutzen

Ein Git-Worktree stellt für eine Aufgabe einen separaten Checkout des Repositorys bereit. Das ist hilfreich, wenn die Änderungen eines Experiments von den Dateien getrennt bleiben sollen, an denen gerade gearbeitet wird.

Mit Version 0.154.0 hat OpenAI verwaltete Worktrees für CLI-Aufgaben, interaktive Sitzungen und Abzweigungen eingeführt. Die Implementierung setzt das experimentelle Feature worktrees voraus und beschränkt es auf lokale Sitzungen. Aktiviert wird das Feature mit codex features enable worktrees, dem dokumentierten CLI-Befehl zum Einschalten benannter Features. Anschließend erfolgt der Start mit codex --worktree. Versionshinweise, Implementierung interaktiver Worktrees, Feature-Befehle

In einer unterstützten Sitzung bietet /worktree die Wahl zwischen einer neuen Unterhaltung und einer Abzweigung in einen verwalteten Checkout. Bei einer Abzweigung wird der Gesprächsverlauf übernommen; eine neue Unterhaltung beginnt ohne diesen Verlauf. Voraussetzung sind das aktivierte Feature und ein lokales Git-Repository. Worktree-Befehle innerhalb einer Sitzung

Prüfung, Integration und Aufräumen müssen selbst eingeplant werden. In der CLI-Implementierung ist die automatische Bereinigung der von ihr verwalteten Checkouts deaktiviert. Ein separater Checkout ersetzt außerdem weder Sandbox-Einstellungen noch die Prüfung vor dem Zusammenführen. Lebenszyklus verwalteter Checkouts

Für den Einstieg in parallele Aufgaben hilft unser Codex-CLI-Leitfaden zu Worktrees. Für die erste Aufgabe zum Schreiben eines Tests reicht ein einzelner Checkout.

Sechs sinnvolle Aufgaben für kleine Teams – nach Priorität

Die folgenden Aufgaben sind Vorschläge, keine gemessenen Produktivitätsversprechen. Der beste Einstieg ist dort, wo sich das Abnahmekriterium am einfachsten überprüfen lässt.

Codex ersetzt keine fehlenden Produktentscheidungen. Eine bestandene Testsuite beweist auch nicht, dass jedes Risiko abgedeckt ist. Abnahmekriterien und menschliche Prüfung bleiben Teil der Arbeit. Eine umfassendere Einordnung bietet unser Codex-Testbericht; bei der Kaufentscheidung hilft Codex vs Claude Code.

Zwei spezialisierte Tools als Produktidee für technische Gründer

Die aussichtsreichere Idee ist ein Regressionstest-Service für einen bestimmten Tech-Stack. Kleine Teams mit bekannten Fehlern und lückenhafter Testabdeckung könnten geprüfte Test-Patches kaufen. Die kleinste sinnvolle Version nimmt einen reproduzierbaren Fehlerfall entgegen, führt eine klar begrenzte Codex-Aufgabe in einem separaten Checkout aus und liefert den Patch samt Testergebnissen zurück. Die am 11. Oktober 2026 abgerufene US-Keyword-Schätzung von DataForSEO liegt bei 880 monatlichen Suchanfragen für „automated software testing services“. Das misst das Interesse an der Aufgabe, nicht die Kaufbereitschaft für dieses Produkt. Die Schwierigkeit liegt in zuverlässigen Test-Fixtures und aussagekräftigen Assertions; ein Test, der lediglich die Implementierung wiederholt, bringt wenig Nutzen.

Die zweite Möglichkeit ist ein Review-Assistent für ein bestimmtes Repository. Eine Entwicklungsleitung könnte für Prüfungen bezahlen, die die dokumentierten Teamkonventionen anwenden und eine kurze, nachprüfbare Liste von Befunden liefern. Als Einstieg genügen ein Repository, dessen AGENTS.md und ein wiederholbarer Prüflauf. Dieselbe Nachfrageanalyse schätzt 1,300 monatliche Suchanfragen in den USA für „ai code review“. Die Herausforderung ist die Abgrenzung: Codex prüft bereits Code. Das Produkt muss deshalb relevantere Befunde liefern und Fehlalarme reduzieren. Bei der Testgenerierung ist das anfängliche Ergebnis klarer greifbar, weil Käufer die gelieferte Arbeit selbst prüfen und ausführen können.

Häufige Fragen zur Einrichtung

Am Montag sollte ein Maintainer dieselbe kleine Aufgabe gemeinsam mit zwei Teammitgliedern durchspielen, den Prüf- und Korrekturaufwand festhalten und die gemeinsamen Anweisungen dort nachbessern, wo die Übergabe hakt. Erst wenn das Team diesen Ablauf sicher wiederholen kann, sollte der Einsatz ausgeweitet werden.

Für einen Repository-Workflow, der auf diesen Steuerungsmöglichkeiten aufbaut: Wir entwickeln KI-Produktionssysteme.