Verwaltete Konfiguration

Mit der verwalteten Konfiguration steuerst du das unterstützte lokale Laufzeitverhalten der abgedeckten Funktionen 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 ChatGPT-Workspaces, weist keine Lizenzen zu und ersetzt nicht die rollenbasierte Zugriffskontrolle (RBAC) im Workspace. Informationen zum Zugriff auf Workspace-Funktionen findest du unter Rollen und Berechtigungen im Workspace. Diese Seite beschreibt Richtlinien für die lokale Laufzeitumgebung.

Die Unternehmensadministration kann das Verhalten unterstützter lokaler Clients mit folgenden Mitteln steuern:

• Anforderungen: administrativ durchgesetzte Einschränkungen, die Nutzende nicht außer Kraft setzen können.
• Konfigurationsstandardwerte: systemseitig oder in der Cloud verwaltete Einstellungen in config.toml, die Nutzende überschreiben können.
• Veraltete verwaltete Standardwerte: Ausgangswerte aus managed_config.toml, die beim Start eines unterstützten Clients angewendet werden. Nutzende können Einstellungen während der Ausführung weiterhin ändern. Beim nächsten Start wendet der Client diese Standardwerte erneut an.

Plug-in-Marketplaces und Standardwerte konfigurieren

Definiere lokale oder Git-basierte Marketplaces und Standardwerte für Plug-ins in der systemweiten config.toml oder im Abschnitt config.toml unter Verwaltete Konfiguration. Diese Einstellungen sind Standardwerte, keine verbindlich durchgesetzte Richtlinie.

Konfigurationsschlüssel findest du in der Konfigurationsreferenz, Informationen zum Überschreiben unter Rangfolge der Konfiguration und zur Konfiguration auf Projektebene unter Plug-in-Einstellungen für Repositorys. GitHub-Import und Synchronisierung im Workspace sind davon getrennt.

Administrativ durchgesetzte Anforderungen (requirements.toml)

Anforderungen schränken sicherheitsrelevante Einstellungen ein: die Genehmigungsrichtlinie, die für die Prüfung von Genehmigungen zuständige Instanz, die Richtlinie zur automatischen Überprüfung, den Sandbox-Modus, Berechtigungsprofile, den Websuchmodus, verwaltete Hooks sowie die MCP-Server, die Nutzende aktivieren können, und die Quellen für Plug-in-Marketplaces, die sie verwenden können. Wenn bei der Ermittlung der Konfiguration (beispielsweise aus config.toml, Profildateien oder Konfigurationsüberschreibungen per CLI) ein Wert einer verbindlichen Regel widerspricht, greift der lokale Client auf einen kompatiblen Wert zurück und benachrichtigt die nutzende Person. Wenn du eine Positivliste für mcp_servers konfigurierst, aktiviert der Client einen MCP-Server nur dann, wenn sowohl dessen Name als auch dessen Identität mit einem genehmigten Eintrag übereinstimmen. Andernfalls deaktiviert der Client ihn.

Anforderungen können auch Feature-Flags über die Tabelle [features] in requirements.toml einschränken. Funktionen sind zwar nicht immer sicherheitsrelevant, Unternehmen können ihre Werte aber bei Bedarf verbindlich festlegen. Für nicht angegebene Schlüssel gelten keine Einschränkungen.

Verwende ab Codex 0.138.0 vorzugsweise Berechtigungsprofile mit allowed_permission_profiles und einem verwalteten Wert für default_permissions. Verwende allowed_sandbox_modes nur für ältere Bereitstellungen, in denen noch sandbox_mode konfiguriert wird.

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

Die nicht mehr unterstützte Genehmigungsrichtlinie untrusted migrieren

Codex und ChatGPT Work unterstützen approval_policy = "untrusted" nicht mehr. Entferne die Einstellung aus verwalteten Standardwerten, der veralteten managed_config.toml sowie allen Konfigurationen für Nutzende, Projekte, Profile oder den Start, in denen sie festgelegt ist.

Wähle für die interaktive Nutzung ohne Schreibzugriff approval_policy = "on-request" zusammen mit einer Sandbox oder einem Berechtigungsprofil ohne Schreibzugriff, die bzw. das deine verwalteten Anforderungen zulassen. Befehle, die diese Sandbox erlaubt, können ohne Genehmigung ausgeführt werden.

