Verwaltete Konfiguration

Die verwaltete Konfiguration steuert für die abgedeckten Funktionen das unterstützte lokale Laufzeitverhalten in der ChatGPT-Desktop-App, der Codex CLI und der IDE-Erweiterung. Welche Anforderungen unterstützt werden, kann je nach Client und Version variieren. Die verwaltete Konfiguration gewährt keinen Zugriff auf den ChatGPT-Workspace, weist keine Lizenzen zu und ersetzt nicht die rollenbasierte Zugriffskontrolle (RBAC) für den Workspace. Informationen zum Zugriff auf Workspace-Funktionen findest du unter Rollen und Berechtigungen im Workspace. Diese Seite behandelt Richtlinien für die lokale Laufzeit.

Administrierende in Unternehmen können das Verhalten unterstützter lokaler Clients auf zwei Arten steuern:

• Anforderungen: von der Administration durchgesetzte Einschränkungen, die Nutzende nicht überschreiben können.
• Verwaltete Standardwerte: Ausgangswerte, die beim Start eines unterstützten Clients angewendet werden. Nutzende können die Einstellungen während einer Ausführung weiterhin ändern. Beim nächsten Start wendet der Client die verwalteten Standardwerte erneut an.

Von der Administration durchgesetzte Anforderungen (requirements.toml)

Anforderungen schränken sicherheitsrelevante Einstellungen ein: die Genehmigungsrichtlinie, die Prüfinstanz für Genehmigungen, die Richtlinie für die automatische Überprüfung, den Sandbox-Modus, Berechtigungsprofile, den Websuchmodus und verwaltete Hooks. Sie regeln außerdem, welche MCP-Server Nutzende aktivieren dürfen und welche selbst konfigurierten Marketplace-Quellen für Plug-ins sie hinzufügen, für Installationen verwenden oder aktualisieren dürfen. Wenn beim Auflösen der Konfiguration, beispielsweise anhand von config.toml, Profildateien oder Überschreibungen der CLI-Konfiguration, ein Wert einer durchgesetzten Regel widerspricht, greift der lokale Client auf einen kompatiblen Wert zurück und benachrichtigt die Nutzenden. Wenn du eine Zulassungsliste für mcp_servers konfigurierst, aktiviert der Client einen MCP-Server nur, wenn sowohl sein Name als auch seine Identität einem genehmigten Eintrag entsprechen. Andernfalls deaktiviert er ihn.

Anforderungen können auch Feature-Flags über die Tabelle [features] in requirements.toml einschränken. Funktionen sind nicht immer sicherheitsrelevant. Unternehmen können Werte jedoch bei Bedarf fest vorgeben. Nicht angegebene Schlüssel bleiben uneingeschränkt.

Verwende ab Codex 0.138.0 vorzugsweise Berechtigungsprofile mit allowed_permission_profiles und der verwalteten Einstellung default_permissions. Verwende allowed_sandbox_modes nur für ältere Bereitstellungen, die weiterhin sandbox_mode konfigurieren.

Die genaue Liste der Schlüssel findest du im Abschnitt zu requirements.toml in der Konfigurationsreferenz.

Speicherorte und Prioritätsreihenfolge

Jeder unterstützte lokale Client setzt die Anforderungen aus folgenden Quellen zusammen, von niedriger zu höherer Priorität:

1. Systemweite Datei requirements.toml (/etc/codex/requirements.toml auf Unix-Systemen, einschließlich Linux und macOS, oder %ProgramData%\OpenAI\Codex\requirements.toml unter Windows).
2. Vom Unternehmen verwaltete Anforderungen, die im Cloud-Konfigurationspaket bereitgestellt werden.
3. Veraltete Felder in managed_config.toml, die der lokale Client als Anforderungen interpretiert.
4. Verwaltete macOS-Einstellungen (MDM), bereitgestellt über com.openai.codex:requirements_toml_base64.

Ebenen mit höherer Priorität überschreiben reguläre skalare Werte und Listenwerte aus niedriger priorisierten Ebenen. Tabellen werden anhand ihrer Schlüssel zusammengeführt. Für Anforderungen wie Regeln, Hooks und Dateisystemeinschränkungen gelten dagegen feldspezifische Regeln für die Zusammenführung. Das aktuelle Schema findest du in der Referenz zu requirements.toml. Gehe nicht davon aus, dass alle Felder auf dieselbe Weise zusammengeführt werden.

Aus Gründen der Abwärtskompatibilität interpretieren unterstützte lokale Clients die veralteten Felder approval_policy, approvals_reviewer und sandbox_mode als Anforderungen. Diese Umwandlung ergänzt bei Bedarf Kompatibilitätsoptionen. Verwende requirements.toml für explizite Zulassungslisten.

In der Cloud verwaltete Anforderungen

