Verwaltete Konfiguration

Die verwaltete Konfiguration steuert das unterstützte lokale Laufzeitverhalten für abgedeckte Funktionen in der ChatGPT-Desktop-App, Codex CLI und der IDE-Erweiterung. Die unterstützten Anforderungen können je nach Client und Version variieren. Die verwaltete Konfiguration gewährt keinen Zugriff auf den ChatGPT-Arbeitsbereich, weist keine Lizenzen zu und ersetzt nicht die rollenbasierte Zugriffskontrolle (RBAC) des Arbeitsbereichs. Verwenden Sie Rollen und Arbeitsbereichsberechtigungen für den Zugriff auf Arbeitsbereichsfunktionen und diese Seite für lokale Laufzeitrichtlinien.

Unternehmensadministratoren können das unterstützte Verhalten lokaler Clients auf zwei Arten steuern:

• Anforderungen: Vom Administrator durchgesetzte Einschränkungen, die Benutzer nicht überschreiben können.
• Verwaltete Standardwerte: Ausgangswerte, die beim Start eines unterstützten Clients angewendet werden. Benutzer können Einstellungen während eines Durchlaufs weiterhin ändern; beim nächsten Start wendet der Client die verwalteten Standardwerte erneut an.

Vom Administrator durchgesetzte Anforderungen (requirements.toml)

Anforderungen schränken sicherheitsrelevante Einstellungen ein (Genehmigungsrichtlinie, Genehmigungsprüfer, Richtlinie für automatische Prüfungen, Sandbox-Modus, Berechtigungsprofile, Websuchmodus, verwaltete Hooks, welche MCP-Server Benutzer aktivieren dürfen und welche vom Benutzer konfigurierten Plugin-Marketplace-Quellen sie hinzufügen, für Installationen verwenden oder aktualisieren dürfen). Wenn beim Auflösen der Konfiguration (beispielsweise aus config.toml, Profildateien oder CLI-Konfigurationsüberschreibungen) ein Wert mit einer durchgesetzten Regel in Konflikt steht, greift der lokale Client auf einen kompatiblen Wert zurück und benachrichtigt den Benutzer. Wenn Sie eine mcp_servers-Zulassungsliste konfigurieren, aktiviert der Client einen MCP-Server nur, wenn sowohl sein Name als auch seine Identität mit einem genehmigten Eintrag übereinstimmen; andernfalls deaktiviert der Client ihn.

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

Bevorzugen Sie für Codex 0.138.0 oder höher Berechtigungsprofile mit allowed_permission_profiles und verwaltetem default_permissions. Verwenden Sie allowed_sandbox_modes nur für ältere Bereitstellungen, die weiterhin sandbox_mode konfigurieren.

Die genaue Schlüsselliste finden Sie im Abschnitt requirements.toml der Konfigurationsreferenz.

Speicherorte und Rangfolge

Jeder unterstützte lokale Client setzt Anforderungen von niedrigerer zu höherer Rangfolge zusammen:

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

Ebenen mit höherer Rangfolge überschreiben gewöhnliche Skalar- und Listenwerte aus Ebenen mit niedrigerer Rangfolge. Tabellen werden nach Schlüsseln zusammengeführt, während Anforderungen wie Regeln, Hooks und Dateisystembeschränkungen ein feldspezifisches Zusammenführungsverhalten aufweisen. Verwenden Sie die Referenz zu requirements.toml für das aktuelle Schema, statt anzunehmen, 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 neu. Diese Konvertierung ergänzt bei Bedarf Kompatibilitätsoptionen; verwenden Sie requirements.toml für explizite Zulassungslisten.

In der Cloud verwaltete Anforderungen

Wenn sich ein Benutzer mit ChatGPT in einem unterstützten Tarif anmeldet, können unterstützte lokale Clients vom Administrator durchgesetzte Anforderungen empfangen, die dem Arbeitsbereich zugeordnet sind. Dies ist ein Bereitstellungskanal für mit requirements.toml kompatible Richtlinien. Er gewährt keinen Zugriff auf den Arbeitsbereich und ersetzt nicht die RBAC des Arbeitsbereichs.