Um strengere Genehmigungsregeln für Befehle beizubehalten, lege approval_policy nicht explizit fest. Setze trust_level = "untrusted" im Projekteintrag der benutzerspezifischen ~/.codex/config.toml und behalte untrusted in allowed_approval_policies bei. Dadurch wird auch die projektlokale Konfiguration deaktiviert. Wenn du on-request explizit festlegst, überschreibt dies diese Richtlinie. Unter Von der nicht mehr unterstützten Genehmigungsrichtlinie untrusted migrieren findest du Beispiele und Informationen zu den damit verbundenen Sicherheitsabwägungen.

Speicherorte und Rangfolge

Jeder unterstützte lokale Client setzt die Anforderungen in aufsteigender Rangfolge zusammen:

1. Systemweite 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. Felder der veralteten managed_config.toml, die der lokale Client als Anforderungen interpretiert.
4. Verwaltete macOS-Einstellungen (MDM), die über com.openai.codex:requirements_toml_base64 bereitgestellt werden.

Ebenen mit höherem Rang überschreiben gewöhnliche Skalar- und Listenwerte aus nachgeordneten Ebenen. Tabellen werden anhand ihrer Schlüssel zusammengeführt. Anforderungen wie Regeln, Hooks und Dateisystemeinschränkungen werden dagegen je nach Feld unterschiedlich kombiniert. 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 Auswahlmöglichkeiten für die Kompatibilität. Verwende requirements.toml für explizite Positivlisten.

In der Cloud verwaltete Anforderungen

Wenn sich eine Person mit ChatGPT und einem unterstützten Tarif anmeldet, können unterstützte lokale Clients administrativ durchgesetzte Anforderungen für den Workspace empfangen. Dies ist ein Bereitstellungskanal für Richtlinien, die mit requirements.toml kompatibel sind. Er gewährt keinen Zugriff auf den Workspace und ersetzt nicht dessen RBAC. Authentifizierungsanforderungen müssen lokal verwaltet werden.

Öffne Verwaltete Konfiguration, um in der Cloud verwaltete Anforderungen zu erstellen und zuzuweisen. Diese Beispielrichtlinie schränkt 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" },
]

Prüfe, ob jede verwaltete Clientversion die 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. Die aktuelle Funktionsweise der Zuweisung 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 Rangfolge beschrieben sind. Verwende die aktuelle Verwaltungsoberfläche, um Anforderungen auf Workspace-Seite zu erstellen und zuzuweisen. Verlasse dich nicht auf einen kopierten Algorithmus zur Gruppenzuordnung. 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 eine Person einen unterstützten lokalen Client startet und sich mit ChatGPT und einem unterstützten Tarif anmeldet, prüft der Client zunächst, ob ein gültiger Cache-Eintrag für diese Identität vorhanden ist. Ist kein gültiger Eintrag verfügbar, ruft der Client das passende Paket ab, wiederholt den Abruf bei Bedarf und schreibt bei Erfolg einen signierten Cache-Eintrag. Wenn die Anfrage fehlschlägt oder das Zeitlimit überschreitet und kein gültiger Cache verfügbar ist, gibt das Laden des Cloud-Konfigurationspakets einen Fehler zurück. Der Client startet dann nicht stillschweigend ohne die in der Cloud verwaltete Anforderungsebene.

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

Verhalten für Administration und Mitarbeitende prüfen

Benenne 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 der Ausweitung des Rollouts mit einer Person aus einer repräsentativen Nutzergruppe sowohl einen genehmigten als auch einen bewusst untersagten Ablauf. Prüfe die tatsächlich wirksamen Einstellungen im unterstützten Client. Gehe nicht davon aus, dass eine Workspace-Rolle oder Gruppe allein 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 requirements.toml oder in den macOS-MDM-Anforderungen fest. Codex ignoriert diese vier Felder in Anforderungen, die in der Cloud verwaltet werden. Lokale Authentifizierungsanforderungen gelten bereits, bevor Anmeldedaten geladen werden und bevor Codex die Cloud-Richtlinie abruft.