Wenn sich Nutzende mit ChatGPT in einem unterstützten Tarif anmelden, können unterstützte lokale Clients von der Administration durchgesetzte Anforderungen erhalten, die dem Workspace zugeordnet sind. Dies ist ein Bereitstellungskanal für Richtlinien, die mit requirements.toml kompatibel sind. Er gewährt keinen Workspace-Zugriff und ersetzt nicht die RBAC des Workspace. Anforderungen an die Authentifizierung müssen lokal verwaltet werden.

Öffne Verwaltete Konfiguration, um in der Cloud verwaltete Anforderungen zu erstellen und zuzuweisen. Diese Richtlinie schränkt beispielsweise die Auswahlmöglichkeiten für Genehmigungen und die Sandbox ein und fordert eine Bestätigung an, bevor ein unterstützter Shell-Einstiegspunkt ausgeführt wird:

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

Stelle sicher, dass jede verwaltete Client-Version die von dir ausgewählten Schlüssel unterstützt, und teste die Richtlinie mit einer kleinen Gruppe, bevor du sie organisationsweit zuweist. Das aktuelle Schema findest du in der Konfigurationsreferenz. Wie Zuweisungen derzeit funktionieren, kannst du in der Verwaltungsoberfläche prüfen.

Der Dienst wählt die vom Unternehmen verwalteten Anforderungsebenen aus, die für die angemeldete Identität gelten. Der lokale Client wertet diese Ebenen zusammen mit den anderen Anforderungsquellen aus, die unter Speicherorte und Prioritätsreihenfolge beschrieben sind. Verwende die aktuelle Verwaltungsoberfläche, um Anforderungen auf Workspace-Seite zu erstellen und zuzuweisen. Verlasse dich nicht auf einen kopierten Algorithmus zum Gruppenabgleich. Der Verwaltungsdienst steuert dieses Verhalten und kann es unabhängig vom lokalen Anforderungsformat ändern.

Unterstützte Schlüssel und Beispiele findest du unter Beispiel für requirements.toml und in der Referenz zu requirements.toml.

So wenden lokale Clients in der Cloud verwaltete Anforderungen an

Wenn Nutzende einen unterstützten lokalen Client starten und sich mit ChatGPT in einem unterstützten Tarif anmelden, prüft der Client zunächst, ob ein gültiger Cache-Eintrag vorliegt, der zur Identität passt. Ist kein gültiger Eintrag verfügbar, ruft der Client das zutreffende Paket ab, wiederholt den Abruf bei Bedarf und schreibt bei Erfolg einen signierten Cache-Eintrag. Schlägt die Anfrage fehl oder überschreitet sie das Zeitlimit und ist kein gültiger Cache verfügbar, gibt das Laden des Cloud-Konfigurationspakets einen Fehler zurück. Der Client startet also nicht stillschweigend ohne die Ebene der in der Cloud verwalteten Anforderungen.

Nach der Cache-Auflösung führt der Client die Cloud-Anforderungen mit den anderen oben beschriebenen Anforderungsebenen zusammen. Eine Aktualisierung im Hintergrund kann den Cache für einen späteren Start aktualisieren. Sie ersetzt jedoch nicht die Anforderungen, die bereits in den aktuellen Prozess geladen wurden.

Verhalten für Administration und Mitarbeitende prüfen

Bestimme für jede verwaltete Richtlinie eine verantwortliche Person. Halte fest, für welche Nutzenden oder Gruppen sie gelten soll, und dokumentiere den geschäftlichen Grund für jede Einschränkung des Dateisystems, des Netzwerks, der Genehmigungen oder der Berechtigungsprofile.

Teste vor einer Ausweitung des Rollouts mit einer repräsentativen Person einen genehmigten und einen bewusst nicht erlaubten Ablauf. Prüfe die tatsächlich wirksamen Einstellungen im unterstützten Client. Gehe nicht davon aus, dass allein eine Workspace-Rolle oder Gruppe die lokale Einschränkung durchsetzt.

Authentifizierung lokal verwalten

Lege allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store und chatgpt_base_url in der lokalen systemweiten Datei requirements.toml oder in den macOS-MDM-Anforderungen fest. Codex ignoriert diese vier Felder in den in der Cloud verwalteten Anforderungen. Lokale Anforderungen an die Authentifizierung gelten bereits, bevor Anmeldedaten geladen werden und Codex die Cloud-Richtlinie abruft.

Verwende die folgende Konfiguration, um die ChatGPT-Anmeldung bei einem genehmigten Workspace vorzuschreiben und Anmeldedaten im Anmeldedatenspeicher des Betriebssystems abzulegen:

allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]
cli_auth_credentials_store = "keyring"

allowed_login_methods akzeptiert chatgpt, api oder beides. Wenn du diese Einstellung weglässt, schränkt sie die Anmeldemethoden nicht ein. Ist sie gesetzt, muss die Liste mindestens eine Methode enthalten. api erlaubt die API-Authentifizierung, einschließlich Amazon Bedrock. Die Workspace-Einschränkung gilt auch für Codex-Zugriffstoken.