Öffnen Sie Verwaltete Konfiguration, um in der Cloud verwaltete Anforderungen zu erstellen und zuzuweisen. Diese Richtlinie schreibt unterstützten Clients beispielsweise die Datenresidenz in den Vereinigten Staaten vor, schränkt die Auswahl von Genehmigungs- und Sandbox-Optionen ein und fordert eine Bestätigung an, bevor ein unterstützter Shell-Einstiegspunkt ausgeführt wird:

enforce_residency = "us"
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" },
]

Vergewissern Sie sich, dass jede verwaltete Clientversion die ausgewählten Schlüssel unterstützt, und testen Sie die Richtlinie mit einer kleinen Gruppe, bevor Sie sie unternehmensweit zuweisen. Verwenden Sie die Konfigurationsreferenz für das aktuelle Schema und die Administrationsoberfläche für das aktuelle Zuweisungsverhalten.

Der Dienst wählt die unternehmensverwalteten Anforderungsebenen aus, die für die angemeldete Identität gelten. Der lokale Client wertet diese Ebenen zusammen mit den anderen unter Speicherorte und Rangfolge beschriebenen Anforderungsquellen aus. Verwenden Sie die aktuelle Administrationsoberfläche für die Erstellung und Zuweisung im Arbeitsbereich. Verlassen Sie sich nicht auf einen kopierten Algorithmus zur Gruppenzuordnung; der Administrationsdienst bestimmt dieses Verhalten und kann es unabhängig vom lokalen Anforderungsformat ändern.

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

So wenden lokale Clients in der Cloud verwaltete Anforderungen an

Wenn ein Benutzer einen unterstützten lokalen Client startet und sich mit ChatGPT in einem unterstützten Tarif anmeldet, sucht der Client zunächst nach einem gültigen, zur Identität passenden Cache-Eintrag. Ist kein gültiger Eintrag verfügbar, ruft der Client das zutreffende Paket mit Wiederholungsversuchen ab und schreibt bei Erfolg einen signierten Cache-Eintrag. Wenn die Anfrage fehlschlägt oder eine Zeitüberschreitung auftritt und kein gültiger Cache verfügbar ist, gibt das Laden des Cloud-Konfigurationspakets einen Fehler zurück, statt ohne die Ebene der in der Cloud verwalteten Anforderungen unbemerkt zu starten.

Nach dem Auflösen des Caches setzt 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 nicht die bereits in den aktuellen Prozess geladenen 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"]

Appshots deaktivieren

Um Appshots für verwaltete Benutzer zu deaktivieren, legen Sie die Anforderung allow_appshots auf oberster Ebene fest:

allow_appshots = false

Wo Appshots verfügbar sind, deaktiviert allow_appshots = false sie. Wenn Sie den Schlüssel auslassen, schränken die Anforderungen Appshots nicht ein und die normalen Prüfungen der Produktverfügbarkeit gelten. App-Server-Clients, die wirksame Anforderungen über configRequirements/read lesen, erhalten dieselbe Einschränkung wie allowAppshots; ein ausgelassener oder auf null gesetzter Wert allowAppshots deaktiviert Appshots nicht.

Gerätefernsteuerung deaktivieren

Um die Gerätefernsteuerung für verwaltete Benutzer zu deaktivieren, legen Sie die Anforderung allow_remote_control auf oberster Ebene fest:

allow_remote_control = false

Wo die Gerätefernsteuerung unterstützt wird, deaktiviert allow_remote_control = false sie. Wenn Sie den Schlüssel auslassen, schränken die Anforderungen die Gerätefernsteuerung nicht ein und die normalen Prüfungen der Produktverfügbarkeit gelten. Diese Anforderung deaktiviert keine SSH-Remoteverbindungen.

Verfügbare Berechtigungsprofile steuern

