Grundlagen der Konfiguration

Codex liest Konfigurationsdetails aus mehreren Quellen. Ihre persönlichen Standardeinstellungen befinden sich in ~/.codex/config.toml, und mit .codex/config.toml-Dateien können Sie projektspezifische Überschreibungen hinzufügen. Aus Sicherheitsgründen lädt Codex projektbezogene .codex/-Ebenen nur, wenn Sie dem Projekt vertrauen.

Codex-Konfigurationsdatei

Codex speichert die Konfiguration auf Benutzerebene unter ~/.codex/config.toml. Um Einstellungen auf ein bestimmtes Projekt oder einen Unterordner zu beschränken, fügen Sie Ihrem Repository eine .codex/config.toml-Datei hinzu.

Um die Konfigurationsdatei über die Codex IDE-Erweiterung zu öffnen, wählen Sie oben rechts das Zahnradsymbol und anschließend Codex Settings > Open config.toml aus.

Die CLI und die IDE-Erweiterung verwenden dieselben Konfigurationsebenen. Damit können Sie:

• das Standardmodell und den Anbieter festlegen.
• Genehmigungsrichtlinien und Sandbox-Einstellungen konfigurieren.
• MCP server konfigurieren.

Konfigurationsrangfolge

Anforderungen schränken das Verhalten ein; Konfigurationswerte geben Standardwerte vor. Für den Zugriff auf den lokalen Computer mit Work Cloud gelten folgende Anforderungen:

• Richtlinienübergreifend: Eine Richtlinie mit höherer Priorität hat Vorrang vor einer Richtlinie mit niedrigerer Priorität, selbst wenn die Richtlinie mit niedrigerer Priorität spezifischer ist.
• Innerhalb einer Richtlinie: Betriebssystemspezifische Umgebungsüberschreibungen haben Vorrang vor betriebssystemübergreifenden Umgebungsüberschreibungen; danach folgen die globalen Einstellungen.
• Für die lokale Ausführung: MDM-Anforderungen und ältere Anforderungen für verwaltete Geräte haben Vorrang vor Agent Security. Die Systemanforderungsdatei des Geräts ist Agent Security nachgeordnet.
• Für Work Cloud: Work-Cloud-Container behalten die bestehenden Work-Cloud-Richtlinien bei. Für Work mit lokalem Zugriff und dots steuert die unterstützte globale Richtlinie den gemeinsamen Cloud-Orchestrator, wenn die verwaltete Richtlinie aktiviert ist; für den verbundenen Computer gelten die anwendbaren Anforderungen an die lokale Ausführung.

Für einige Anforderungen gelten feldspezifische Zusammenführungsregeln. Informationen zum Geltungsbereich von Richtlinien und zu Laufzeitbeschränkungen finden Sie unter Verwaltete Konfiguration, Informationen zur Kompatibilität mit Work in der Konfigurationsreferenz.

Codex löst Werte in dieser Reihenfolge auf, beginnend mit der höchsten Priorität:

1. CLI-Flags und --config-Überschreibungen
2. Projektkonfigurationsdateien: .codex/config.toml, vom Projektstammverzeichnis bis zu Ihrem aktuellen Arbeitsverzeichnis geordnet (die nächstgelegene hat Vorrang; nur vertrauenswürdige Projekte)
3. Mit --profile profile-name ausgewählte Profildateien (~/.codex/profile-name.config.toml)
4. Benutzerkonfiguration: ~/.codex/config.toml
5. Cloudverwaltete config.toml-Standardwerte, sofern sie für den angemeldeten Workspace bereitgestellt werden
6. Systemkonfiguration (falls vorhanden): /etc/codex/config.toml unter Unix
7. Integrierte Standardwerte

Nutzen Sie diese Rangfolge, um gemeinsame Standardeinstellungen in config.toml festzulegen, und beschränken Sie Profildateien auf abweichende Werte.

Die cloudverwaltete Konfiguration und die Systemkonfiguration können Plugin-Marktplätze definieren und festlegen, ob Plugins standardmäßig aktiviert sind. Diese Einstellungen sind von erzwungenen requirements.toml-Richtlinien getrennt. Siehe Plugin-Marktplätze und Standardwerte konfigurieren.

Wenn Sie ein Projekt als nicht vertrauenswürdig markieren, überspringt Codex projektbezogene .codex/-Ebenen einschließlich lokaler Projektkonfigurationen, Hooks und Regeln. Benutzer- und Systemkonfigurationen werden weiterhin geladen, einschließlich benutzerbezogener und globaler Hooks und Regeln.

Informationen zu einmaligen Überschreibungen über -c/--config, einschließlich der TOML-Regeln für Anführungszeichen, finden Sie unter Erweiterte Konfiguration.

Häufig verwendete Konfigurationsoptionen

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

Standardmodell

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

model = "gpt-6.1-sol"

Genehmigungsabfragen

Legen Sie fest, wann Codex vor dem Ausführen generierter Befehle pausiert und um Genehmigung bittet.

approval_policy = "on-request"

