Grundlagen der Konfiguration

Codex liest die Konfiguration aus mehreren Quellen. Deine persönlichen Standardeinstellungen stehen in ~/.codex/config.toml. Mit .codex/config.toml-Dateien kannst du sie für einzelne Projekte überschreiben. Aus Sicherheitsgründen lädt Codex projektspezifische Konfigurationsebenen unter .codex/ nur, wenn du dem Projekt vertraust.

Codex-Konfigurationsdatei

Codex speichert die Benutzerkonfiguration unter ~/.codex/config.toml. Wenn Einstellungen nur für ein bestimmtes Projekt oder einen Unterordner gelten sollen, füge dort in deinem Repository eine .codex/config.toml-Datei hinzu.

Um die Konfigurationsdatei in der Codex IDE-Erweiterung zu öffnen, wähle oben rechts das Zahnradsymbol und dann Codex-Einstellungen > config.toml öffnen aus.

CLI und IDE-Erweiterung verwenden dieselben Konfigurationsebenen. Damit kannst du:

• Das Standardmodell und den Anbieter festlegen.
• Genehmigungsrichtlinien und Sandbox-Einstellungen konfigurieren.
• MCP-Server konfigurieren.

Priorität der Konfiguration

Codex ermittelt Werte in dieser Reihenfolge (höchste Priorität zuerst):

1. CLI-Flags und Überschreibungen mit --config
2. Projektkonfigurationsdateien: .codex/config.toml, vom Projektstammverzeichnis bis zu deinem aktuellen Arbeitsverzeichnis (die nächstgelegene Datei hat Vorrang; nur bei vertrauenswürdigen Projekten)
3. Mit --profile profile-name ausgewählte Profildateien (~/.codex/profile-name.config.toml)
4. Benutzerkonfiguration: ~/.codex/config.toml
5. In der Cloud verwaltete Standardeinstellungen für config.toml, sofern sie für den Workspace bereitgestellt werden, in dem du angemeldet bist
6. Systemkonfiguration (falls vorhanden): /etc/codex/config.toml unter Unix
7. Integrierte Standardeinstellungen

Nutze diese Prioritätsreihenfolge, um gemeinsame Standardeinstellungen in config.toml festzulegen und in Profildateien nur die abweichenden Werte anzugeben.

Die in der Cloud verwaltete Konfiguration und die Systemkonfiguration können Plug-in-Marketplaces definieren und festlegen, ob Plug-ins standardmäßig aktiviert sind. Diese Einstellungen sind unabhängig von den verbindlichen Richtlinien in requirements.toml. Siehe Plug-in-Marketplaces und Standardeinstellungen konfigurieren.

Wenn du ein Projekt als nicht vertrauenswürdig markierst, überspringt Codex die projektspezifischen Konfigurationsebenen unter .codex/, einschließlich lokaler Konfiguration, Hooks und Regeln. Die Benutzer- und Systemkonfiguration werden weiterhin geladen, einschließlich benutzerspezifischer und globaler Hooks und Regeln.

Informationen zu einmaligen Überschreibungen über -c/--config (einschließlich der Regeln für Anführungszeichen in TOML) findest du unter Erweiterte Konfiguration.

Häufig verwendete Konfigurationsoptionen

Hier sind einige der am häufigsten geänderten Optionen:

Standardmodell

Wähle das Modell, das Codex standardmäßig in der CLI und IDE verwendet.

model = "gpt-5.6"

Genehmigungsanfragen

Lege fest, wann Codex vor der Ausführung generierter Befehle pausiert, um deine Genehmigung anzufordern.

approval_policy = "on-request"

Informationen zu den Verhaltensunterschieden zwischen on-request und never findest du unter Ohne Genehmigungsanfragen ausführen und Gängige Kombinationen von Sandbox und Genehmigungen. Wenn eine bestehende Konfiguration approval_policy = "untrusted" verwendet, siehe Von der eingestellten Genehmigungsrichtlinie untrusted migrieren.

Sandbox-Stufe

Lege fest, wie weit Codex bei der Ausführung von Befehlen auf das Dateisystem und das Netzwerk zugreifen darf.

sandbox_mode = "workspace-write"

Informationen zum Verhalten der einzelnen Modi (einschließlich geschützter Pfade wie .git/.codex und der Netzwerkstandardeinstellungen) findest du unter Sandbox und Genehmigungen, Geschützte Pfade in Stammverzeichnissen mit Schreibzugriff und Netzwerkzugriff.

Berechtigungsprofile

Codex unterstützt auch benannte Berechtigungsprofile für wiederverwendbare Richtlinien zum Dateisystem- und Netzwerkzugriff. Die integrierten Profile sind :read-only, :workspace und :danger-full-access. Benutzerdefinierte Profile verwenden [permissions.<name>]-Tabellen und einen passenden Wert für default_permissions. Siehe Berechtigungen.