Verwenden Sie allowed_permission_profiles, um zu steuern, welche integrierten und benutzerdefinierten Berechtigungsprofile Benutzer auswählen können. Dies ist das Berechtigungsprofil-Gegenstück zu allowed_sandbox_modes; verwenden Sie die Zulassungsliste, die der Art entspricht, wie Ihre Benutzer Berechtigungen auswählen.

Zulassungslisten für Berechtigungsprofile erfordern Codex 0.138.0 oder höher. Codex 0.137.0 und ältere Versionen ignorieren allowed_permission_profiles und verwaltetes default_permissions.

Verwenden Sie die nachstehenden Beispiele für Berechtigungsprofile erst, nachdem alle verwalteten Clients eine unterstützte Version ausführen. Stellen Sie verwaltete benutzerdefinierte Profile erst bereit, wenn das Flottenupgrade abgeschlossen ist.

Ist die Tabelle vorhanden, stellt sie die vollständige Liste zulässiger Profile dar. Sie lässt Profile mit dem Wert true zu und verweigert ausgelassene oder auf false gesetzte Profile, einschließlich integrierter Profile, die in zukünftigen Codex-Versionen hinzukommen.

Standardprofile zulassen

Diese Richtlinie erlaubt schreibgeschützten Zugriff und Arbeitsbereichszugriff, jedoch keinen vollständigen Zugriff:

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

Administratoren können in derselben Anforderungsquelle ein benutzerdefiniertes Profil definieren. Verwenden Sie unternehmensspezifische Profilnamen, die nicht mit Namen in der geladenen Konfiguration der Benutzer kollidieren. Benutzerdefinierte Namen dürfen weder mit : beginnen noch den reservierten Namen filesystem verwenden.

Stellen Sie verwaltete benutzerdefinierte Profile nicht für Clients mit Codex 0.137.0 oder älter bereit. Diese Clients erkennen zwar die Profiltabelle, nicht jedoch den verwalteten Standardwert, der sie auswählt.

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 unternehmensdefinierte Profile zulassen

Lassen Sie alle integrierten Profile aus, wenn Benutzer ausschließlich von Administratoren 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 Benutzer das integrierte Profil :workspace nicht direkt auswählen können.

Ein von einer anderen Quelle zugelassenes Profil deaktivieren

Berechtigungszulassungslisten werden nach Profilnamen zusammengeführt. Da Cloud-Anforderungen eine höhere Rangfolge als Systemanforderungen haben, können Cloud-Anforderungen false verwenden, um ein von der Systemdatei zugelassenes Profil zu deaktivieren.

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.

Setzen Sie default_permissions explizit auf ein zulässiges Profil. Wird der Wert ausgelassen, verwendet die lokale Laufzeitumgebung standardmäßig nur dann :workspace, wenn sowohl :workspace als auch :read-only explizit zugelassen sind. Wenn allowed_permission_profiles fehlt, schränken verwaltete Anforderungen nicht ein, welche Profilnamen Benutzer auswählen können. Jeder Eintrag muss ein integriertes Profil oder ein benutzerdefiniertes Profil benennen, das in einer geladenen Konfigurations- oder Anforderungsquelle definiert ist. Definieren Sie benutzerdefinierte Profile in verwalteten Anforderungen, um deren Verhalten zentral zu steuern.

Sandbox-Anforderungen nach Host überschreiben

Verwenden Sie [[remote_sandbox_config]], wenn eine verwaltete Richtlinie auf unterschiedlichen Hosts unterschiedliche Sandbox-Anforderungen anwenden soll. Sie können beispielsweise einen strengeren Standard für Laptops beibehalten und zugleich Schreibzugriffe auf den Arbeitsbereich auf passenden Entwicklungsrechnern oder CI- Runnern 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 hostname_patterns-Eintrag mit dem nach bestem Bemühen aufgelösten Hostnamen. Wenn verfügbar, bevorzugt sie den vollqualifizierten Domänennamen und greift andernfalls auf den lokalen Hostnamen zurück. Beim Abgleich wird die Groß-/Kleinschreibung nicht berücksichtigt; * entspricht einer beliebigen Zeichenfolge und ? einem einzelnen Zeichen.