Verwende Folgendes, um die ChatGPT-Anmeldung in einem genehmigten Workspace vorzuschreiben und Anmeldedaten im Anmeldedatenspeicher des Betriebssystems zu speichern:

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 die Einstellung weglässt, schränkt sie die Anmeldemethoden nicht ein. Ist sie gesetzt, muss die Liste mindestens eine Methode enthalten. api erlaubt API-Authentifizierung, einschließlich Amazon Bedrock. Die Workspace-Einschränkung gilt auch für Codex-Zugriffstoken.

Die von Nutzenden konfigurierten Werte für forced_login_method und forced_chatgpt_workspace_id müssen den Anforderungen entsprechen. Ein ausgewählter Workspace muss außerdem in der verwalteten Positivliste für Workspaces enthalten sein. Wenn kein Workspace übereinstimmt, ist die ChatGPT-Anmeldung nicht verfügbar. 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 Referenz zu Anforderungen.

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"]

Hier behält untrusted das strengere Genehmigungsverhalten bei, das sich aus trust_level = "untrusted" ergibt. Dadurch wird approval_policy = "untrusted" jedoch nicht zu einer unterstützten expliziten Einstellung.

Appshots deaktivieren

Um Appshots für verwaltete Nutzende zu deaktivieren, setze die Anforderung allow_appshots auf der obersten Ebene:

allow_appshots = false

Wo Appshots verfügbar sind, deaktiviert allow_appshots = false sie. Wenn du den Schlüssel weglässt, schränken die Anforderungen Appshots nicht ein. Dann gelten die üblichen Prüfungen der Produktverfügbarkeit. Clients des App Server, die die wirksamen Anforderungen über configRequirements/read auslesen, erhalten dieselbe Einschränkung als allowAppshots. Wenn allowAppshots fehlt oder den Wert null hat, werden Appshots dadurch nicht deaktiviert.

Gerätefernsteuerung deaktivieren

Um die Gerätefernsteuerung für verwaltete Nutzende zu deaktivieren, setze die Anforderung allow_remote_control auf der obersten Ebene:

allow_remote_control = false

Wo die Gerätefernsteuerung unterstützt wird, deaktiviert allow_remote_control = false sie. 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 Positivliste, die dazu passt, wie deine Nutzenden Berechtigungen auswählen.

Positivlisten für Berechtigungsprofile erfordern Codex 0.138.0 oder neuer. Codex 0.137.0 und ältere Versionen ignorieren allowed_permission_profiles und den verwalteten Wert für default_permissions.

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

Wenn die Tabelle vorhanden ist, bildet sie die vollständige Liste der erlaubten Profile. Sie erlaubt Profile mit dem Wert true und sperrt Profile, die fehlen oder auf false gesetzt sind. Das gilt auch für integrierte Profile, die in künftigen Codex-Versionen hinzukommen.

Standardprofile erlauben

Diese Richtlinie erlaubt die Nutzung ohne Schreibzugriff und den Zugriff auf den Workspace, 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

Die Administration kann ein benutzerdefiniertes Profil in derselben Anforderungsquelle 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

Lass alle integrierten Profile weg, wenn Nutzende nur von Admins 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, obwohl Nutzende das integrierte Profil :workspace nicht direkt auswählen können.

Ein durch eine andere Quelle zugelassenes Profil deaktivieren

Zulassungslisten für Berechtigungen werden anhand der Profilnamen zusammengeführt. Da Anforderungen aus der Cloud Vorrang vor Systemanforderungen haben, lässt sich mit false in den Cloud-Anforderungen ein Profil deaktivieren, das die Systemdatei zulässt.

Cloud-Anforderungen:

default_permissions = ":read-only"

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

Systemanforderungen:

[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. Fehlt die Einstellung, verwendet die lokale Laufzeitumgebung :workspace nur dann als Standard, wenn sowohl :workspace als auch :read-only ausdrücklich zugelassen sind. Fehlt allowed_permission_profiles, schränken die verwalteten Anforderungen die auswählbaren Profilnamen nicht ein. Jeder Eintrag muss ein integriertes Profil oder ein benutzerdefiniertes Profil benennen, das in einer geladenen Konfigurations- oder Anforderungsquelle definiert ist. Definiere benutzerdefinierte Profile in 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. So kannst du beispielsweise für Laptops einen strengeren Standard beibehalten und auf passenden Entwicklungsrechnern oder CI-Runnern Schreibzugriffe auf den Workspace zulassen. 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 bestmöglich ermittelten Hostnamen. Wenn verfügbar, bevorzugt sie den vollständig qualifizierten Domainnamen und greift andernfalls auf den lokalen Hostnamen zurück. Der Abgleich ignoriert Groß- und Kleinschreibung. * steht für eine beliebige Zeichenfolge und ? für ein einzelnes Zeichen.

Innerhalb derselben Anforderungsquelle hat der erste passende Eintrag in [[remote_sandbox_config]] Vorrang. Passt kein Eintrag, behält die lokale Laufzeitumgebung die Einstellung allowed_sandbox_modes auf oberster Ebene 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 der Websuche einschränken:

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

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

Anforderungen für den Netzwerkzugriff konfigurieren

Verwende [experimental_network] in requirements.toml, wenn Admins Anforderungen für den Netzwerkzugriff zentral definieren sollen. Diese Anforderungen sind unabhängig von der benutzerseitigen Einstellung features.network_proxy: Sie können das Netzwerkverhalten der Sandbox ohne dieses Feature-Flag konfigurieren. Sie gewähren Befehlen jedoch 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 von Admins verwaltete Einträge mit "allow" in [experimental_network.domains] definierst und ausschließlich diese Regeln gelten sollen. Steht die Einstellung auf true, ohne dass verwaltete Zulassungsregeln vorliegen, verlieren von Nutzenden hinzugefügte Domain-Zulassungsregeln ihre Wirkung. Kombiniere die kanonische Zuordnung domains nicht mit den älteren Listen allowed_domains oder denied_domains.

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

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

Der Proxy leitet den Netzwerkverkehr lokaler Befehle weiter, die innerhalb der Sandbox ausgeführt werden. Browsertools prüfen außerdem verwaltete Netzwerksperren und exklusive Zulassungslisten, bevor sie auf einen Origin zugreifen. Dies ist eine separate Richtlinienprüfung; der Browserdatenverkehr wird dabei nicht über den Befehlsproxy geleitet. Der Proxy filtert weder Websuche, Apps und Konnektoren, MCP-Server, Datenverkehr nativer Apps, Anfragen an Codex-Dienste noch den Datenverkehr von Codex Cloud. Verwende die jeweiligen Steuerungsmöglichkeiten:

• Verwende allowed_web_search_modes, um die Websuche einzuschränken.
• Verwende features.apps = false, um App- und Konnektorintegrationen 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. Überprüfe die Richtlinie mit den Clientversionen und Betriebssystemen deiner Bereitstellung. 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. Ein Origin umfasst das Schema, den Host und optional den Port, beispielsweise https://example.com oder https://*.example.com:8443. Gib keinen Pfad, keine Abfrage und kein Fragment an. Anders als Domainregeln für den Netzwerkzugriff von Befehlen unterscheiden Origin-Regeln für den 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 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. Eine passende Sperrregel hat Vorrang. Andernfalls liefert die standardmäßige Origin-Richtlinie die Werte für Felder, die passende Regeln nicht festlegen. Die lokale Konfiguration kann Einschränkungen hinzufügen, aber keine verwaltete Sperre lockern. Netzwerksperren und exklusive verwaltete Netzwerk-Zulassungslisten gelten weiterhin.

Setze browser_use.disable_auto_review = true, um die automatische Überprüfung von Genehmigungen für Browseraktionen zu deaktivieren. Oder setze auto_review = "deny" in einer Origin-Richtlinie, um sie für diesen Origin einzuschränken. Dies steuert den Umgang mit Genehmigungen; die Sicherheitsüberwachung des Modells wird dadurch nicht deaktiviert.

Lege für native Apps eine standardmäßige Zugriffsrichtlinie fest und identifiziere die zulässigen Apps. Diese macOS-Richtlinie erlaubt beispielsweise Calculator und verhindert das Speichern von 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 überprüfte Identität der App und nicht nur ihren Anzeigenamen.

Eine vollständige Übersicht der Felder findest du in der Konfigurationsreferenz. Sieh dir außerdem die Einschränkungen für die Nutzung im gesperrten Zustand für verwaltete macOS-Geräte an.

Feature-Flags verbindlich festlegen

Du kannst auch Feature-Flags für Nutzende 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 passt erkannte Funktionen so an, dass sie diesen Festlegungen entsprechen. Sie lehnt widersprüchliche Schreibzugriffe auf Funktionseinstellungen in config.toml oder Profildateien ab.

• 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 Einstellung hat keinen Einfluss auf die externe Paketbereitstellung und verlängert nicht die Unterstützung älterer App-Versionen. Hinweise zum Setup und Rollout findest du unter App-Updates verwalten.
• browser_use = false deaktiviert die Computernutzung in Browsern und macht den Browser-Agenten nicht mehr verfügbar.
• browser_use_full_cdp_access = false deaktiviert den vollständigen CDP-Zugriff in der lokalen Laufzeitumgebung, einschließlich des Entwicklermodus für den Browser. Außerdem verhindert die Einstellung, dass die ChatGPT-Desktop-App die entsprechende Option aktiviert.
• browser_use_external = false deaktiviert die Browser-Funktion für externe Browser.
• computer_use = false deaktiviert die Computernutzung, Aufzeichnen und Wiedergeben sowie die zugehörigen Installations- oder Setup-Abläufe.

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

Computernutzung im gesperrten Zustand einschränken

Füge diese Anforderung hinzu, um zu verhindern, dass Nutzende die Nutzung im gesperrten Zustand auf einem verwalteten Mac aktivieren:

[computer_use]
allow_locked_computer_use = false

Diese Anforderung entfernt die Bedienelemente zum Aktivieren der Nutzung im gesperrten Zustand. Sie deaktiviert diese Funktion nicht, wenn sie bereits aktiviert ist. Wenn du die Anforderung weglässt, gelten weiterhin die normale Produktverfügbarkeit und die lokale Einstellung der nutzenden Person.

Richtlinie für die automatische Überprüfung konfigurieren

Verwende allowed_approvals_reviewers, um die automatische Überprüfung vorzuschreiben oder zuzulassen. Setze die Einstellung auf ["auto_review"], um die automatische Überprüfung vorzuschreiben, oder nimm "user" auf, wenn Nutzende eine 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 durchsetzen

Admins können Lesezugriffe für exakte Pfade oder Glob-Muster mit [permissions.filesystem] verbieten. Nutzende können diese Anforderungen durch lokale Konfiguration nicht 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 Leseverbote vorliegen, lehnt die lokale Laufzeitumgebung Berechtigungen mit Vollzugriff ab und beschränkt die lokale Ausführung auf eine Sandbox ohne Schreibzugriff oder eine Workspace-Sandbox, um die Verbote durchsetzen zu können. Unter nativem Windows gilt die verwaltete Einstellung deny_read für Tools, die direkt auf Dateien zugreifen. Für Lesezugriffe von Shell-Unterprozessen gilt diese Sandbox-Regel nicht.

Verwaltete Hooks über Anforderungen durchsetzen

Admins können verwaltete Lebenszyklus-Hooks auch direkt in requirements.toml definieren. Verwende [hooks] für die Hook-Konfiguration selbst und setze managed_dir auf das Verzeichnis, in dem deine MDM- oder Endpunktverwaltungstools die referenzierten Skripte installieren.

Um verwaltete Hooks auch dann durchzusetzen, wenn Nutzende Hooks lokal deaktiviert haben, lege [features].hooks = true zusätzlich zu [hooks] verbindlich fest. Um Hooks aus Benutzer-, Projekt-, Sitzungs- und Plug-in-Quellen zu überspringen und verwaltete Hooks weiterhin zuzulassen, 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 über absolute Pfade auf Skripte im konfigurierten verwalteten Verzeichnis verweisen.
• 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

Admins können auch einschränkende Befehlsregeln aus requirements.toml mithilfe einer [rules]-Tabelle durchsetzen. Diese Regeln werden mit regulären .rules-Dateien zusammengeführt. Dabei hat weiterhin die restriktivste Entscheidung Vorrang.

Anders als bei .rules müssen Regeln in den Anforderungen decision angeben. Dieser 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 unter mcp_servers eine Liste zugelassener Server hinzu. Verwende für den Abgleich bei stdio-Servern command, 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, wobei reguläre Ausdrücke den gesamten Wert abgleichen. Auch strukturierte Befehlsregeln prüfen weder cwd noch env oder env_vars. Mit Plug-ins gebündelte 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 beschrieben.

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

Um Quellen für Plug-in-Marketplaces einzuschränken, setze restrict_to_allowed_sources = true und definiere eine oder mehrere Quellenregeln:

[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 vorhanden, einen exakten ref-Wert 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. In der Referenz zu requirements.toml findest du das vollständige Schema und Informationen zum Verhalten beim Zusammenführen.

Diese Anforderungen verhindern das Hinzufügen von Marketplaces, die Installation von Plug-ins und die Aktualisierung konfigurierter Git-Marketplaces, wenn keine Quellenregel zutrifft. Außerdem filtern sie zur Laufzeit die konfigurierten Marketplaces und deren Plug-ins.

Auch die von OpenAI kuratierten Git-Marketplaces, einschließlich des Katalogs für die Nutzung mit API-Schlüssel, müssen durch die Liste zugelassener Quellen abgedeckt sein. Um sie zuzulassen, füge die folgende Git-Quelle ohne Einschränkung für ref hinzu:

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

Um die kuratierten Kataloge auszuschließen, lasse diese Quelle weg und stelle sicher, dass keine allgemeinere Host-Regel sie zulässt. Gebündelte Plug-ins und remote installierte Workspace-Plug-ins sind von dieser Richtlinie für kuratierte Git-Quellen unabhängig.

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 lokale config.toml der nutzenden Person und alle über --config in der CLI angegebenen Werte. Nutzende können diese Einstellungen während des aktuellen Laufs weiterhin ändern. Beim nächsten Start des Clients gelten wieder die Standardwerte.

Wenn ein verwalteter Standardwert, ein macOS-MDM-Profil oder eine gespeicherte Konfiguration gpt-5.5 für Personen festlegt, die sich mit ChatGPT bei Codex anmelden, ersetze diesen Wert vor dem 14. Oktober 2026 durch gpt-5.6-sol. Ab diesem Datum ist GPT-5.5 in ChatGPT, ChatGPT Work und Codex in keinem Tarif mehr verfügbar. Die OpenAI API ist davon nicht betroffen. Siehe Verfügbarkeit von Modellen im Workspace.

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 diese 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 davon nicht betroffen. Siehe Verfügbarkeit von Modellen im Workspace.

Stelle sicher, dass deine verwalteten Standardwerte deine Anforderungen erfüllen. Die lokale Laufzeitumgebung weist unzulässige Werte zurück.

Priorität und Konfigurationsebenen

Die lokale Laufzeitumgebung setzt die wirksame Konfiguration in dieser Reihenfolge zusammen (weiter oben stehende Ebenen überschreiben weiter unten stehende):

• Verwaltete Einstellungen (macOS MDM; höchste Priorität)
• managed_config.toml (Systemdatei oder verwaltete Datei)
• config.toml (Basiskonfiguration der nutzenden Person)

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

Für config.toml aus der Cloud gilt die normale Konfigurationspriorität, nicht die oben beschriebene ältere Reihenfolge. Für requirements.toml aus der Cloud gilt die Prioritätsreihenfolge der 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-Payloads unter folgenden Angaben bereitstellt:

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

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

Ablauf des MDM-Setups

Die lokale Laufzeitumgebung unterstützt standardmäßige macOS-MDM-Payloads. Du kannst Einstellungen daher mit Tools wie Jamf Pro, Fleet oder Kandji verteilen. Eine einfache Bereitstellung läuft so ab:

1. Erstelle die verwaltete Payload 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 die Nutzenden anschließend, den unterstützten lokalen Client neu zu starten und zu bestätigen, dass die Konfigurationsübersicht beim Start die verwalteten Werte anzeigt.
4. Wenn du eine Richtlinie zurücknimmst oder änderst, aktualisiere die verwaltete Payload. Der Client liest die aktualisierte Einstellung beim nächsten Start ein.

Vermeide es, Geheimnisse oder dynamische Werte, die sich häufig ändern, in die Payload einzubetten. Behandle die verwaltete TOML-Konfiguration wie jede andere MDM-Einstellung, die der Änderungskontrolle unterliegt.

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 vorzugsweise workspace-write mit Genehmigungen. Beschränke Vollzugriff auf kontrollierte Container.
• Behalte network_access = false bei, sofern dein Sicherheits-Review keinen Collector oder für deine Arbeitsabläufe erforderliche Domains zulässt.
• Nutze 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.