Sandbox-Modus unter Windows

Wenn du Codex nativ unter Windows ausführst, setze den nativen Sandbox-Modus in der Tabelle windows auf elevated. Verwende unelevated nur, wenn du keine Administratorrechte hast oder das Setup mit erhöhten Rechten fehlschlägt.

[windows]
sandbox = "elevated"   # Recommended
# sandbox = "unelevated" # Fallback if admin permissions/setup are unavailable

Modus der Websuche

Codex aktiviert die Websuche standardmäßig für lokale Chats und liefert Ergebnisse aus einem Websuchcache. Dieser Cache ist ein von OpenAI gepflegter Index von Webergebnissen. Im Cache-Modus werden daher bereits indexierte Ergebnisse zurückgegeben, statt Seiten live abzurufen. Das verringert das Risiko von Prompt Injection durch beliebige Live-Inhalte. Dennoch solltest du Webergebnisse weiterhin als nicht vertrauenswürdig behandeln. Wenn du --yolo oder eine andere Sandbox-Einstellung mit Vollzugriff verwendest, liefert die Websuche standardmäßig Live-Ergebnisse. Wähle den Modus mit web_search:

• "cached" (Standard) liefert Ergebnisse aus dem Websuchcache.
• "indexed" erlaubt externe Webzugriffe nur, wenn die Anfrage die Zugriffskontrolle des Suchindex durchläuft.
• "live" ruft die aktuellsten Daten aus dem Web ab (entspricht --search).
• "disabled" deaktiviert das Tool für die Websuche.

web_search = "cached"  # default; serves results from the web search cache
# web_search = "indexed" # gate external web access through the search index
# web_search = "live"  # fetch the most recent data from the web (same as --search)
# web_search = "disabled"

Reasoning-Aufwand

Passe den Reasoning-Aufwand des Modells an, sofern es diese Einstellung unterstützt.

model_reasoning_effort = "high"

Kommunikationsstil

Lege für unterstützte Modelle einen standardmäßigen Kommunikationsstil fest.

personality = "friendly" # or "pragmatic" or "none"

Du kannst diese Einstellung später in einer aktiven Sitzung mit /personality überschreiben oder bei Verwendung der App Server-APIs pro Thread oder Gesprächsschritt anpassen.

TUI-Tastenbelegung

Passe die Tastenkürzel im Terminal unter tui.keymap an. Bestimmte Aktionen im Editor greifen auf passende Belegungen unter tui.keymap.global zurück. Kontextspezifische Belegungen haben Vorrang, sofern sie unterstützt werden. Eine leere Liste hebt die Tastenbelegung für die Aktion auf.

[tui.keymap.global]
open_transcript = "ctrl-t"

[tui.keymap.composer]
submit = ["enter", "ctrl-m"]

[tui.keymap.chat]
interrupt_turn = "f12"

Umgebung für Befehle

Lege fest, welche Umgebungsvariablen Codex an gestartete Befehle weitergibt. Verwende Filter nach Variablennamen, um nur die benötigten Variablen beizubehalten:

[shell_environment_policy]
ignore_default_excludes = false

[shell_environment_policy.filters]
"PATH" = "include"
"HOME" = "include"

ignore_default_excludes ist standardmäßig auf true gesetzt. Dadurch entfällt die automatische Filterung von Variablen, deren Namen KEY, SECRET oder TOKEN enthalten. Setze den Wert auf false, wenn du diese automatische Filterung aktivieren möchtest. Informationen zu Ausschlussregeln, Prioritäten und älteren Konfigurationen findest du unter Richtlinie für die Shell-Umgebung.

Protokollverzeichnis

Ändere das Verzeichnis, in das Codex lokale Protokolldateien schreibt. Wenn du log_dir explizit setzt, aktivierst du damit auch das optionale TUI-Protokoll im Klartextformat, codex-tui.log, in diesem Verzeichnis.

log_dir = "/absolute/path/to/codex-logs"

Für einzelne Ausführungen kannst du das Verzeichnis auch über die CLI festlegen:

codex -c log_dir=./.codex-log

Feature-Flags

Verwende die Tabelle [features] in config.toml, um optionale und experimentelle Funktionen ein- oder auszuschalten.

Häufig verwendete Feature-Flags

Informationen zur Konfiguration von Lebenszyklus-Hooks findest du unter Hooks.

Funktionen aktivieren

• Füge in config.toml unter [features] den Eintrag feature_name = true hinzu.
• Führe in der CLI codex --enable feature_name aus.
• Um mehrere Funktionen zu aktivieren, führe codex --enable feature_a --enable feature_b aus.
• Um eine Funktion zu deaktivieren, setze den Schlüssel in config.toml auf false.