Zu den Verhaltensunterschieden zwischen on-request und never siehe Ohne Genehmigungsabfragen ausführen und Gängige Kombinationen aus Sandbox und Genehmigungen. Wenn eine bestehende Konfiguration approval_policy = "untrusted" verwendet, siehe Von der eingestellten Genehmigungsrichtlinie untrusted migrieren.

Sandbox-Stufe

Legen Sie fest, wie weit Codex beim Ausführen von Befehlen auf das Dateisystem und das Netzwerk zugreifen darf.

sandbox_mode = "workspace-write"

Informationen zum Verhalten der einzelnen Modi (einschließlich der geschützten Pfade .git, .agents, .codex und .aws sowie der Netzwerkstandardwerte) finden Sie unter Sandbox und Genehmigungen, Geschützte Pfade in beschreibbaren Stammverzeichnissen und Netzwerkzugriff.

Berechtigungsprofile

Codex unterstützt außerdem benannte Berechtigungsprofile für wiederverwendbare Dateisystem- und Netzwerkrichtlinien. Die integrierten Profile sind :read-only, :workspace und :danger-full-access. Benutzerdefinierte Profile verwenden [permissions.<name>]-Tabellen und einen entsprechenden default_permissions-Wert. Weitere Informationen finden Sie unter Berechtigungen.

Windows-Sandbox-Modus

Verwenden Sie unter Windows vorzugsweise MXC, wenn das Gerät und die Richtlinien dies unterstützen. Legen Sie eine ältere Implementierung als Ausweichlösung fest:

[windows]
sandbox = "elevated" # Legacy fallback

[features]
prefer_mxc = true

Verwenden Sie unelevated nur, wenn die Einrichtung mit erhöhten Rechten nicht verfügbar ist und die Richtlinien Ihrer Organisation dies erlauben. Informationen zu Kompatibilitätsgrenzen und zur Steuerung des Rollouts finden Sie im Leitfaden zur Windows-Sandbox.

Websuchmodus

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 vorab indexierte Ergebnisse zurückgegeben, statt Seiten live abzurufen. Dies verringert das Risiko von Prompt Injection durch beliebige Live-Inhalte. Behandeln Sie Webergebnisse als nicht vertrauenswürdig. Wenn Sie --yolo oder eine andere Sandbox-Einstellung mit Vollzugriff verwenden, liefert die Websuche standardmäßig Live-Ergebnisse. Wählen Sie einen Modus mit web_search:

• "cached" (Standard) stellt Ergebnisse aus dem Websuchcache bereit.
• "indexed" erlaubt externen Webzugriff nur, wenn der Suchindex die Anfrage freigibt.
• "live" ruft die neuesten Daten aus dem Web ab (entspricht --search).
• "disabled" deaktiviert das Websuchtool.

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

Legen Sie bei unterstützten Modellen fest, wie viel Reasoning-Aufwand das Modell aufwendet.

model_reasoning_effort = "medium"

Kommunikationsstil

Um die integrierten Persönlichkeitsanweisungen wegzulassen, legen Sie Folgendes fest:

personality = "none"

Dadurch wird der Abschnitt Personality aus den integrierten Anweisungen des Modells entfernt. Explizite benutzerdefinierte Basisanweisungen werden dadurch nicht geändert. Die älteren Werte friendly und pragmatic dienen nicht mehr zur Stilauswahl. Codex stellt den Befehl /personality nicht mehr bereit.

TUI-Tastenbelegung

Passen Sie die Terminal-Tastenkürzel unter tui.keymap an. Ausgewählte Aktionen des Eingabebereichs greifen ersatzweise auf entsprechende tui.keymap.global-Belegungen zurück. Kontextbezogene Belegungen haben Vorrang, sofern sie unterstützt werden. Eine leere Liste hebt die Belegung der Aktion auf.

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

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

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

Befehlsumgebung

Legen Sie fest, welche Umgebungsvariablen Codex an erzeugte Befehle weitergibt. Verwenden Sie schlüsselbasierte Filter, 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 verwendet standardmäßig true. Dadurch wird die automatische Filterung von Variablennamen übersprungen, die KEY, SECRET oder TOKEN enthalten. Setzen Sie den Wert auf false, wenn Sie diese automatische Filterung wünschen. Informationen zu Ausschlussregeln, Rangfolge und Legacy-Konfiguration finden Sie unter Richtlinie für die Shell-Umgebung.

Protokollverzeichnis

Überschreiben Sie den Speicherort, an den Codex lokale Protokolldateien schreibt. Wenn Sie log_dir ausdrücklich festlegen, wird außerdem das optionale TUI-Klartextprotokoll codex-tui.log in diesem Verzeichnis aktiviert.

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

Für einmalige Ausführungen können Sie den Speicherort auch über die CLI festlegen:

codex -c log_dir=./.codex-log

Feature-Flags

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

Häufig verwendete Feature-Flags

Informationen zur Konfiguration von Lifecycle-Hooks finden Sie unter Hooks.

Funktionen aktivieren

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