Von Nutzenden konfigurierte Werte für forced_login_method und forced_chatgpt_workspace_id müssen den Anforderungen entsprechen. Ein von Nutzenden ausgewählter Workspace muss außerdem in der verwalteten Workspace-Zulassungsliste enthalten sein. Stimmt kein Workspace überein, ist die ChatGPT-Anmeldung nicht verfügbar. Die API-Authentifizierung bleibt verfügbar, sofern sie erlaubt ist. Ist keine Anmeldemethode verfügbar, verweigert Codex den Start.

Informationen zu den Speichermodi für Anmeldedaten und zur Konfiguration der Dienst-URL findest du in der Anforderungsreferenz .

Beispiel für requirements.toml

Dieses Beispiel blockiert --ask-for-approval never und --sandbox danger-full-access (einschließlich --yolo):

allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Appshots deaktivieren

Um Appshots für verwaltete Nutzende zu deaktivieren, lege die Anforderung allow_appshots auf oberster Ebene fest:

allow_appshots = false

Wo Appshots verfügbar sind, deaktiviert allow_appshots = false diese Funktion. Wenn du den Schlüssel weglässt, schränken die Anforderungen Appshots nicht ein, und es gelten die üblichen Prüfungen der Produktverfügbarkeit. Clients des App Server, die die wirksamen Anforderungen über configRequirements/read lesen, erhalten dieselbe Einschränkung als allowAppshots. Wenn der Wert für allowAppshots fehlt oder null ist, bleiben Appshots aktiviert.

Gerätefernsteuerung deaktivieren

Um die Gerätefernsteuerung für verwaltete Nutzende zu deaktivieren, lege die Anforderung allow_remote_control auf oberster Ebene fest:

allow_remote_control = false

Wo die Gerätefernsteuerung unterstützt wird, wird sie durch allow_remote_control = false deaktiviert. Wenn du den Schlüssel weglässt, schränken die Anforderungen die Gerätefernsteuerung nicht ein, und es gelten die üblichen Prüfungen der Produktverfügbarkeit. Diese Anforderung deaktiviert keine Remote-Verbindungen über SSH.

Verfügbare Berechtigungsprofile steuern

Mit allowed_permission_profiles steuerst du, welche integrierten und benutzerdefinierten Berechtigungsprofile Nutzende auswählen können. Dies ist das Gegenstück zu allowed_sandbox_modes für Berechtigungsprofile. Verwende die Zulassungsliste, die zur Art der Berechtigungsauswahl deiner Nutzenden passt.

Zulassungslisten für Berechtigungsprofile erfordern Codex 0.138.0 oder neuer. Codex 0.137.0 und ältere Versionen ignorieren allowed_permission_profiles und die verwaltete Einstellung default_permissions.

Verwende die folgenden Beispiele für Berechtigungsprofile erst, wenn auf jedem verwalteten Client eine Version läuft, die sie unterstützt. Stelle verwaltete benutzerdefinierte Profile erst bereit, wenn das Upgrade aller Clients abgeschlossen ist.

Wenn die Tabelle vorhanden ist, enthält sie die vollständige Liste der zulässigen Profile. Sie erlaubt Profile, die auf true gesetzt sind, und verweigert nicht aufgeführte oder auf false gesetzte Profile. Das gilt auch für integrierte Profile, die in künftigen Codex-Versionen hinzukommen.

Standardprofile zulassen

Diese Richtlinie erlaubt Zugriff ohne Schreibzugriff sowie Workspace-Zugriff, aber keinen Vollzugriff:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

Einen verwalteten Standardwert mit minimalen Berechtigungen hinzufügen

Administrierende können in derselben Anforderungsquelle ein benutzerdefiniertes Profil definieren. Verwende organisationsspezifische Profilnamen, die nicht mit Namen in der geladenen Konfiguration der Nutzenden kollidieren. Benutzerdefinierte Namen dürfen weder mit : beginnen noch den reservierten Namen filesystem verwenden.

Stelle keine verwalteten benutzerdefinierten Profile auf Clients mit Codex 0.137.0 oder älter bereit. Diese Clients erkennen zwar die Profiltabelle, aber nicht den verwalteten Standardwert, der das Profil auswählt.

Zum Beispiel:

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

Nur vom Unternehmen definierte Profile zulassen

Lasse alle integrierten Profile weg, wenn Nutzende nur von der Administration definierte Profile auswählen sollen:

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Das benutzerdefinierte Profil kann :workspace erweitern, auch wenn Nutzende das integrierte Profil :workspace nicht direkt auswählen können.

Ein von einer anderen Quelle zugelassenes Profil deaktivieren

