- Codex fragt bei der Einrichtung vier Dinge, die andere Werkzeuge im Hintergrund festlegen: Schreibrechte, Rückfragen, Umgebungsvariablen und Projektvertrauen.
- Die wichtigste Zeile ist
shell_environment_policy.inherit. Sie entscheidet, ob der Agent Ihre API-Schlüssel sieht. workspace-writeist für die meisten Betriebe die richtige Voreinstellung: Änderungen bleiben im Projektordner und damit im Zugriff von Git.- Die Einrichtung dauert rund zwanzig Minuten. Wer sie überspringt, bekommt ein Werkzeug, das mehr darf, als irgendjemand entschieden hat.
1. Warum Codex anders eingerichtet wird
Ein Coding-Agent ist ein Programm, das in Ihrem Namen Befehle ausführt. Es liest Dateien, schreibt Dateien, startet Prozesse und ruft Dienste im Netz auf. Jedes dieser Werkzeuge muss deshalb irgendwo festlegen, wie weit es dabei gehen darf.
Der Unterschied liegt darin, wo diese Festlegung steht. Bei den meisten Werkzeugen ist sie in Voreinstellungen verteilt, die man erst findet, wenn etwas schiefgegangen ist. Codex sammelt sie in einer einzigen Datei, ~/.codex/config.toml, und die Einträge heißen so, wie die Fragen lauten, die dahinterstehen.
Das ist der eigentliche Grund, warum sich ein zweiter Blick auf Codex lohnt, auch wenn Sie mit Claude Code zufrieden sind. Nicht weil die Ergebnisse besser wären, sondern weil die Entscheidungen sichtbar sind. In einem Betrieb, in dem jemand die Verantwortung für diese Entscheidungen trägt, ist das ein Unterschied.
2. Die vier Entscheidungen
Nach codex login läuft das Werkzeug. Die folgenden vier Einträge bestimmen, was es in Ihrem Betrieb tun darf. Keiner davon hat eine Voreinstellung, die für jeden passt.
Erstens: Wie weit darf geschrieben werden
Der Eintrag heißt sandbox_mode und kennt drei Stufen. read-only erlaubt nur Lesen, der Agent schlägt Änderungen vor und führt keine aus. workspace-write erlaubt Schreiben innerhalb des Projektordners. danger-full-access hebt die Grenze auf.
Für die allermeisten Fälle ist workspace-write richtig. Der Grund ist nicht Vorsicht, sondern Git: Was im Projektordner passiert, steht in git diff. Sie sehen jede geänderte Zeile und machen sie mit einem Befehl rückgängig. Außerhalb des Projektordners gibt es dieses Netz nicht.
Zweitens: Wann wird nachgefragt
Codex kann vor jedem Befehl fragen, bei riskanten Befehlen fragen oder durchlaufen. Die Versuchung, das Nachfragen abzuschalten, ist groß, weil es im Alltag bremst. Dagegen spricht ein praktisches Argument: Die Rückfrage ist der Moment, in dem Sie merken, dass der Agent das Problem anders verstanden hat als Sie.
Ein Mittelweg hat sich bewährt. Lassen Sie ihn in Projekten durchlaufen, die unter Versionskontrolle stehen und keine Produktivdaten berühren. Verlangen Sie Rückfragen überall sonst.
Drittens: Was er aus Ihrer Umgebung sieht
Das ist die Einstellung, die am seltensten angeschaut wird und am meisten entscheidet. Sie heißt shell_environment_policy.inherit und legt fest, welche Umgebungsvariablen die Befehle des Agenten erben.
Auf einem Entwicklerrechner stehen in diesen Variablen typischerweise API-Schlüssel, Datenbankzugänge und Tokens für Dienste. Steht in der Zeile all, sieht jeder Befehl alles davon. Steht dort core, bekommt er nur die Grundvariablen wie PATH und HOME, und Sie geben einzeln frei, was eine Aufgabe wirklich braucht.
Aus der Praxis: Diese Einstellung wirkt erst beim nächsten Start. Ein Agentenprozess erbt seine Umgebung genau einmal, im Moment des Starts, und sieht spätere Änderungen nicht. Wer eine Variable ändert und im selben Terminal nachprüft, bekommt das richtige Ergebnis aus der falschen Quelle: Die Prüfung startet eine frische Shell, der laufende Agent nicht. Nach jeder Änderung an der Umgebung den Agenten neu starten, sonst prüfen Sie etwas, das gar nicht läuft.
Viertens: Welche Projekte als vertrauenswürdig gelten
Codex führt eine Liste von Verzeichnissen mit einem trust_level. In vertrauenswürdigen Projekten arbeitet der Agent zügiger, weil weniger Rückfragen anfallen. Die Liste wächst im Alltag von selbst, und niemand räumt sie auf.
Schauen Sie zweimal im Jahr hinein. Ein Verzeichnis, in dem Sie vor acht Monaten einmal etwas ausprobiert haben, braucht kein dauerhaftes Vertrauen. Besonders wenn es Ihr Benutzerverzeichnis ist.
3. Was Codex kann und Claude Code nicht
Beide Werkzeuge lösen dieselbe Aufgabe und unterscheiden sich in den Griffen, die sie dafür anbieten. Vier davon gibt es so nur bei Codex.
| Befehl | Was er tut | Wofür das gut ist |
|---|---|---|
codex review | Prüft Code, ohne eine Sitzung zu öffnen | Läuft als Schritt in der Auslieferungskette mit |
codex sandbox | Führt einen Befehl in der Codex-Sandbox aus | Fremde Skripte testen, ohne das System zu öffnen |
codex apply | Übernimmt den letzten Vorschlag als git apply | Vorschlag erst lesen, dann übernehmen |
codex fork | Verzweigt eine frühere Sitzung | Zwei Lösungswege ab demselben Stand vergleichen |
Am nützlichsten davon ist codex apply. Es trennt zwei Dinge, die sonst in einem Schritt zusammenfallen: den Vorschlag erzeugen und ihn übernehmen. Dazwischen passt ein Blick, und dieser Blick ist die eigentliche Arbeit. Wie ein solcher Blick systematisch aussieht, steht in KI-gestützte Codebase-Audits.
codex doctor verdient eine eigene Erwähnung. Es prüft Installation, Konfiguration, Anmeldung und Laufzeit in einem Durchgang. Bei Problemen ist das der erste Befehl, nicht der letzte.
4. Was Sie getrost weglassen
Codex bringt einen Marktplatz für Erweiterungen mit, und die Verlockung ist dieselbe wie bei jedem anderen Werkzeug: Man installiert zwanzig und benutzt drei. Jede aktive Erweiterung belegt Platz im Arbeitsspeicher des Modells, auch wenn sie nie aufgerufen wird. Das Ergebnis sind langsamere und unschärfere Antworten.
Fangen Sie mit nichts an. Installieren Sie eine Erweiterung erst, wenn Sie dieselbe Handarbeit zum dritten Mal machen. Das gilt für die Anbindung externer Systeme doppelt, weil dort neben Rechenzeit auch Zugriffsrechte im Spiel sind. Wenn Sie überlegen, wie so etwas in Ihrem Betrieb sauber aufgesetzt wird, ist das ein Thema für die KI-Integration.
Fazit
Die vier Entscheidungen kosten zusammen rund zwanzig Minuten. Wer sie überspringt, bekommt kein kaputtes Werkzeug, sondern ein Werkzeug, das mehr darf, als irgendjemand bewusst entschieden hat. Das fällt meistens lange nicht auf und dann auf einmal.
Wenn Sie beide Werkzeuge ausprobieren wollen: Sie stören einander nicht. Beide arbeiten auf denselben Dateien, und Git ist die gemeinsame Grundlage. Welche Festlegungen unabhängig vom Werkzeug vorher stehen müssen, steht in Software selbst bauen: die Entscheidungen davor. Und wenn die Frage größer ist als das Werkzeug, also ob überhaupt selbst gebaut werden soll, führt der Weg eher über eine saubere Softwareentwicklung als über die Wahl des Editors.