Innerhalb derselben Anforderungsquelle gilt der erste passende [[remote_sandbox_config]]-Eintrag. Wenn kein Eintrag passt, behält die lokale Laufzeitumgebung das übergeordnete allowed_sandbox_modes bei. Der Hostnamenabgleich dient ausschließlich der Richtlinienauswahl; behandeln Sie ihn nicht als authentifizierten Gerätenachweis.

Sie können auch den Websuchmodus 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 selbst in danger-full-access-Sitzungen.

Anforderungen für den Netzwerkzugriff konfigurieren

Verwenden Sie [experimental_network] in requirements.toml, wenn Administratoren Anforderungen für den Netzwerkzugriff zentral definieren sollen. Diese Anforderungen sind vom Benutzerschalter features.network_proxy getrennt: Sie können Sandbox- Netzwerkfunktionen ohne dieses Feature-Flag konfigurieren, gewähren Befehlen jedoch keinen Netzwerkzugriff, wenn die aktive Sandbox Netzwerkfunktionen deaktiviert lässt.

experimental_network.enabled = true
experimental_network.allowed_domains = [
  "api.openai.com",
  "*.example.com",
]
experimental_network.denied_domains = [
  "blocked.example.com",
  "*.exfil.example.com",
]

Verwenden Sie experimental_network.managed_allowed_domains_only = true nur, wenn Sie auch administratorseitig verwaltete allowed_domains definieren und diese Zulassungsliste exklusiv verwenden möchten. Ist der Wert ohne verwaltete Zulassungsregeln auf true gesetzt, bleiben vom Benutzer hinzugefügte Regeln zur Domänenzulassung nicht wirksam.

Die Domänensyntax, Regeln für lokale/private Ziele, der Vorrang von Verweigerungen vor Zulassungen und die Einschränkungen beim DNS-Rebinding entsprechen dem unter Agent-Genehmigungen und Sicherheit beschriebenen Netzwerkverhalten der Sandbox.

Feature-Flags fest vorgeben

Sie können für Benutzer, die ein verwaltetes requirements.toml erhalten, auch Feature-Flags fest vorgeben:

[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

Verwenden Sie für Laufzeitfunktionen die maßgeblichen Feature-Schlüssel aus der Tabelle [features] von config.toml. Die lokale Laufzeitumgebung normalisiert erkannte Funktionen entsprechend diesen Vorgaben und weist widersprüchliche Schreibvorgänge in config.toml oder in Funktionseinstellungen von Profildateien zurück.

• in_app_browser = false deaktiviert den integrierten Browserbereich.
• in_app_updates = false deaktiviert beim Neustart, sofern unterstützt, den eigenen Updater der ChatGPT-Desktop-App. Dies wirkt sich weder auf die Bereitstellung über externe Pakete aus noch verlängert es die Unterstützung älterer App-Versionen. Hinweise zur Einrichtung und zum Rollout finden Sie unter App-Updates verwalten.
• browser_use = false deaktiviert Computer Use in Browsern sowie die Verfügbarkeit von Browser Agent.
• browser_use_full_cdp_access = false deaktiviert den vollständigen CDP-Zugriff in der lokalen Laufzeitumgebung einschließlich des Browser-Entwicklermodus und verhindert, dass die ChatGPT-Desktop- App die entsprechende Einstellung aktiviert.
• browser_use_external = false deaktiviert externes Browser Use.
• computer_use = false deaktiviert Computer Use, Record & Replay sowie zugehörige Installations- oder Einrichtungsabläufe.

Wenn Sie diese Schlüssel auslassen, erlaubt die Richtlinie die Funktionen vorbehaltlich der normalen Client-, Plattform- und Rollout-Verfügbarkeit.

Computer Use bei gesperrtem Computer einschränken

Um zu verhindern, dass Computer Use nach dem Sperren eines verwalteten Mac weiterarbeitet, fügen Sie diese Anforderung hinzu:

[computer_use]
allow_locked_computer_use = false

Diese Anforderung aktiviert Computer Use nicht. Sie verhindert lediglich die Nutzung bei gesperrtem Gerät unter macOS. Wenn Sie sie auslassen, schränken Anforderungen die Nutzung bei gesperrtem Gerät nicht ein; die normale Produktverfügbarkeit und die lokale Einstellung des Benutzers gelten weiterhin.

Richtlinie für automatische Prüfungen konfigurieren

Verwenden Sie allowed_approvals_reviewers, um automatische Prüfungen vorzuschreiben oder zuzulassen. Setzen Sie den Wert auf ["auto_review"], um automatische Prüfungen vorzuschreiben, oder schließen Sie "user" ein, wenn Benutzer eine manuelle Genehmigung auswählen dürfen.

Legen Sie guardian_policy_config fest, um den mandantenspezifischen Abschnitt der Richtlinie für automatische Prüfungen zu ersetzen. Die lokale Laufzeitumgebung verwendet weiterhin die integrierte Prüfer- vorlage und den Ausgabevertrag. Verwaltetes guardian_policy_config hat Vorrang vor lokalem [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.
"""

Anforderungen zur Leseverweigerung durchsetzen

Administratoren können mit [permissions.filesystem] Lesezugriffe auf exakte Pfade oder Glob-Muster verweigern. Benutzer können diese Anforderungen nicht durch 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 zur Leseverweigerung vorhanden sind, weist die lokale Laufzeitumgebung Berechtigungen für vollständigen Zugriff zurück und belässt die lokale Ausführung in einer schreibgeschützten oder Arbeitsbereichs-Sandbox, damit sie diese durchsetzen kann. Unter nativem Windows gilt verwaltetes deny_read für direkte Datei- tools; Lesevorgänge von Shell-Unterprozessen verwenden diese Sandbox-Regel nicht.

Verwaltete Hooks aus Anforderungen durchsetzen

Administratoren können verwaltete Lebenszyklus-Hooks auch direkt in requirements.toml definieren. Verwenden Sie [hooks] für die Hook-Konfiguration selbst und lassen Sie managed_dir auf das Verzeichnis verweisen, in dem Ihre MDM- oder Endpunktverwaltungstools die referenzierten Skripte installieren.

Um verwaltete Hooks auch für Benutzer durchzusetzen, die Hooks lokal deaktiviert haben, geben Sie [features].hooks = true zusammen mit [hooks] fest vor. Um Hooks aus Benutzer-, Projekt-, Sitzungs- und Plugin-Quellen zu überspringen, verwaltete Hooks jedoch weiterhin zuzulassen, legen Sie allow_managed_hooks_only = true fest.

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 jedoch nicht die Skripte in managed_dir.
• Stellen Sie diese Skripte mit Ihrer MDM- oder Geräteverwaltungslösung bereit.
• Befehle verwalteter Hooks sollten auf absolute Skriptpfade unterhalb des konfigurierten verwalteten Verzeichnisses verweisen.
• allow_managed_hooks_only = true überspringt Hooks aus Benutzer-, Projekt-, Sitzungs- und Plugin-Quellen, lädt jedoch weiterhin Hooks aus requirements.toml und anderen verwalteten Konfigurationsebenen.

Befehlsregeln aus Anforderungen durchsetzen

Administratoren können über eine Tabelle [rules] auch restriktive Befehlsregeln aus requirements.toml durchsetzen. Diese Regeln werden mit regulären .rules-Dateien zusammengeführt und die restriktivste Entscheidung hat weiterhin Vorrang.

Anders als .rules müssen Anforderungsregeln decision angeben und diese Entscheidung muss "prompt" oder "forbidden" (nicht "allow") lauten.

[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 darf, fügen Sie eine genehmigte Liste mcp_servers hinzu. Gleichen Sie STDIO-Server anhand von command und streamfähige HTTP- Server anhand von url ab:

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

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

Die Zeichenfolgenform von identity.command gleicht nur das konfigurierte command ab. Sie untersucht weder args, cwd, env noch env_vars.

Um einen vollständigen STDIO-Aufruf einzuschränken, gleichen Sie 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, die Anzahl der Argumente und deren Reihenfolge müssen übereinstimmen. Argument- und URL- Regeln unterstützen exact, prefix und den Abgleich des vollständigen Werts mit regex. Strukturierte Befehlsregeln untersuchen weiterhin weder cwd, env noch env_vars. In Plugins gebündelte MCP-Server verwenden dieselben Identitätsformen unter plugins.<plugin>.mcp_servers.<server>.

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

Plugin-Verfügbarkeit steuern

Um Plugins in unterstützten lokalen Clients zu deaktivieren, setzen Sie features.plugins in requirements.toml auf false:

features.plugins = false

Diese Einstellung gilt auch, wenn sich Benutzer mit einem API key bei Codex anmelden. Informationen zur unterstützten Konfiguration finden Sie in der Referenz zu features.plugins.

Plugin-Marketplace-Quellen einschränken

Um Vorgänge mit vom Benutzer konfigurierten Marketplace-Quellen einzuschränken, legen Sie restrict_to_allowed_sources = true fest und definieren Sie eine oder mehrere Quellregeln:

[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, sofern vorhanden, ein exaktes ref ab. Hostmuster sind reguläre Ausdrücke, die mit dem kleingeschriebenen Git- Host abgeglichen werden; verwenden Sie ^ und $ für einen Abgleich des gesamten Hosts. Lokale Regeln erfordern einen absoluten, normalisierten Pfad. Das vollständige Schema und Zusammenführungsverhalten finden Sie in der Referenz zu requirements.toml.

Diese Anforderungen weisen Vorgänge zum Hinzufügen nicht übereinstimmender Marketplaces, zur Plugin-Installation und zur Aktualisierung konfigurierter Git-Marketplaces für vom Benutzer konfigurierte Quellen zurück. Von Codex verwaltete OpenAI-Marketplaces bleiben verfügbar, wenn ihre Quelle und ihr reservierter Name übereinstimmen. Die Anforderungen filtern bereits konfigurierte Benutzer- Marketplaces oder deren Plugins nicht zur Laufzeit.

Diese Quellbeschränkungen gelten nur dort, wo ein lokaler Client Plugin- Marketplace-Vorgänge unterstützt: ChatGPT Work und Codex in der Desktop-App sowie Codex CLI. Sie fügen Chat, der IDE-Erweiterung oder mobilen Apps keine Plugins hinzu.

Verwaltete Standardwerte (managed_config.toml)

Verwaltete Standardwerte werden über dem lokalen config.toml eines Benutzers zusammengeführt und haben Vorrang vor allen CLI-Überschreibungen mit --config. Damit legen sie die Ausgangswerte beim Start eines unterstützten lokalen Clients fest. Benutzer können diese Einstellungen während eines Durchlaufs weiterhin ändern; beim nächsten Start wendet der Client die verwalteten Standardwerte erneut an.

Wenn ein verwalteter Standardwert, ein macOS-MDM-Profil oder eine gespeicherte Konfiguration für mit ChatGPT angemeldete Benutzer gpt-5.4 oder gpt-5.4-mini fest vorgibt, aktualisieren Sie ihn vor dem 31. August 2026. Ersetzen Sie gpt-5.4 durch gpt-5.6-terra und gpt-5.4-mini durch gpt-5.6-luna. Die OpenAI API und Codex bei Authentifizierung mit Ihrem eigenen API key sind nicht betroffen. Siehe Modellverfügbarkeit im Arbeitsbereich.

Stellen Sie sicher, dass Ihre verwalteten Standardwerte Ihren Anforderungen entsprechen; die lokale Laufzeitumgebung weist unzulässige Werte zurück.

Rangfolge und Ebenen

Die lokale Laufzeitumgebung setzt die wirksame Konfiguration in dieser Reihenfolge zusammen (oben überschreibt unten):

• Verwaltete Einstellungen (macOS MDM; höchste Rangfolge)
• managed_config.toml (System-/verwaltete Datei)
• config.toml (Basiskonfiguration des Benutzers)

CLI-Überschreibungen mit --config key=value gelten für die Basis, werden jedoch von verwalteten Ebenen überschrieben. Das bedeutet, dass jeder Durchlauf von den verwalteten Standardwerten ausgeht, selbst wenn Sie lokale Flags angeben.

In der Cloud verwaltete Anforderungen wirken sich auf die Anforderungsebene aus (nicht auf verwaltete Standardwerte). Informationen zur Rangfolge finden Sie oben im Abschnitt zu den vom Administrator durchgesetzten Anforderungen.

Speicherorte

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

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

Verwaltete macOS-Einstellungen (MDM)

Unter macOS können Administratoren ein Geräteprofil bereitstellen, das Base64-codierte TOML-Nutzlasten an folgender Stelle enthält:

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

Die lokale Laufzeitumgebung parst diese Nutzlasten der „verwalteten Einstellungen“ als TOML. Für verwaltete Standardwerte (config_toml_base64) haben verwaltete Einstellungen die höchste Rangfolge. Für Anforderungen (requirements_toml_base64) gilt die oben beschriebene Rangfolge der in der Cloud verwalteten Anforderungen. Dieselbe anforderungsseitige Tabelle [features] funktioniert in requirements_toml_base64; verwenden Sie auch dort die maßgeblichen Feature-Schlüssel.

MDM-Einrichtungsworkflow

Die lokale Laufzeitumgebung unterstützt standardmäßige macOS-MDM-Nutzlasten, sodass Sie Einstellungen mit Tools wie Jamf Pro, Fleet oder Kandji verteilen können. Eine schlanke Bereitstellung sieht wie folgt aus:

1. Erstellen Sie das TOML der verwalteten Nutzlast und codieren Sie es mit base64 (ohne Umbruch).
2. Tragen Sie die Zeichenfolge in Ihrem MDM-Profil unter der Domäne com.openai.codex bei config_toml_base64 (verwaltete Standardwerte) oder requirements_toml_base64 (Anforderungen) ein.
3. Verteilen Sie das Profil und bitten Sie die Benutzer anschließend, den unterstützten lokalen Client neu zu starten und zu bestätigen, dass die Zusammenfassung der Startkonfiguration die verwalteten Werte widerspiegelt.
4. Aktualisieren Sie beim Widerrufen oder Ändern einer Richtlinie die verwaltete Nutzlast; der Client liest die aktualisierte Einstellung beim nächsten Start.

Betten Sie keine Geheimnisse oder häufig wechselnden dynamischen Werte in die Nutzlast ein. Behandeln Sie das verwaltete TOML wie jede andere MDM-Einstellung unter Änderungskontrolle.

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

• Bevorzugen Sie für die meisten Benutzer workspace-write mit Genehmigungen; behalten Sie vollständigen Zugriff kontrollierten Containern vor.
• Behalten Sie network_access = false bei, sofern Ihre Sicherheitsprüfung keinen Collector oder für Ihre Workflows erforderliche Domänen zulässt.
• Verwenden Sie die verwaltete Konfiguration, um OTel-Einstellungen (Exporter, Umgebung) fest vorzugeben, behalten Sie jedoch log_user_prompt = false bei, sofern Ihre Richtlinie das Speichern von Prompt-Inhalten nicht ausdrücklich erlaubt.
• Prüfen Sie regelmäßig die Unterschiede zwischen lokalem config.toml und der verwalteten Richtlinie, um Abweichungen zu erkennen; verwaltete Ebenen sollten Vorrang vor lokalen Flags und Dateien haben.