Berechtigungszulassungslisten werden anhand der Profilnamen zusammengeführt. Da Cloud-Anforderungen eine höhere Priorität als systemweite Anforderungen haben, können Cloud-Anforderungen mit false ein Profil deaktivieren, das in der systemweiten Datei zugelassen ist.

Cloud-Anforderungen:

default_permissions = ":read-only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = false

Systemweite Anforderungen:

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # Not honored because cloud requirements set this to false.

Setze default_permissions ausdrücklich auf ein zulässiges Profil. Wenn du die Einstellung weglässt, verwendet die lokale Laufzeit nur dann standardmäßig :workspace, wenn sowohl :workspace als auch :read-only ausdrücklich zugelassen sind. Wenn allowed_permission_profiles fehlt, schränken verwaltete Anforderungen nicht ein, welche Profilnamen Nutzende auswählen können. Jeder Eintrag muss ein integriertes Profil oder ein benutzerdefiniertes Profil benennen, das in einer geladenen Konfigurations- oder Anforderungsquelle definiert ist. Definiere benutzerdefinierte Profile in den verwalteten Anforderungen, um ihr Verhalten zentral zu steuern.

Sandbox-Anforderungen je nach Host überschreiben

Verwende [[remote_sandbox_config]], wenn eine verwaltete Richtlinie auf verschiedenen Hosts unterschiedliche Sandbox-Anforderungen anwenden soll. Du kannst beispielsweise für Laptops strengere Standardvorgaben beibehalten und auf passenden Entwicklungsrechnern oder CI-Runnern Schreibzugriffe auf den Workspace erlauben. Hostspezifische Einträge überschreiben derzeit nur allowed_sandbox_modes:

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Die lokale Laufzeitumgebung vergleicht jeden Eintrag in hostname_patterns mit dem Hostnamen, den sie bestmöglich ermittelt hat. Wenn verfügbar, verwendet sie bevorzugt den vollständig qualifizierten Domainnamen. Andernfalls greift sie auf den lokalen Hostnamen zurück. Beim Abgleich wird die Groß- und Kleinschreibung ignoriert. * steht für eine beliebige Zeichenfolge und ? für ein einzelnes Zeichen.

Innerhalb derselben Anforderungsquelle gilt der erste passende Eintrag in [[remote_sandbox_config]]. Wenn kein Eintrag passt, behält die lokale Laufzeitumgebung den auf oberster Ebene festgelegten Wert von allowed_sandbox_modes bei. Der Abgleich des Hostnamens dient nur zur Auswahl der Richtlinie. Betrachte ihn nicht als authentifizierten Nachweis der Geräteidentität.

Du kannst auch den Modus für die Websuche einschränken:

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] erlaubt nur "disabled". Beispielsweise verhindert allowed_web_search_modes = ["cached"] die Live-Websuche auch in Sitzungen mit danger-full-access.

Anforderungen an den Netzwerkzugriff konfigurieren

Verwende [experimental_network] in requirements.toml, wenn die Administration Anforderungen an den Netzwerkzugriff zentral festlegen soll. Diese Anforderungen sind unabhängig von der benutzerseitigen Einstellung features.network_proxy: Sie können den Netzwerkzugriff der Sandbox ohne dieses Feature-Flag konfigurieren. Sie gewähren Befehlen aber keinen Netzwerkzugriff, wenn die aktive Sandbox den Netzwerkzugriff deaktiviert hält. Setze experimental_network.enabled = true, um den verwalteten Proxy zu aktivieren. Domainregeln allein aktivieren den Proxy nicht.

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

Verwende experimental_network.managed_allowed_domains_only = true nur, wenn du auch administrativ verwaltete Einträge mit "allow" in [experimental_network.domains] definierst und ausschließlich diese Regeln gelten sollen. Ist der Wert true, ohne dass verwaltete Zulassungsregeln vorliegen, verlieren von Nutzenden hinzugefügte Domain-Zulassungsregeln ihre Wirkung. Kombiniere die kanonische Zuordnung domains nicht mit den veralteten Listen allowed_domains oder denied_domains.

*.example.com erfasst nur Subdomains. **.example.com erfasst die Stammdomain und ihre Subdomains. Eine passende Verbotsregel hat Vorrang vor einer Zulassungsregel.

Für die Domainsyntax, Regeln für lokale und private Ziele, den Vorrang von Verbotsregeln vor Zulassungsregeln und Einschränkungen beim DNS-Rebinding gilt dasselbe wie für den Netzwerkzugriff der Sandbox, der unter Agentenfreigaben und Sicherheit beschrieben ist.

Der Proxy leitet den Netzwerkverkehr lokaler Befehle weiter, die innerhalb der Sandbox ausgeführt werden. Browser-Tools prüfen vor dem Zugriff auf eine Origin außerdem verwaltete Netzwerkverbote und exklusive Zulassungslisten. Dies ist eine separate Richtlinienprüfung; der Browserverkehr wird dabei nicht über den Befehlsproxy geleitet. Der Proxy filtert weder die Websuche noch Apps und Konnektoren, MCP-Server, den Datenverkehr nativer Apps, Anfragen an Codex-Dienste oder den Datenverkehr von Codex Cloud. Verwende die jeweils vorgesehenen Steuerungsmöglichkeiten:

• Verwende allowed_web_search_modes, um die Websuche einzuschränken.
• Verwende features.apps = false, um Integrationen von Apps und Konnektoren zu deaktivieren, und features.plugins = false, um Plug-ins zu deaktivieren, sofern dies unterstützt wird.
• Verwende die verwaltete Zulassungsliste mcp_servers, um MCP-Server einzuschränken.
• Verwende Funktionsanforderungen wie browser_use, in_app_browser und computer_use, um Browserfunktionen und die Computernutzung einzuschränken.
• Konfiguriere den Netzwerkzugriff von Codex Cloud in den Einstellungen der zugehörigen Cloud-Umgebung.

Eine Domain-Zulassungsliste für Befehle ersetzt diese funktionsspezifischen Steuerungsmöglichkeiten nicht.

Browser und Computernutzung steuern

Verwende die Tabellen [browser_use] und [computer_use] in requirements.toml, um unterstützte Desktop-Clients einzuschränken. Prüfe die Richtlinie mit den Client-Versionen und Betriebssystemen, die du einsetzt. Eine konfigurierte Zulassungsregel installiert kein Plug-in, erteilt keine Betriebssystemberechtigung und genehmigt keine Aktion, die weiterhin überprüft werden muss.

Konfiguriere für den Browserzugriff eine Origin-Richtlinie. Eine Origin umfasst das Schema, den Host und optional den Port, etwa https://example.com oder https://*.example.com:8443. Gib weder Pfad noch Abfrageparameter oder Fragment an. Anders als Domainregeln für den Netzwerkzugriff von Befehlen unterscheiden Origin-Regeln für Browser zwischen HTTP und HTTPS und gleichen den Port ab.

Dieses Beispiel beschränkt den Browserzugriff auf eine zugelassene Website und verhindert dort Uploads sowie den vollständigen Zugriff über das Chrome DevTools Protocol (CDP):

[browser_use]
allow_history_access = false
allow_global_persistent_approval = false

[browser_use.default_origin_policy]
access = "deny"

[browser_use.origins."https://example.com"]
access = "allow"
uploads = "deny"
downloads = "allow"
full_cdp_access = "deny"
persistent_approval = false
access_approval_lifetime = "turn"

Passende Origin-Regeln werden für jedes Feld einzeln ausgewertet. Ein passendes Verbot hat Vorrang. Andernfalls liefert die Standardrichtlinie für Origins die Werte für Felder, die in den passenden Regeln nicht festgelegt sind. Die lokale Konfiguration kann weitere Einschränkungen hinzufügen, aber ein verwaltetes Verbot nicht lockern. Netzwerkverbote und exklusive verwaltete Netzwerk-Zulassungslisten gelten weiterhin.

Setze browser_use.disable_auto_review = true, um die automatische Prüfung von Genehmigungsanfragen für Browseraktionen zu deaktivieren. Oder setze auto_review = "deny" in einer Origin-Richtlinie, um sie für diese Origin einzuschränken. Dies steuert die Verarbeitung von Genehmigungen. Die Sicherheitsüberwachung des Modells wird dadurch nicht deaktiviert.

Lege für native Apps eine Standardrichtlinie für den Zugriff fest und gib die zulässigen Apps an. Diese macOS-Richtlinie erlaubt beispielsweise den Taschenrechner und verhindert gespeicherte Genehmigungen:

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Windows-Richtlinien können paketierte Apps über computer_use.windows.aumids oder ausführbare Dateien über computer_use.windows.exes identifizieren. Regeln für ausführbare Dateien erfordern publisher_name, product_name und access; binary_name ist optional. Verwende die verifizierte Identität der App und nicht nur ihren Anzeigenamen.

Alle Felder findest du in der Konfigurationsreferenz. Für verwaltete macOS-Geräte findest du außerdem Informationen zu den Einschränkungen der Nutzung bei gesperrtem Computer im entsprechenden Abschnitt.

Feature-Flags verbindlich festlegen

Du kannst auch Feature-Flags für Personen verbindlich festlegen, die eine verwaltete requirements.toml erhalten:

[features]
personality = true
unified_exec = false

# Disable surface-specific features when needed.
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false

Verwende für Laufzeitfunktionen die kanonischen Funktionsschlüssel aus der Tabelle [features] in config.toml. Die lokale Laufzeitumgebung normalisiert erkannte Funktionen so, dass sie diesen verbindlichen Vorgaben entsprechen. Sie weist widersprüchliche Schreibzugriffe auf config.toml oder auf Funktionseinstellungen in Profildateien zurück.

• in_app_browser = false deaktiviert den integrierten Browserbereich.
• in_app_updates = false deaktiviert beim Neustart die integrierte Updatefunktion der ChatGPT-Desktop-App, sofern dies unterstützt wird. Die externe Paketbereitstellung bleibt davon unberührt, und der Support für ältere App-Versionen wird dadurch nicht verlängert. Hinweise zu Setup und Rollout findest du unter App-Updates verwalten.
• browser_use = false deaktiviert die Computernutzung in Browsern und macht den Browser-Agenten unverfügbar.
• browser_use_full_cdp_access = false deaktiviert den vollständigen CDP-Zugriff in der lokalen Laufzeitumgebung, einschließlich des Browser-Entwicklungsmodus, und verhindert, dass die ChatGPT-Desktop-App die entsprechende Einstellung aktiviert.
• browser_use_external = false deaktiviert die externe Browserfunktion.
• computer_use = false deaktiviert Computernutzung, Aufzeichnen und Wiedergeben sowie zugehörige Installations- oder Setup-Abläufe.

Wenn du diese Schlüssel weglässt, erlaubt die Richtlinie die Funktionen. Ihre Verfügbarkeit hängt weiterhin wie üblich vom Client, der Plattform und dem Rollout ab.

Computernutzung bei gesperrtem Gerät einschränken

Um zu verhindern, dass Nutzende die Nutzung bei gesperrtem Computer auf einem verwalteten Mac aktivieren, füge diese Anforderung hinzu:

[computer_use]
allow_locked_computer_use = false

Diese Anforderung entfernt die Bedienelemente zum Aktivieren der Nutzung bei gesperrtem Computer. Ist die Funktion bereits aktiviert, wird sie dadurch nicht deaktiviert. Wenn du die Anforderung weglässt, gelten weiterhin die normale Produktverfügbarkeit und die lokale Einstellung der jeweiligen Person.

Richtlinie für die automatische Überprüfung konfigurieren

Verwende allowed_approvals_reviewers, um die automatische Überprüfung vorzuschreiben oder zu erlauben. Setze den Wert auf ["auto_review"], um die automatische Überprüfung vorzuschreiben, oder nimm "user" auf, wenn Nutzende die manuelle Genehmigung wählen dürfen.

Setze guardian_policy_config, um den mandantenspezifischen Abschnitt der Richtlinie für die automatische Überprüfung zu ersetzen. Die lokale Laufzeitumgebung verwendet weiterhin die integrierte Vorlage für die Überprüfung und die festgelegten Ausgabevorgaben. Die verwaltete Einstellung guardian_policy_config hat Vorrang vor der lokalen Einstellung [auto_review].policy.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

Leseverbote durch Anforderungen durchsetzen

Die Administration kann Lesezugriffe für exakte Pfade oder Glob-Muster mit [permissions.filesystem] verbieten. Nutzende können diese Anforderungen nicht durch ihre lokale Konfiguration abschwächen.

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

Wenn Anforderungen Lesezugriffe verbieten, lehnt die lokale Laufzeitumgebung Berechtigungen für den Vollzugriff ab und führt lokale Aktionen weiterhin in einer Sandbox ohne Schreibzugriff oder in einer Workspace-Sandbox aus, damit sie die Anforderungen durchsetzen kann. Unter nativem Windows gilt das verwaltete deny_read für direkte Dateitools. Lesezugriffe von Shell-Unterprozessen verwenden diese Sandbox-Regel nicht.

Verwaltete Hooks über Anforderungen durchsetzen

Die Administration kann verwaltete Lebenszyklus-Hooks auch direkt in requirements.toml definieren. Verwende [hooks] für die eigentliche Hook-Konfiguration und setze managed_dir auf das Verzeichnis, in dem deine MDM- oder Endpunktverwaltung die referenzierten Skripte installiert.

Um verwaltete Hooks auch für Personen durchzusetzen, die Hooks lokal deaktiviert haben, lege zusätzlich zu [hooks] auch [features].hooks = true verbindlich fest. Um Hooks aus Benutzer-, Projekt-, Sitzungs- und Plug-in-Quellen zu überspringen und verwaltete Hooks weiterhin zu erlauben, setze allow_managed_hooks_only = true.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

Hinweise:

• Die lokale Laufzeitumgebung setzt die Hook-Konfiguration aus requirements.toml durch, verteilt aber nicht die Skripte in managed_dir.
• Verteile diese Skripte mit deiner MDM- oder Geräteverwaltungslösung.
• Befehle verwalteter Hooks sollten absolute Pfade zu Skripten im konfigurierten verwalteten Verzeichnis verwenden.
• allow_managed_hooks_only = true überspringt Hooks aus Benutzer-, Projekt-, Sitzungs- und Plug-in-Quellen, lädt aber weiterhin Hooks aus requirements.toml und anderen verwalteten Konfigurationsebenen.

Befehlsregeln über Anforderungen durchsetzen

Die Administration kann auch einschränkende Befehlsregeln aus requirements.toml mit einer Tabelle [rules] durchsetzen. Diese Regeln werden mit regulären .rules-Dateien zusammengeführt. Dabei gilt weiterhin die restriktivste Entscheidung.

Anders als bei .rules muss für Regeln in den Anforderungen decision angegeben werden. Der Wert muss "prompt" oder "forbidden" sein (nicht "allow").

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

Um einzuschränken, welche MCP-Server ein lokaler Client aktivieren kann, füge eine Zulassungsliste mcp_servers hinzu. Gleiche bei stdio-Servern command ab und bei Servern mit Streamable HTTP url:

[mcp_servers.docs]
identity = { command = "codex-mcp" }

[mcp_servers.remote]
identity = { url = "https://example.com/mcp" }

Die Zeichenfolgenform von identity.command gleicht nur den konfigurierten Wert von command ab. Sie prüft weder args noch cwd, env oder env_vars.

Um einen vollständigen stdio-Aufruf einzuschränken, gleiche die ausführbare Datei und jedes Positionsargument ab:

[mcp_servers.internal.identity]
command = { executable = "/usr/local/bin/codex-mcp", args = [
  { match = "exact", value = "serve" },
  { match = "prefix", value = "--workspace=" },
] }

Die ausführbare Datei sowie Anzahl und Reihenfolge der Argumente müssen übereinstimmen. Regeln für Argumente und URLs unterstützen den Abgleich mit exact, prefix und regex über den gesamten Wert. Auch strukturierte Befehlsregeln prüfen weder cwd noch env oder env_vars. In Plug-ins enthaltene MCP-Server verwenden dieselben Identitätsstrukturen unter plugins.<plugin>.mcp_servers.<server>.

Wenn mcp_servers vorhanden, aber leer ist, deaktiviert der lokale Client alle MCP-Server.

Verfügbarkeit von Plug-ins steuern

Um Plug-ins in unterstützten lokalen Clients zu deaktivieren, setze features.plugins in requirements.toml auf false:

features.plugins = false

Diese Einstellung gilt auch, wenn sich Nutzende mit einem API-Schlüssel bei Codex anmelden. Informationen zur unterstützten Konfiguration findest du in der Referenz zu features.plugins.

Quellen für Plug-in-Marketplaces einschränken

Um Vorgänge für selbst konfigurierte Marketplace-Quellen einzuschränken, setze restrict_to_allowed_sources = true und definiere mindestens eine Regel für Quellen:

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

Git-Regeln gleichen die normalisierte Repository-URL und, falls angegeben, einen exakten ref ab. Host-Muster sind reguläre Ausdrücke, die mit dem kleingeschriebenen Git-Host abgeglichen werden. Verwende ^ und $, um den gesamten Hostnamen abzugleichen. Lokale Regeln erfordern einen absoluten, normalisierten Pfad. Das vollständige Schema und das Verhalten beim Zusammenführen findest du in der Referenz zu requirements.toml.

Diese Anforderungen verhindern bei selbst konfigurierten Quellen das Hinzufügen von Marketplaces, das Installieren von Plug-ins und das Aktualisieren konfigurierter Git-Marketplaces, wenn keine Regel zutrifft. Von Codex verwaltete OpenAI-Marketplaces bleiben verfügbar, wenn ihre Quelle und ihr reservierter Name übereinstimmen. Bereits selbst konfigurierte Marketplaces und deren Plug-ins werden durch die Anforderungen zur Laufzeit nicht gefiltert.

Diese Quellenbeschränkungen gelten nur dort, wo ein lokaler Client Vorgänge für Plug-in-Marketplaces unterstützt: in ChatGPT und Codex in der Desktop-App sowie in Codex CLI. Sie steuern nicht die Nutzung von Plug-ins in ChatGPT im Web oder auf Mobilgeräten und fügen der IDE-Erweiterung keine Plug-ins hinzu.

Verwaltete Standardwerte (managed_config.toml)

Verwaltete Standardwerte legen fest, mit welcher Konfiguration ein unterstützter lokaler Client startet. Beim Start überschreiben sie die persönliche lokale config.toml und alle per CLI mit --config angegebenen Werte. Nutzende können diese Einstellungen während des aktuellen Laufs weiterhin ändern. Beim nächsten Start des Clients gelten die Standardwerte erneut.

Wenn ein verwalteter Standardwert, ein macOS-MDM-Profil oder eine gespeicherte Konfiguration gpt-5.4 oder gpt-5.4-mini für Personen festlegt, die mit ChatGPT angemeldet sind, aktualisiere die entsprechende Einstellung vor dem 31. August 2026. Ersetze gpt-5.4 durch gpt-5.6-terra und gpt-5.4-mini durch gpt-5.6-luna. Die OpenAI API und Codex mit Authentifizierung über deinen eigenen API-Schlüssel sind nicht betroffen. Siehe Modellverfügbarkeit im Workspace.

Stelle sicher, dass deine verwalteten Standardwerte deinen Anforderungen entsprechen. Die lokale Laufzeitumgebung lehnt unzulässige Werte ab.

Priorität und Konfigurationsebenen

Die lokale Laufzeitumgebung setzt die wirksame Konfiguration in dieser Reihenfolge zusammen (weiter oben aufgeführte Ebenen überschreiben die darunterliegenden):

• Verwaltete Einstellungen (macOS MDM; höchste Priorität)
• managed_config.toml (Systemdatei bzw. verwaltete Datei)
• config.toml (persönliche Basiskonfiguration)

Per CLI mit --config key=value angegebene Werte überschreiben die Basiskonfiguration, werden aber ihrerseits von verwalteten Ebenen überschrieben. Jeder Lauf startet daher mit den verwalteten Standardwerten, auch wenn du lokale Flags angibst.

Cloudverwaltete Anforderungen wirken auf die Anforderungsebene (nicht auf die verwalteten Standardwerte). Die Prioritätsreihenfolge findest du oben im Abschnitt „Von Admins erzwungene Anforderungen“.

Speicherorte

• Linux/macOS (Unix): /etc/codex/managed_config.toml
• Windows/Nicht-Unix-Systeme: ~/.codex/managed_config.toml

Wenn die Datei fehlt, überspringt die lokale Laufzeitumgebung die verwaltete Ebene.

Verwaltete macOS-Einstellungen (MDM)

Unter macOS können Admins ein Geräteprofil verteilen, das Base64-kodierte TOML-Nutzdaten an folgender Stelle bereitstellt:

• Einstellungsdomäne: com.openai.codex
• Schlüssel:
  • config_toml_base64 (verwaltete Standardwerte)
  • requirements_toml_base64 (Anforderungen)

Die lokale Laufzeitumgebung liest die Nutzdaten dieser „verwalteten Einstellungen“ als TOML ein. Bei verwalteten Standardwerten (config_toml_base64) haben verwaltete Einstellungen die höchste Priorität. Bei Anforderungen (requirements_toml_base64) gilt die oben beschriebene Reihenfolge für cloudverwaltete Anforderungen. Die gleiche [features]-Tabelle für Anforderungen funktioniert auch in requirements_toml_base64. Verwende auch dort die kanonischen Feature-Schlüssel.

Ablauf des MDM-Setups

Die lokale Laufzeitumgebung berücksichtigt standardmäßige macOS-MDM-Nutzdaten. Daher kannst du Einstellungen mit Tools wie Jamf Pro, Fleet oder Kandji verteilen. Eine einfache Bereitstellung läuft so ab:

1. Erstelle die verwalteten Nutzdaten im TOML-Format und kodiere sie mit base64 (ohne Zeilenumbrüche).
2. Füge die Zeichenfolge in deinem MDM-Profil in der Domäne com.openai.codex unter config_toml_base64 (verwaltete Standardwerte) oder requirements_toml_base64 (Anforderungen) ein.
3. Verteile das Profil. Bitte anschließend die Nutzenden, den unterstützten lokalen Client neu zu starten und zu bestätigen, dass die beim Start angezeigte Konfigurationsübersicht die verwalteten Werte enthält.
4. Wenn du eine Richtlinie aufhebst oder änderst, aktualisiere die verwalteten Nutzdaten. Der Client liest die aktualisierte Einstellung beim nächsten Start ein.

Vermeide es, Geheimnisse oder dynamische Werte, die sich häufig ändern, in die Nutzdaten einzubetten. Behandle die verwaltete TOML-Konfiguration wie jede andere MDM-Einstellung, deren Änderungen kontrolliert werden.

Beispiel für managed_config.toml

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = "otlp-http"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

Empfohlene Schutzmaßnahmen

• Verwende für die meisten Nutzenden bevorzugt workspace-write mit Genehmigungen. Beschränke Vollzugriff auf kontrollierte Container.
• Behalte network_access = false bei, sofern dein Sicherheits-Review keinen Collector oder Domains zulässt, die für deine Arbeitsabläufe erforderlich sind.
• Verwende die verwaltete Konfiguration, um OTel-Einstellungen (Exporter, Umgebung) festzulegen. Behalte jedoch log_user_prompt = false bei, sofern deine Richtlinie das Speichern von Prompt-Inhalten nicht ausdrücklich erlaubt.
• Prüfe regelmäßig die Unterschiede zwischen der lokalen config.toml und der verwalteten Richtlinie, um Abweichungen zu erkennen. Verwaltete Ebenen sollten Vorrang vor lokalen Flags und Dateien haben.