Verwaltete Konfiguration

Mit der verwalteten Konfiguration können Unternehmensadministratoren unterstützte Anforderungen und Standardwerte für ChatGPT Work und Codex festlegen. Anforderungen schränken ein, was Benutzer und Aufgaben tun können. Standardwerte liefern Ausgangswerte. Die Unterstützung hängt vom Produkt, der Clientversion und der Ausführungsumgebung ab.

Beginnen Sie für unterstützte cloudverwaltete Einstellungen unter Agent Security in der Admin-Konsole. Verwenden Sie die Einstellungssteuerelemente für gängige Aufgaben, oder wählen Sie Als TOML bearbeiten, um den Konfigurationstext zu prüfen, zu kopieren oder zu bearbeiten. Beide Ansichten bearbeiten dieselbe Richtlinie; TOML bietet zudem Zugriff auf unterstützte Felder ohne eigenes Steuerelement. Sie müssen keine lokale Datei verteilen, um cloudverwaltete Einstellungen zu verwenden. Für Authentifizierungseinschränkungen und geräteverwaltete Bereitstellungen gibt es eine separate lokale Einrichtung.

Enterprise-Administratoren können das unterstützte Verhalten lokaler Clients mit folgenden Mitteln steuern:

• Anforderungen: von Administratoren durchgesetzte Einschränkungen, die Benutzer nicht überschreiben können.

• Konfigurationsstandardwerte: vom System oder über die Cloud verwaltete config.toml-Einstellungen, die Benutzer überschreiben können.

• Ältere verwaltete Standardwerte: managed_config.toml-Ausgangswerte, die beim Start eines unterstützten Clients angewendet werden. Benutzer können Einstellungen während eines Laufs weiterhin ändern. Beim nächsten Start wendet der Client diese Standardwerte erneut an.

Informationen zur Global-Basiskonfiguration, zu umgebungsspezifischen Überschreibungen und zu den Feldlisten für Orchestrator und Executor finden Sie unter Agent Security.

Eine Richtlinie unter Agent Security konfigurieren

Wenn Agent Security aktiviert ist, können Workspace-Inhaber, Workspace-Administratoren und Mitglieder mit Codex-Administratorberechtigungen Richtlinien verwalten. Der Zugriff auf den Richtlinieneditor gewährt Mitgliedern keinen Zugriff auf die Funktionen, die eine Richtlinie steuert.

Verwenden Sie Workspace-Standard für die Basiskonfiguration des Workspace. Verwenden Sie Überschreibungen, wenn bestimmte Benutzer, Gruppen oder Rollen andere Einstellungen benötigen. Eine zielgruppenbezogene Überschreibung legt fest, wer eine Richtlinie erhält; eine Umgebungseinstellung legt fest, wo unterstützte Ausführungssteuerungen gelten.

1. Öffnen Sie Admin-Konsole > Agent Security und wählen Sie Workspace-Standard oder unter Überschreibungen die Richtlinie, die Sie bearbeiten möchten.
2. Öffnen Sie Anforderungen, um verbindliche Grenzen festzulegen, oder Standardwerte, um Ausgangswerte festzulegen, die Mitglieder innerhalb dieser Grenzen ändern können.
3. Belassen Sie Genehmigungs-, Websuche- und andere agentenweite Einstellungen unter Global. Verwenden Sie, sofern verfügbar, Umgebungseinstellungen hinzufügen in der jeweiligen Karte, um Lokale Umgebungen oder Codex Cloud-Umgebungen für unterstützte Ausführungseinstellungen hinzuzufügen. Ein leeres Umgebungsdokument erbt Einstellungen von Global; es kopiert die aktuelle Basiskonfiguration nicht und schreibt sie auch nicht fest.
4. Verwenden Sie die in diesem Leitfaden beschriebenen Steuerelemente. Wählen Sie für erweiterte Felder Als TOML bearbeiten und bearbeiten Sie requirements.toml oder config.toml des entsprechenden Geltungsbereichs. Wählen Sie Einstellungssteuerelemente verwenden, um zum visuellen Editor zurückzukehren.
5. Prüfen Sie die Validierungsmeldungen und wählen Sie dann Änderungen speichern. Das Anwenden einer Regel in einem Regeleditor aktualisiert den Entwurf; die Richtlinie wird dadurch allein nicht gespeichert.
6. Prüfen Sie die Richtlinienauswahl und das Verhalten unterstützter Clients wie unter Die Erfahrung von Administratoren und Mitarbeitern überprüfen beschrieben.

Umgebungseditoren und unterstützte Felder hängen vom Workspace und der Richtlinie ab. Lesen Sie Wo Einstellungen gelten, bevor Sie eine Einstellung aus Global in eine Umgebung verschieben. Eine Einstellung unter Global gilt nicht zwangsläufig für jedes Produkt oder jeden Ausführungspfad.

Eine Konfiguration kopieren oder wiederverwenden

Der visuelle Editor ersetzt TOML nicht. Wählen Sie Als TOML bearbeiten, um eine Konfiguration zu kopieren, eine Referenzkopie aufzubewahren oder Einstellungen in einer anderen Richtlinie wiederzuverwenden. Wählen Sie Einstellungssteuerelemente verwenden, um zum visuellen Editor zurückzukehren.

1. Öffnen Sie die Quellrichtlinie und wählen Sie Als TOML bearbeiten.
2. Wählen Sie den Geltungsbereich, den Sie kopieren möchten: Global oder eine verfügbare Umgebungsregisterkarte. Kopieren Sie den Text aus Anforderungen (requirements.toml), Standardwerte (config.toml) oder beiden, je nachdem, was Sie wiederverwenden möchten.
3. Öffnen Sie die Zielrichtlinie, wählen Sie Als TOML bearbeiten und wählen Sie den passenden Geltungsbereich. Fügen Sie Anforderungen in requirements.toml und Standardwerte in config.toml ein. Prüfen Sie die vorhandenen Zieleinstellungen, bevor Sie Text ersetzen; behalten Sie andere Einstellungen bei, die weiterhin gelten sollen.
4. Prüfen Sie die Validierungsmeldungen sowie die Zielgruppen und die Priorität der Zielrichtlinie und wählen Sie dann Änderungen speichern. Überprüfen Sie das resultierende Clientverhalten, bevor Sie sich auf die kopierte Richtlinie verlassen.

Der kopierte Text enthält die für diese Richtlinie und diesen Geltungsbereich festgelegten Einstellungen. Er enthält weder Zuweisungen, die Richtlinienreihenfolge, andere Umgebungsdokumente noch die effektive Konfiguration, die aus anderen Richtlinien und Geräteeinstellungen zusammengeführt wird. Kopieren Sie Umgebungseinstellungen bei Bedarf separat. Das Wechseln der Ansicht oder Kopieren von Text speichert keine Richtlinienänderung.

Probieren Sie das folgende Beispiel aus: Ändern Sie eine Einstellung und wählen Sie dann Als TOML bearbeiten, um die zugehörige Konfiguration anzuzeigen. Wechseln Sie mit Einstellungssteuerelemente verwenden zurück, um weiter zu experimentieren.

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only"]
allowed_web_search_modes = ["disabled"]

Das passende Steuerelement auswählen

Browser und Computer Use steuern

Verwenden Sie Agent Security in der Admin-Konsole, um Browser- und native App-Zugriffe für unterstützte Desktop-Clients zu verwalten. Beginnen Sie mit den Steuerelementen der Benutzeroberfläche. Die folgenden TOML-Beispiele dienen als Konfigurationsreferenz für die dateibasierte Richtlinienbereitstellung und für Einstellungen, die den TOML-Editor erfordern.

Browser Use steuert agentengesteuerte Aktivitäten in einem Browser. Computer Use steuert agentengesteuerte Aktivitäten in nativen Desktop-Apps. Die Einstellungen für den integrierten Browserbereich sind von Browser Use getrennt. Lesen Sie Browsersitzungen und bestehende Anmeldungen zu den Unterschieden zwischen den Browserzugriffswegen.

Bevor Sie beginnen

Verwenden Sie ein Konto mit der Berechtigung, Richtlinien in Agent Security zu verwalten. Prüfen Sie, welche Personen die Richtlinie erhalten und welche Clientversionen und Betriebssysteme Sie unterstützen müssen. Informationen zu Richtlinienzuweisungen finden Sie unter Agent Security, ebenso zu Global-Einstellungen und unterstützten Umgebungsüberschreibungen.

Verwenden Sie Anforderungen für Grenzen, die Benutzer nicht außer Kraft setzen können. Standardwerte legen Ausgangswerte innerhalb dieser Grenzen fest. Das Zulassen einer Website oder App installiert kein Plugin, gewährt keine Betriebssystemberechtigungen, meldet keinen Benutzer an und genehmigt keine Aktion, die weiterhin geprüft werden muss.

Prüfen Sie unter Verfügbarkeit von Desktop-Funktionen die Optionen Browsernutzung, Externe Browsernutzung und Computernutzung. Deaktivierung erzwingen deaktiviert die jeweilige Funktion; eine Zulassungsregel für eine Website oder App setzt dies nicht außer Kraft. Prüfen Sie Vollständiger CDP-Zugriff separat; Aktivierung durch Benutzer blockieren verhindert, dass Benutzer ihn aktivieren.

Diese Desktop-Steuerelemente konfigurieren den gehosteten Work Cloud-Browser nicht. Verwalten Sie Cloud-Browsernutzung und Cloud-Netzwerkzugriff separat unter Administrationskonsole > Berechtigungen und Rollen > Workspace-Funktionen > Cloud-Computerfunktionen. Siehe Anwendung von Agent Security auf Work Cloud.

Browserzugriff konfigurieren

1. Öffnen Sie Administrationskonsole > Agent Security. Verwenden Sie Workspace-Standard für die Grundeinstellungen des Workspace oder öffnen Sie die entsprechende Richtlinie unter Überschreibungen. Wechseln Sie unter Anforderungen zu Desktop-Browsersteuerung.
2. Öffnen Sie unter Website-Regeln die Aktionen der Zeile Standard und wählen Sie Standard bearbeiten. Um den Zugriff auf genehmigte Websites zu beschränken, setzen Sie Website-Zugriff auf Blockieren und wählen Sie Regel anwenden. Die Zeile Standard liefert die Werte, die eine passende Website-Regel auf Standardregel verwenden belässt.
3. Wählen Sie Website-Regel hinzufügen. Geben Sie unter Website oder Muster einen Ursprung an: ein Schema, einen Hostnamen und optional einen Port. Beispielsweise ist https://example.com gültig; https://example.com/files ist es nicht. Geben Sie keinen Pfad, keine Abfrage und kein Fragment an. HTTP und HTTPS sind unterschiedliche Ursprünge. Geben Sie den Port an, wenn er vom Standardport des Schemas abweicht.
4. Legen Sie Website-Zugriff fest und prüfen Sie Downloads, Uploads und Debug/CDP. Wählen Sie nach Bedarf Zulassen oder Blockieren oder belassen Sie eine Einstellung auf Standardregel verwenden. Debug/CDP steuert den vollständigen Zugriff auf das Chrome DevTools Protocol zur Browser-Fehlersuche. Zulassen lässt die üblichen Richtlinien- und Genehmigungsprüfungen weiterlaufen.
5. Prüfen Sie Automatische Prüfung, Immer zulassen und Genehmigungsdauer für die Website. Genehmigungsdauer bietet Dieser Turn und Dieser Thread. Prüfen Sie auch Browserverlauf, Website-Genehmigungen speichern und Anfragen automatisch genehmigen unter Desktop-Browsersteuerung.
6. Wählen Sie Regel hinzufügen, prüfen Sie die Validierungsmeldungen und wählen Sie Änderungen speichern. Testen Sie eine zugelassene und eine blockierte Website auf einem unterstützten Client, der die Richtlinie erhält. Testen Sie Uploads, Downloads und andere eingeschränkte Aktionen separat.

Website-Regel hinzufügen

Die Zeile „Standard“ gilt, wenn eine Website-Regel eine Berechtigung auf „Standard“ belässt. Wenn sich Regeln überschneiden, hat „Blockieren“ für jede Berechtigung Vorrang.

Website oder Muster 

Website-ZugriffStandardregel verwenden

DownloadsStandardregel verwenden

UploadsStandardregel verwenden

Debug/CDPStandardregel verwenden

Automatische PrüfungStandardregel verwenden

Immer zulassenStandardregel verwenden

GenehmigungsdauerStandardregel verwenden

Wenn Sie die automatische Prüfung für Browseraktionen deaktivieren, werden diese Aktionen stattdessen dem Benutzer zur Genehmigung vorgelegt. Die Sicherheitsüberwachung des Modells wird dadurch nicht deaktiviert.

Wenn mehrere Ursprungsmuster übereinstimmen, hat für jede Einstellung der restriktivste Wert Vorrang. Eine lokale Konfiguration kann eine verwaltete Zugriffsverweigerung nicht lockern. Verwaltete Netzwerksperren und exklusive Zulassungslisten gelten auch für Browsertools. Informationen zu Ursprungsmustern finden Sie unter Felder der Browserrichtlinie , ebenso wie Informationen zum Genehmigungsverhalten.

Computer Use kann einen Browser auch als native App bedienen. Die Website- und Funktionsregeln von Browser Use gelten für diesen Zugriffsweg nicht. Prüfen Sie den Zugriff auf native Apps separat; siehe die Sicherheitsgrenzen des Browsers.

Zugriff auf native Apps konfigurieren

1. Wechseln Sie unter Anforderungen zu Desktop-App-Steuerung > App-Regeln.
2. Verwenden Sie die Aktionen der Zeile Standard, um den Zugriff für Apps ohne passende Regel zu konfigurieren. Um Computer Use auf genehmigte Apps zu beschränken, blockieren Sie den Zugriff standardmäßig und fügen Sie Zulassungsregeln für diese Apps hinzu.
3. Wählen Sie App-Regel hinzufügen. Wählen Sie im Dialog Regel bearbeiten unter App die Option macOS-Bundle-ID, Windows AUMID oder Ausführbare Windows-Datei. Geben Sie die genaue App-Kennung für eine Bundle-ID oder Application User Model ID (AUMID) ein. Geben Sie für Ausführbare Windows-Datei den Herausgebernamen und Produktnamen ein; der Binärdateiname ist optional. Verwenden Sie verifizierte Angaben zur App-Identität, keinen Anzeigenamen oder Dateipfad.
4. Legen Sie App-Zugriff für die Regel fest und wählen Sie dann Regel hinzufügen. Prüfen Sie App-Genehmigungen speichern unter Desktop-App-Steuerung, prüfen Sie die Validierungsmeldungen und wählen Sie Änderungen speichern. Wenn gespeicherte Genehmigungen deaktiviert sind, bleiben Genehmigungen für die aktuelle Sitzung möglich; das Zulassen gespeicherter Genehmigungen genehmigt keine App.
5. Testen Sie eine zugelassene und eine blockierte App auf jedem unterstützten Betriebssystem in Ihrer Bereitstellung. Stellen Sie sicher, dass die Betriebssystemberechtigungen weiterhin gelten und Benutzer erforderliche Genehmigungen weiterhin erteilen müssen.

Regel bearbeiten

Legen Sie den standardmäßigen App-Zugriff fest und überschreiben Sie ihn für passende Apps.

AppmacOS-Bundle-ID

App-Kennung 

App-ZugriffZugriff auswählen

Informationen zu den Windows-Identitätsanforderungen finden Sie unter Felder der Computer Use-Richtlinie. Informationen zu verwalteten Macs finden Sie unter Einschränkungen bei gesperrtem Computer.

Wirksame Richtlinie prüfen

Wenn eine zugelassene Website oder App weiterhin blockiert wird, prüfen Sie andere passende Regeln, Richtlinienzuweisungen und deren Priorität, Geräteanforderungen und die Benutzerkonfiguration. Eine Zulassungsregel in einer Quelle umgeht keine andere geltende Zugriffsverweigerung. Siehe Speicherorte und Vorrang von Anforderungen.

Wenn eine Einstellung keine Wirkung hat, prüfen Sie, ob der Client, das Betriebssystem und der Übermittlungsweg der Richtlinie sie unterstützen. Achten Sie besonders auf Work Cloud mit lokalem Computerzugriff: Einige Felder werden nur teilweise unterstützt oder erfordern eine Validierung. Siehe Work-Kompatibilität in der Konfigurationsreferenz.

Prüfen Sie die Workspace-Berechtigungen und Plugin-Steuerung separat, wenn ein Benutzer nicht auf die Funktion oder das erforderliche Plugin zugreifen kann.

TOML-Konfigurationsreferenz

Die folgenden Beispiele beschreiben dieselbe Richtlinienabsicht für requirements.toml. Verwenden Sie sie, wenn Sie Richtlinien über Dateien oder den TOML-Editor verwalten. Sie müssen keine lokale Datei bearbeiten, um die in Agent Security verfügbaren Steuerelemente zu verwenden.

Dieses Browserbeispiel verweigert den Zugriff standardmäßig, erlaubt https://example.com, blockiert dort Uploads und den vollständigen CDP-Zugriff und begrenzt die Genehmigung des Websitezugriffs auf den aktuellen Gesprächsschritt:

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

Um die automatische Überprüfung von Browseraktionen zu deaktivieren, setzen Sie browser_use.disable_auto_review = true oder legen Sie auto_review = "deny" in einer Ursprungsrichtlinie fest, um sie für diesen Ursprung einzuschränken.

Um Website-Tools für einen berechtigten Enterprise-Arbeitsbereich zu aktivieren, setzen Sie browser_use.allow_webmcp = true. Diese verwaltete Aktivierung gilt für den integrierten Browser der Desktop-App. Wenn Sie den Wert auf false setzen oder weglassen, bleiben die üblichen Prüfungen der Funktionsverfügbarkeit bestehen; false erzwingt keine Sperre. Benutzereinstellungen und Websiteberechtigungen gelten weiterhin.

Dieses Beispiel für native Apps erlaubt Calculator unter macOS, verweigert andere Apps standardmäßig und verhindert, dass App-Genehmigungen über Sitzungen hinweg bestehen bleiben:

[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.

Alle unterstützten Felder und Werte finden Sie in der Referenz zu requirements.toml. Wie Sie eine Funktion deaktivieren, statt einzelne Websites oder Apps einzuschränken, erfahren Sie unter Feature-Flags festlegen.

Weitere Desktop-Steuerelemente

Die folgenden Desktop-Steuerelemente betreffen die Funktionsverfügbarkeit, Locked Use, Appshots und die Gerätefernsteuerung. Verwenden Sie die jeweiligen Einstellungen für die Funktionsverfügbarkeit und Locked Use; konfigurieren Sie Appshots und die Gerätefernsteuerung über Als TOML bearbeiten. Einschränkungen der Netzwerkziele für den Datenverkehr der Desktop-App finden Sie unter Netzwerkziele der Desktop-App steuern.

Feature-Flags festlegen

Für Desktop-Funktionen, die in Agent Security verfügbar sind, öffnen Sie Global > Anforderungen > Verfügbarkeit von Desktop-Funktionen. Setzen Sie In-App-Browser, Browsernutzung, Externe Browsernutzung oder Computernutzung auf Deaktivierung erzwingen, um die jeweilige Funktion zu deaktivieren, und wählen Sie anschließend Änderungen speichern. Wählen Sie für Vollständiger CDP-Zugriff Aktivierung durch Benutzer blockieren, um zu verhindern, dass Benutzer ihn aktivieren. Das Zulassen einer Funktion setzt deren produkt-, plattform- oder rolloutbedingte Verfügbarkeit nicht außer Kraft.

Für andere unterstützte Feature-Flags verwenden Sie Als TOML bearbeiten und das globale Dokument requirements.toml oder eine unterstützte lokale Anforderungsquelle. Die folgenden Beispiele enthalten sowohl Festlegungen für Laufzeitfunktionen als auch für desktopspezifische Funktionen:

[features]
hooks = 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 kanonischen Funktionsschlüssel aus der Tabelle [features] in config.toml. Die lokale Laufzeitumgebung normalisiert erkannte Funktionen entsprechend diesen Festlegungen und weist widersprüchliche Schreibzugriffe auf config.toml oder auf Funktionseinstellungen in Profildateien zurück.

Ein verwaltetes unified_exec = false lässt die Befehlsausführung weiterhin zu, deaktiviert jedoch fortsetzbare Prozesse und das Tool write_stdin. Über die Benutzerkonfiguration lässt sich diese Funktion nicht deaktivieren.

• in_app_browser = false deaktiviert den integrierten Browserbereich.
• in_app_updates = false deaktiviert beim Neustart das eigene Aktualisierungsprogramm der ChatGPT-Desktop-App, sofern dies unterstützt wird. Dies wirkt sich weder auf die externe Paketbereitstellung aus noch verlängert es die Unterstützung älterer App-Versionen. Hinweise zur Einrichtung und Einführung finden Sie unter App-Updates verwalten.
• browser_use = false deaktiviert unterstützte Browser Use-Funktionen. Für External Browser Use und Computer Use mit nativen Apps gibt es separate Steuerelemente.
• browser_use_full_cdp_access = false deaktiviert den vollständigen CDP-Zugriff in der lokalen Laufzeitumgebung, einschließlich des Browser Developer-Modus, und verhindert, dass die ChatGPT-Desktop-App die entsprechende Einstellung aktiviert.
• browser_use_external = false deaktiviert die agentengesteuerte Browsernutzung über unterstützte Browsererweiterungen.
• computer_use = false deaktiviert Computer Use mit nativen Apps, einschließlich der Bedienung eines Browsers als native App, sowie Record & Replay und zugehörige Installations- oder Einrichtungsabläufe.

Das Deaktivieren von Browser Use allein blockiert nicht jeden Browserzugriffsweg. Computer Use mit nativen Apps kann weiterhin einen Browser bedienen, wenn diese Funktion und der App-Zugriff erlaubt sind; die Website- und Funktionsregeln von Browser Use gelten für diesen Zugriffsweg nicht. Um ihn zu blockieren, setzen Sie Computernutzung auf Deaktivierung erzwingen (computer_use = false) oder verweigern Sie die Browser-App in den App-Regeln, wenn andere native Apps verfügbar bleiben sollen. Prüfen Sie Externe Browsernutzung und In-App-Browser separat. Unter Browsersitzungen und bestehende Anmeldungen finden Sie die Steuerelemente, die für die jeweiligen Zugriffswege gelten.

Wenn Sie diese Schlüssel weglassen, erlaubt die Richtlinie die Funktionen vorbehaltlich der üblichen Client-, Plattform- und Rolloutverfügbarkeit.

Computernutzung im gesperrten Zustand einschränken

Um zu verhindern, dass Benutzer Locked Use auf einem verwalteten Mac aktivieren, öffnen Sie Global > Anforderungen > Desktop-App-Steuerung, setzen Sie Nutzung im gesperrten Zustand zulassen auf Deaktiviert und wählen Sie Änderungen speichern. Diese Einstellung schaltet Locked Use auf einem Mac nicht aus, wenn es dort bereits aktiviert ist.

Die entsprechende Anforderung für den TOML-Editor oder die geräteverwaltete Bereitstellung lautet:

[computer_use]
allow_locked_computer_use = false

Diese Anforderung entfernt die Steuerelemente zum Aktivieren von Locked Use. Sie schaltet Locked Use nicht aus, wenn es bereits aktiviert ist. Wenn Sie sie weglassen, gelten weiterhin die normale Produktverfügbarkeit und die lokale Einstellung des Benutzers.

Appshots deaktivieren

Mit Appshots können unterstützte Clients Anwendungs-Snapshots einbeziehen. Um sie für cloudverwaltete Benutzer zu deaktivieren, öffnen Sie Als TOML bearbeiten in Agent Security und setzen Sie das Feld allow_appshots auf oberster Ebene in der globalen requirements.toml. Für geräteverwaltete Bereitstellungen verwenden Sie die jeweils zutreffende lokale Anforderungsquelle:

allow_appshots = false

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

Gerätefernsteuerung deaktivieren

Um die Gerätefernsteuerung für cloudverwaltete Benutzer zu deaktivieren, verwenden Sie Als TOML bearbeiten in Agent Security und setzen Sie das Feld allow_remote_control auf oberster Ebene in der globalen requirements.toml. Sie können allow_remote_control auch in einer unterstützten lokalen Anforderungsquelle setzen:

allow_remote_control = false

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

Genehmigungen und Ausführungsberechtigungen festlegen

In diesem Abschnitt legen Sie das Genehmigungsverhalten, Berechtigungsgrenzen und anfängliche Standardwerte fest. Beginnen Sie mit Richtlinienleitplanken und Standardwerten. Die späteren Aufgaben erläutern TOML-Anforderungen für die Durchsetzung der Prüfinstanz, benutzerdefinierte Berechtigungsprofile, Dateisystembeschränkungen, Hostüberschreibungen und Befehlsregeln.

Administrativ 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 und welche Plugin-Marktplatzquellen sie verwenden können). Wenn beim Auflösen der Konfiguration (beispielsweise aus config.toml, Profildateien oder CLI-Konfigurationsüberschreibungen) ein Wert einer erzwungenen Regel widerspricht, greift der lokale Client auf einen kompatiblen Wert zurück und benachrichtigt den Benutzer. Wenn Sie eine Positivliste für mcp_servers konfigurieren, 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 ü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.

Leitplanken für Genehmigungen, Sandbox und Websuche festlegen

Verwenden Sie Anforderungen > Richtlinienleitplanken, um die unterstützten Auswahlmöglichkeiten im Client einzuschränken. Diese Steuerelemente begrenzen die Konfiguration; sie legen keinen Anfangswert fest. Legen Sie den Anfangswert separat unter Standardwerte fest.

1. Öffnen Sie unter Global die Option Genehmigungsrichtlinien und wählen Sie die zulässigen Genehmigungsarten aus. Beispielsweise erlaubt Bei Bedarf fragen dem Agenten, eine Genehmigung für Aktionen wie eine Sandbox-Eskalation anzufordern. Nie fragen verhindert Genehmigungsanfragen; diese Option erlaubt keine uneingeschränkte Ausführung.
2. Öffnen Sie Sandbox-Modi, um die Auswahl älterer Sandbox-Modi einzuschränken. Schreibgeschützt schränkt Schreibzugriffe ein, Schreibzugriff im Arbeitsbereich erlaubt Schreibzugriffe innerhalb des Arbeitsbereichs und der konfigurierten beschreibbaren Stammverzeichnisse, und Vollzugriff hebt die Dateisystem-Sandbox auf. Verwenden Sie Anforderungen an Berechtigungsprofile für Bereitstellungen, die Berechtigungsprofile anstelle von sandbox_mode verwenden.
3. Öffnen Sie unter Global die Option Websuchmodi, um die Websuche einzuschränken. Wählen Sie Zwischengespeichert, um die Suche im Cache ohne Live-Suche zu erlauben, oder Deaktiviert, um die Websuche auszuschalten. Einschränkungen der Websuche sind von Netzwerkregeln für Befehle unabhängig.
4. Prüfen Sie die zulässigen Optionen und die entsprechenden Standardwerte und wählen Sie dann Änderungen speichern.

Wenn Sie eine Anforderung nicht festlegen, gilt unter dieser Richtlinie keine entsprechende Einschränkung. Andere anwendbare Richtlinien gelten weiterhin. Die Option Bei nicht vertrauenswürdigen Befehlen fragen entspricht untrusted in der Zulassungsliste der Anforderungen; sie stellt die eingestellte explizite Einstellung approval_policy = "untrusted" nicht wieder her. Befolgen Sie in diesem Fall die nachstehenden Migrationshinweise.

Um die Websuche einzuschränken, verwenden Sie Global > Anforderungen > Richtlinienleitplanken > Websuchmodi. Die entsprechende TOML-Konfiguration lautet:

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 danger-full-access-Sitzungen.

Konfigurationsstandardwerte festlegen

Standardwerte geben Mitgliedern eine Ausgangskonfiguration vor. Sie erzwingen keine Einschränkung und gewähren keinen Zugriff auf eine Funktion des Arbeitsbereichs.

1. Öffnen Sie die Karte Standardwerte der Richtlinie. Belassen Sie agentenweite Standardwerte unter Global; verwenden Sie für unterstützte Ausführungsstandardwerte eine verfügbare Umgebungsregisterkarte.
2. Wählen Sie unter Befehlsausführung die anfängliche Genehmigungsrichtlinie und Genehmigungsprüfinstanz sowie den zutreffenden Sandbox-Modus oder die Standardberechtigungen aus. Die Prüfinstanz bestimmt, wer Genehmigungsanfragen standardmäßig prüft; die Genehmigungsrichtlinie bestimmt, wann Anfragen gestellt werden können.
3. Wählen Sie unter Websuche den anfänglichen Modus für Websuche und den Websuchkontext aus. Prüfen Sie unter Apps und Tools die Optionen Apps/Konnektoren, Open-World-Tools und Destruktive Tools für unterstützte App-Tools.
4. Stellen Sie sicher, dass die Standardwerte Ihre Anforderungen erfüllen, und wählen Sie dann Änderungen speichern.

Verwenden Sie Als TOML bearbeiten für unterstützte Standardwerte ohne visuelle Bedienelemente, etwa die Konfiguration des Plugin-Marktplatzes. Diese Cloud-Standardwerte verwenden die normale Konfigurationsrangfolge . Sie unterscheiden sich von der älteren Rangfolge für managed_config.toml, bei der verwaltete Standardwerte beim Start Vorrang vor der lokalen Konfiguration haben.

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 bewahrt untrusted das strengere Genehmigungsverhalten, das aus trust_level = "untrusted" abgeleitet wird; dadurch wird approval_policy = "untrusted" jedoch nicht zu einer unterstützten expliziten Einstellung.

Die eingestellte Genehmigungsrichtlinie untrusted migrieren

Codex und ChatGPT Work unterstützen approval_policy = "untrusted" nicht mehr. Entfernen Sie diese Einstellung aus verwalteten Standardwerten, der älteren Datei managed_config.toml und jeder Benutzer-, Projekt-, Profil- oder Startkonfiguration, in der sie festgelegt ist.

Wählen Sie für die interaktive, schreibgeschützte Nutzung approval_policy = "on-request" mit einer schreibgeschützten Sandbox oder einem Berechtigungsprofil, das Ihre verwalteten Anforderungen zulassen. Befehle, die diese Sandbox erlaubt, können ohne Genehmigung ausgeführt werden.

Um strengere Befehlsfreigaben beizubehalten, lassen Sie eine explizite Angabe von approval_policy weg und setzen Sie trust_level = "untrusted" im Projekteintrag der benutzerspezifischen Datei ~/.codex/config.toml. Behalten Sie außerdem untrusted in allowed_approval_policies bei. Dadurch wird auch die projektlokale Konfiguration deaktiviert. Eine explizite Einstellung von on-request überschreibt diese Richtlinie. Unter Migration von der eingestellten Genehmigungsrichtlinie untrusted finden Sie Beispiele und Hinweise zu Sicherheitsabwägungen.

Richtlinie für die automatische Prüfung konfigurieren

Um die automatische Prüfung als Standard festzulegen, verwenden Sie Global > Standardwerte > Befehlsausführung > Genehmigungsprüfinstanz. Ein Standardwert erlaubt Benutzern, eine andere zulässige Prüfinstanz auszuwählen. Um die automatische Prüfung vorzuschreiben oder die Prüfanweisungen Ihrer Organisation bereitzustellen, verwenden Sie Als TOML bearbeiten und bearbeiten Sie stattdessen die globale requirements.toml. Diese Anforderungen sind von den Steuerelementen des Browsers für die automatische Prüfung unabhängig.

Verwenden Sie allowed_approvals_reviewers, um die automatische Prüfung vorzuschreiben oder zu erlauben. Setzen Sie den Wert auf ["auto_review"], um die automatische Prüfung vorzuschreiben, oder nehmen Sie "user" auf, wenn Benutzer die manuelle Genehmigung wählen können.

Setzen Sie guardian_policy_config, um den mandantenspezifischen Abschnitt der Richtlinie für die automatische Prüfung zu ersetzen. Die lokale Laufzeit verwendet weiterhin die integrierte Vorlage für die Prüfinstanz und die Ausgabevorgaben. 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.
"""

Verfügbare Berechtigungsprofile steuern

Verwenden Sie Standardwerte > Befehlsausführung > Standardberechtigungen, um das integrierte Profil auszuwählen, mit dem Benutzer beginnen. Um festzulegen, welche Profile Benutzer auswählen dürfen, oder um benutzerdefinierte Profile zu definieren, verwenden Sie Als TOML bearbeiten und konfigurieren Sie requirements.toml für den zutreffenden globalen Geltungsbereich oder den einer unterstützten Ausführungsumgebung. Die Auswahl eines Standardwerts allein schränkt die verfügbaren Profile nicht ein.

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.

Anforderungen zur Verweigerung von Lesezugriffen durchsetzen

Verwenden Sie Als TOML bearbeiten, um Dateisystemeinschränkungen zur zutreffenden globalen requirements.toml oder der entsprechenden Datei einer unterstützten Ausführungsumgebung hinzuzufügen. Diese Einschränkungen blockieren Lesezugriffe auf sensible Pfade; ein schreibgeschützter Standardwert allein verbirgt keine Dateien.

Administratoren können Lesezugriffe auf exakte Pfade oder Glob-Muster mit [permissions.filesystem] 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 Verweigerung von Lesezugriffen vorliegen, lehnt die lokale Laufzeit Vollzugriffsberechtigungen ab und führt lokale Aktionen weiterhin in einer schreibgeschützten Sandbox oder einer Arbeitsbereichs-Sandbox aus, damit sie diese Anforderungen durchsetzen kann. Unter nativem Windows gilt verwaltetes deny_read für direkte Dateitools; Lesezugriffe durch Shell-Unterprozesse verwenden diese Sandbox-Regel nicht.

Sandbox-Anforderungen nach Host überschreiben

Verwenden Sie Als TOML bearbeiten unter Agent Security, um hostspezifische Anforderungen zu erstellen. Umgebungssteuerelemente wählen eine Ausführungsumgebung aus; Hostmuster wählen passende Rechner innerhalb der unterstützten Laufzeit aus.

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 soweit möglich 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.

Befehlsregeln aus Anforderungen durchsetzen

Verwenden Sie Als TOML bearbeiten unter Agent Security, um Befehlsregeln und Einschränkungen für MCP server zur globalen requirements.toml hinzuzufügen. Befehlsregeln legen Genehmigungs- oder Ablehnungsentscheidungen für passende Befehle fest; MCP-Einschränkungen begrenzen, welche Serveridentitäten der Client aktivieren kann. Das Steuerelement Genehmigungsrichtlinien erstellt keines dieser beiden Regelwerke.

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

Anders als bei .rules müssen Regeln in Anforderungen decision angeben, und diese Entscheidung 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ügen Sie eine mcp_servers-Zulassungsliste hinzu. Gleichen Sie bei STDIO-Servern command ab; bei Streamable-HTTP-Servern gleichen Sie 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 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, 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 sowie Anzahl und Reihenfolge der Argumente müssen übereinstimmen. Argument- und URL-Regeln unterstützen den Abgleich mit exact, prefix und regex über den gesamten Wert. Strukturierte Befehlsregeln prüfen weiterhin weder cwd noch env oder env_vars. Mit Plugins 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.

Netzwerkzugriff konfigurieren

Für den Netzwerkzugriff von Befehlen und Desktop-Apps gelten unterschiedliche Steuerelemente. Beginnen Sie mit Steuerelemente zur Netzwerknutzung für unterstützten Befehlsdatenverkehr, prüfen Sie die Umgebungs- und Laufzeitbeschränkungen und verwenden Sie bei Bedarf anschließend die separaten Anforderungen für Desktop-Apps. Regeln für Browser-Websites finden Sie weiterhin unter Browser und Computer Use steuern.

Anforderungen für den Netzwerkzugriff konfigurieren

Verwenden Sie Anforderungen > Steuerelemente zur Netzwerknutzung, um den unterstützten Netzwerkzugriff von Befehlen unter Agent Security zu verwalten. Konfigurieren Sie eine gemeinsame Basis unter Global oder verwenden Sie eine verfügbare Registerkarte Lokale Umgebungen oder Codex Cloud-Umgebungen für umgebungsspezifische Ausführungseinstellungen.

1. Setzen Sie Verwalteter Netzwerkzugriff auf Ein, um Domainregeln auf den verwalteten Netzwerkverkehr von Befehlen anzuwenden. Das Hinzufügen von Domainregeln allein aktiviert den verwalteten Proxy nicht.
2. Wählen Sie unter Netzwerkregeln die Option Netzwerkregel hinzufügen aus. Geben Sie eine Domain wie api.openai.com oder **.example.com ohne URL-Schema oder Pfad ein. Wählen Sie unter Zugriff die Option Zulassen oder Verweigern und anschließend Regel speichern, um den Entwurf zu aktualisieren. Wiederholen Sie dies für weitere Ziele.
3. Setzen Sie Nur von Administratoren hinzugefügte Domains zulassen auf Ein, wenn Benutzereinstellungen und domainspezifische Genehmigungen die verwaltete Zulassungsliste nicht erweitern dürfen. Fügen Sie die erforderlichen Zulassungseinträge hinzu; eine reine Sperrliste lässt keine anderen Ziele zu.
4. Überprüfen Sie Lokalen Netzwerkzugriff zulassen für Workflows, die lokale Listener oder private Ziele benötigen. Direkte lokale Verbindungen können die Domainregeln des Proxys umgehen. Prüfen Sie die unten aufgeführten Konnektivitätsbeschränkungen von Codex Cloud, bevor Sie diese Einstellung ändern.
5. Überprüfen Sie geerbte Regeln und Validierungsmeldungen und wählen Sie dann Änderungen speichern aus. Testen Sie in jeder betroffenen Ausführungsumgebung eine Anfrage, die erfolgreich sein sollte, und eine, die blockiert werden sollte.

Wenn Sie Verwalteter Netzwerkzugriff auf Aus setzen, werden die in diesem Geltungsbereich erstellten Netzwerkregeln entfernt und ein expliziter Aus-Wert gespeichert; der Internetzugriff wird dadurch nicht deaktiviert. Nicht festgelegt entfernt die in diesem Geltungsbereich erstellten Netzwerkeinstellungen, sodass die geltenden Richtlinien- oder Laufzeitstandardwerte greifen können. Durch das Entfernen von Umgebungseinstellungen können geerbte globale Regeln wieder wirksam werden. Verwenden Sie Als TOML bearbeiten für erweiterte Netzwerkfelder oder vorhandene ältere Domainlisten, die der visuelle Editor nicht darstellen kann.

Verwenden Sie [experimental_network] in requirements.toml, wenn Administratoren Anforderungen an den Netzwerkzugriff zentral definieren sollen. Diese Anforderungen sind vom benutzerseitigen Schalter features.network_proxy getrennt: Sie können die Sandbox-Netzwerkanbindung ohne dieses Feature-Flag konfigurieren, gewähren jedoch keinen Netzwerkzugriff für Befehle, wenn die aktive Sandbox die Netzwerkanbindung deaktiviert lässt. Setzen Sie experimental_network.enabled = true, um den verwalteten Proxy zu aktivieren; Domänenregeln 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"

Verwenden Sie experimental_network.managed_allowed_domains_only = true nur, wenn Sie auch administratoreigene "allow"-Einträge in [experimental_network.domains] definieren und möchten, dass diese Regeln exklusiv gelten. Ist die Einstellung true aktiv, ohne dass verwaltete Zulassungsregeln vorhanden sind, bleiben von Benutzern hinzugefügte Domänen-Zulassungsregeln nicht wirksam. Kombinieren Sie die kanonische domains-Zuordnung nicht mit den veralteten Listen allowed_domains oder denied_domains.

*.example.com stimmt nur mit Subdomänen überein. **.example.com stimmt mit der Apex-Domäne und ihren Subdomänen überein. Eine passende Sperrregel hat Vorrang vor einer Zulassungsregel.

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.

Der Proxy leitet lokale Befehle weiter, die innerhalb der Sandbox ausgeführt werden. Browser-Tools prüfen außerdem verwaltete Netzwerksperren und exklusive Zulassungslisten, bevor sie auf einen Origin zugreifen. Dies ist eine separate Richtlinienprüfung; der Browser-Datenverkehr wird dabei nicht durch den Befehlsproxy geleitet. Dieser filtert weder Websuche, Apps und Konnektoren noch MCP server, Datenverkehr nativer Apps, Codex-Dienstanfragen oder anderen funktionsspezifischen Datenverkehr. Verwenden Sie die jeweiligen Steuerelemente für jeden Bereich:

• Verwenden Sie allowed_web_search_modes, um die Websuche einzuschränken.
• Verwenden Sie features.apps = false, um App- und Konnektorintegrationen zu deaktivieren, und features.plugins = false, um Plugins zu deaktivieren, sofern dies unterstützt wird.
• Verwenden Sie die verwaltete Zulassungsliste mcp_servers, um MCP server einzuschränken.
• Verwenden Sie Funktionsanforderungen wie browser_use, in_app_browser und computer_use, um Funktionen zur Browser- und Computernutzung einzuschränken.
• Konfigurieren Sie für unterstützte verwaltete Codex Cloud-Befehle die Agent Security-Anforderungen und die Interneteinstellungen der Cloud-Umgebung getrennt.

Eine Domain-Positivliste für Befehle ersetzt diese funktionsspezifischen Steuerelemente nicht.

Auf unterstützten verwalteten Ausführungspfaden von Codex Cloud beschränken Agent Security-Anforderungen den Netzwerkzugriff von Befehlen. Die Interneteinstellungen der Codex Cloud-Umgebung gelten separat. Eine in Agent Security zugelassene Domain setzt keine Einschränkung in den Interneteinstellungen der Cloud-Umgebung außer Kraft. Diese Netzwerksteuerungen für Befehle deaktivieren für sich genommen weder die gehostete Websuche noch Apps oder MCP. ChatGPT Work Cloud verfügt über separate Funktionsberechtigungen und übernimmt diese Agent Security-Anforderungen nicht.

Eine verwaltete Zulassungsliste für Befehle gilt für Befehle, die den verwalteten Proxy verwenden. Wenn die Richtlinie eine vollständige Sandbox-Eskalation zulässt und diese genehmigt wird, kann die Ausführung den Befehlsproxy umgehen. Eine eng begrenzte Netzwerkfreigabe unterscheidet sich von einer vollständigen Sandbox-Eskalation. Konfigurieren Sie verbindliche Genehmigungs- und Sandbox-Anforderungen für die vorgesehene Grenze und testen Sie sowohl gewöhnliche als auch mit erweiterten Berechtigungen ausgeführte Befehle.

Keine effektiv zugelassenen Ziele: Wenn Verwalteter Netzwerkzugriff und Nur von Administratoren hinzugefügte Domains zulassen eingeschaltet sind, benötigen gewöhnliche verwaltete Befehle effektiv zugelassene Ziele. Wenn keine Zulassungseinträge konfiguriert oder geerbt werden, haben diese Befehle keine zugelassenen Ziele. Eine reine Sperrrichtlinie lässt den Rest des Internets nicht implizit zu. Fügen Sie die erforderlichen Zulassungseinträge hinzu und prüfen Sie vor dem Speichern die geerbten Regeln. Diese Einschränkung gilt für den verwalteten Befehlsproxy, nicht für jedes Tool oder jede genehmigte vollständige Sandbox-Eskalation.

Lokale/private Konnektivität von Codex Cloud: Der explizite Wert Off für die lokale/private Konnektivität kann verhindern, dass Codex Cloud seinen vorgeschalteten Proxy erreicht, selbst wenn die Zieldomain erlaubt ist. Prüfen Sie den endgültigen Wert von allow_local_binding und ermitteln Sie, aus welcher Richtlinie oder Einstellung er stammt. Auf dem unterstützten Cloud-Proxy-Pfad ist der Standardwert nur dann true, wenn weder eine anwendbare Anforderung noch ein ausgewähltes Netzwerkprofil oder eine Einstellung der Proxy-Funktion einen Wert vorgibt. Ein geerbter Wert false gilt ebenfalls als explizite Einstellung. Legen Sie, sofern unterstützt, eine Cloud-Überschreibung mit höherer Priorität fest, um diesen Wert für Codex Cloud zu ändern, ohne den von Local verwendeten Global-Wert zu ändern. Dadurch werden keine Allow-Einträge für Domains hinzugefügt. Prüfen Sie die Unterstützung durch den Executor, bevor Sie sich auf die Überschreibung verlassen. Wenden Sie diesen Cloud-Standardwert nicht auf Local an.

Wenn die Umgebungsanforderungen leer sind, gelten die globalen Anforderungen. Verwalteter Netzwerkzugriff mit dem Wert Aus ist unabhängig von der Einstellung für den Internetzugriff der Cloud-Umgebung. Unter Ausführungssteuerung in Agent Security finden Sie Einzelheiten zum Ausführungsumfang.

Rangfolge von Netzwerkrichtlinien und Laufzeitbeschränkungen

Innerhalb einer Richtlinie gilt folgende Reihenfolge von der höchsten zur niedrigsten Priorität: betriebssystemspezifische Umgebungsüberschreibung → betriebssystemübergreifende Umgebungsüberschreibung → Global. Eine Richtlinie mit höherer Priorität hat weiterhin Vorrang vor einer Richtlinie mit niedrigerer Priorität, selbst wenn letztere spezifischer ist. Für einige Anforderungen gelten feldspezifische Zusammenführungsregeln. Die Laufzeitumgebung setzt anschließend die aufgelösten Anforderungen durch. Betrachten Sie die folgenden feldspezifischen Netzwerkfälle getrennt von der Richtlinienpriorität.

Diese Beispiele vergleichen Umgebungseinstellungen und globale Einstellungen innerhalb derselben Richtlinie. Dabei ist der verwaltete Netzwerkzugriff bereits konfiguriert und keine Richtlinie mit höherer Priorität ändert die Werte. Sie beschreiben das feldspezifische Zusammenführungs- und Laufzeitverhalten.

Unterschiedlichen Domainzugriff je nach Umgebung festlegen

Für dieselbe Domainregel innerhalb einer Richtlinie kann eine administrative Umgebungsüberschreibung eine unter Global gesperrte Domain zulassen oder eine unter Global zugelassene Domain sperren. Ohne Umgebungsüberschreibung wird die globale Regel geerbt. Andere wirksame Sperrregeln oder Zugriffskontrollen können eine Anfrage weiterhin blockieren.

So werden Domainregeln kombiniert

Diese Ergebnisse vergleichen denselben Domainschlüssel innerhalb einer Richtlinie, ohne dass eine Richtlinie mit höherer Priorität das Ergebnis ändert. Ein Wert mit höherer Priorität ersetzt den Wert desselben Schlüssels. Andere geerbte Schlüssel bleiben erhalten. Eine Zulassungsregel umgeht keine andere zutreffende Sperrregel, etwa eine geerbte Platzhalterregel. Eine leere Umgebungszuordnung entfernt keine geerbten Regeln.

Beispiel: Sperren Sie packages.example.com unter Global und lassen Sie die Domain in Development zu. Development kann sie unter den oben genannten Bedingungen zulassen. Production erbt die globale Sperrregel, sofern sie nicht überschrieben wird.

Vergewissern Sie sich, dass der bereitgestellte Executor diese Zusammenführungsregeln unterstützt. Die Unterstützung durch reguläre verwaltete Executoren muss noch validiert werden.

Orchestrator-Beschränkungen. Verwaltete HTTP/SOCKS-Listener-Ports und Proxy-Listener außerhalb der Loopback-Schnittstelle werden von der Cloud-Laufzeitumgebung nicht unterstützt; die Unterstützung für Socket-Regeln hängt vom Ausführungspfad ab. Eine Einstellung für die lokale Ausführung in der folgenden Tabelle ist keine unterstützte Orchestrator-Konfiguration.

Weitere Netzwerkbeschränkungen der Laufzeitumgebung

Alle folgenden Feldnamen befinden sich unter experimental_network in requirements.toml. Die Pfeile zeigen jeweils einen globalen Wert, gefolgt von einem Umgebungswert innerhalb derselben Richtlinie. Diese Fälle für die lokale Ausführung belegen keine Orchestrator-Unterstützung für dieselben Einstellungen.

Proxy-Aktivierung, Exklusivität, das Verhalten des vorgeschalteten Proxys und Unix-Socket-Regeln verhalten sich je nach Executor unterschiedlich. Übertragen Sie die Zusammenführung von Domainschlüsseln nicht pauschal auf diese Einstellungen. Überprüfen Sie die wirksamen Werte und testen Sie die bereitgestellte Laufzeitumgebung. Informationen zur lokalen/privaten Konnektivität von Codex Cloud finden Sie unter Anforderungen an den Netzwerkzugriff konfigurieren.

Verhalten vor dem Rollout überprüfen

Testen Sie die tatsächlichen Ziele, lokalen Listener, das Proxy-Verhalten und die Socket-Pfade, die Ihre Workflows verwenden. Prüfen Sie in jeder betroffenen Umgebung eine Aktion, die erfolgreich sein sollte, und eine, die blockiert werden sollte. Vergewissern Sie sich, dass die bereitgestellte Laufzeitversion jede verwendete Einstellung unterstützt.

Netzwerkziele der Desktop-App steuern

Verwenden Sie Als TOML bearbeiten in Agent Security, um diese desktopspezifischen Anforderungen unter Global zu konfigurieren. Die Benutzeroberfläche Steuerelemente zur Netzwerknutzung verwaltet den Netzwerkzugriff von Befehlen, für den eine separate Richtlinie gilt.

Verwenden Sie [application.network] in requirements.toml, um die Netzwerkziele der Desktop-App einzuschränken. Mit enabled = true müssen externe Anfragen HTTPS oder WSS verwenden und exakt einer Domain mit dem Wert "allow" in [application.network.domains] entsprechen. Subdomains sind nicht implizit erlaubt. Eine leere Domainzuordnung lässt keine externen Ziele zu. Die unterstützten Schlüssel finden Sie in der Referenz zur Konfiguration.

Diese Richtlinie ist unabhängig vom Netzwerkzugriff für Befehle und von Browser-Origin-Regeln. Sie beschränkt keine Netzwerkziele nativer Module oder gestarteter Prozesse und regelt nicht die Ausführung in Work Cloud.

Plugins und verwaltete Hooks konfigurieren

Verwenden Sie für diese Aufgaben Als TOML bearbeiten in Agent Security oder eine unterstützte lokale Konfigurationsquelle. Marketplace-Standardwerte, erzwungene Plugin-Einschränkungen und verwaltete Hooks erfüllen unterschiedliche Zwecke; wählen Sie die Aufgabe aus, die der benötigten Richtlinie entspricht.

Plugin-Marketplaces und Standardwerte konfigurieren

Verwenden Sie Agent Security > Als TOML bearbeiten, um lokale oder Git-Marketplaces und Plugin-Standardwerte im globalen config.toml-Dokument festzulegen. Sie können diese Einstellungen auch über die systemweite config.toml verteilen. Sie stellen eine anfängliche Marketplace- und Plugin-Konfiguration bereit, keine erzwungene Richtlinie. Um einzuschränken, welche Quellen Mitglieder verwenden können, konfigurieren Sie Anforderungen an Marketplace-Quellen.

Konfigurationsschlüssel finden Sie in der Konfigurationsreferenz, Informationen zu Überschreibungen unter Rangfolge der Konfiguration und zur Konfiguration auf Projektebene unter Plugin-Einstellungen für Repositorys. GitHub-Import und -Synchronisierung im Workspace sind davon unabhängig.

Plugin-Verfügbarkeit steuern

Verwenden Sie Als TOML bearbeiten in Agent Security, um erzwungene Plugin-Funktionseinstellungen in der globalen requirements.toml festzulegen, oder verteilen Sie sie über lokale Anforderungen für Clients auf verwalteten Geräten. Standardwerte > Apps und Tools > Apps/Konnektoren legt Standardwerte für App-Tools fest; dies ist nicht der erzwungene Schalter features.plugins. Informationen zu Plugin-Berechtigungen im Workspace finden Sie unter Apps und Konnektoren.

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

Verwenden Sie Als TOML bearbeiten, um Anforderungen an Marketplace-Quellen in der globalen requirements.toml zu konfigurieren, oder stellen Sie diese über lokale Anforderungen bereit. Diese Regeln beschränken, welche lokalen oder Git-Quellen Benutzer hinzufügen und verwenden können. Sie sind unabhängig von den Marketplace-Standardeinstellungen.

Um die Quellen für Plugin-Marktplätze einzuschränken, setzen Sie restrict_to_allowed_sources = true 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 blockieren das Hinzufügen von Marktplätzen, die Installation von Plugins und Aktualisierungsvorgänge für konfigurierte Git-Marktplätze, deren Quellen keiner Regel entsprechen. Sie filtern außerdem konfigurierte Marktplätze und deren Plugins zur Laufzeit.

Auch die von OpenAI kuratierten Git-Marktplätze, einschließlich des Katalogs für API key, müssen der Quellenzulassungsliste entsprechen. Um sie zuzulassen, fügen Sie die folgende Git-Quelle ohne eine 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, lassen Sie diese Quelle weg und stellen Sie sicher, dass keine weiter gefasste Hostregel sie zulässt. Mitgelieferte Plugins und remote installierte Arbeitsbereichs-Plugins werden von dieser Richtlinie für kuratierte Git-Quellen nicht erfasst.

Diese Quellenbeschränkungen gelten nur, wenn ein lokaler Client Vorgänge für Plugin-Marktplätze unterstützt: ChatGPT und Codex in der Desktop-App sowie Codex CLI. Sie steuern weder die Plugin-Nutzung in ChatGPT im Web oder auf Mobilgeräten noch fügen sie der IDE-Erweiterung Plugins hinzu.

Verwaltete Hooks über Anforderungen erzwingen

Verwaltete Hooks führen bei unterstützten Aufgaben- oder Tool-Ereignissen Aktionen aus, die Administratoren definiert haben. Verwenden Sie Als TOML bearbeiten in Agent Security, um sie in der globalen requirements.toml zu konfigurieren; die Einstellungsoberfläche enthält keinen eigenen Hook-Editor. Die folgenden Ausführungspfade bestimmen, welche Hook-Typen ausgeführt werden können.

Wenn verwaltete Richtlinien und Remote-Hooks aktiviert sind, verwenden Work Cloud mit lokalem Zugriff und dots administrativ verwaltete Remote-MCP-Hooks auf dem Cloud-Orchestrator. Konfigurieren Sie mcp_tool-Handler in der globalen requirements.toml. Work Cloud ohne lokalen Zugriff und persönliche Konten verwenden diese Unternehmens-Hooks nicht. Befehls-/Shell-, Prompt- und Agent-Handler; Hooks aus lokaler Konfiguration, Plugins oder lokalen Verzeichnissen; umgebungsbezogene Hooks; sowie SessionEnd-MCP-Hooks werden bei der Cloud-Orchestrierung nicht unterstützt, selbst wenn Tools lokal ausgeführt werden. Wenn sowohl Orchestrierung als auch Ausführung lokal erfolgen, funktionieren bestehende unterstützte Hooks weiterhin in rein lokalen Work- und Codex-Threads. Administratoren können für diese Workflows weiterhin unterstützte verwaltete Hooks in Agent Security konfigurieren.

Bevor Sie sich auf diese Hooks verlassen, testen Sie die Callback-Konnektivität, die erforderlichen Ereignisse und das Verhalten bei Fehlern. Eine explizite, unterstützte Ablehnung kann eine Aktion blockieren. Ein Fehler im PreToolUse-Callback, eine Zeitüberschreitung oder eine fehlerhaft formatierte Antwort kann jedoch zum Fehlschlagen des Hooks führen, ohne das Tool zu blockieren. MCP-Hooks stellen kein vollständiges Audit-Protokoll der Compliance API bereit. Die folgenden Skript- und Verzeichnisbeispiele gelten weiterhin für Codex.

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

Um verwaltete Hooks auch für Benutzer zu erzwingen, die Hooks lokal deaktiviert haben, legen Sie [features].hooks = true zusammen mit [hooks] verbindlich fest. Um Benutzer-, Projekt-, Sitzungs- und Plugin-Hooks zu überspringen und verwaltete Hooks weiterhin zuzulassen, setzen Sie 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 erzwingt die Hook-Konfiguration aus requirements.toml, verteilt jedoch nicht die Skripte in managed_dir.
• Stellen Sie diese Skripte über Ihre 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 aber weiterhin Hooks aus requirements.toml und anderen verwalteten Konfigurationsebenen.

Geltungsbereich und Rangfolge von Richtlinien verstehen

Prüfen Sie anhand dieses Abschnitts, wo eine Richtlinie gilt, wie Anforderungen kombiniert werden, wie Clients cloudverwaltete Einstellungen erhalten und wie Sie das Ergebnis überprüfen können.

Für Work mit lokalem Zugriff und dots steuern unterstützte globale Richtlinien den gemeinsam genutzten Cloud-Orchestrator, wenn verwaltete Richtlinien aktiviert sind; die geltenden Anforderungen für die lokale Ausführung steuern den verbundenen Computer. Work-Cloud-Container behalten die bestehenden Work Cloud-Richtlinien bei, und unterstützte Gerätesteuerungen gelten weiterhin für die lokale Ausführung. Codex behält sein bestehendes Konfigurationsverhalten bei. Die verwaltete Konfiguration gewährt weder eine Workspace-Lizenz noch Zugriff auf Funktionen. Verwenden Sie für diese Steuerungsmöglichkeiten Rollen und Workspace-Berechtigungen.

Agent Security und lokaler Computerzugriff mit Work Cloud

Verwenden Sie Agent Security in der Admin Console, um Richtlinien und Konfiguration zu verwalten. Es ersetzt Policies & Configuration. Agent Security ist in der Admin Console unabhängig vom lokalen Computerzugriff mit Work Cloud verfügbar. Bestehende Richtlinien, Zuweisungen und deren Reihenfolge bleiben erhalten. Überprüfen Sie Ihre bestehenden Richtlinien in Agent Security. Der lokale Computerzugriff mit Work Cloud muss separat aktiviert werden. Hinweise zur Migration finden Sie unter Agent Security.

Bevor Sie die Richtlinienautomatisierung auf Agent Security umstellen:

1. Ermitteln Sie betroffene Integrationen. Erfassen Sie Terraform-Konfigurationen und Skripte, die Richtlinien aktualisieren, und dokumentieren Sie, welche Richtlinien sie verwalten.

2. Verwenden Sie die Richtlinien-API, um globale Einstellungen zu verwalten. Verwenden Sie die Agent Security-Oberfläche, um lokale oder Codex Cloud-Einstellungen zu verwalten. Bestehende API-Workflows für globale Einstellungen bleiben nach der Migration verfügbar. Testen Sie Ihre Skripte und Terraform-Integrationen und bestätigen Sie, dass Richtlinienzuweisungen und deren Reihenfolge unverändert sind.

3. Nehmen Sie alle erforderlichen Änderungen vor und testen Sie die Automatisierung. Überprüfen Sie, ob eine beabsichtigte Aktualisierung die richtige Agent Security-Richtlinie erreicht und ob die daraus resultierenden Steuerungsvorgaben durchgesetzt werden.

Die Richtlinienmigration gewährt keinen lokalen Computerzugriff für Work oder dots. Es wird empfohlen, Richtlinien vor dem Rollout zu überprüfen oder zu erstellen. Der Bestätigungsablauf setzt jedoch keine Richtlinienerstellung voraus, um den Zugriff zu aktivieren. Bevor Sie Lokalen Computerzugriff erlauben aktivieren, überprüfen Sie die migrierte Basiskonfiguration oder erstellen Sie eine Cloud-Basiskonfiguration, falls Ihre Richtlinien derzeit ausschließlich über MDM bereitgestellt werden. Wenn enforce_residency in einer Cloud-Richtlinie aktiviert ist, ist Lokalen Computerzugriff erlauben sowohl für Work als auch für dots deaktiviert. Diese Schutzmaßnahme konfiguriert weder die Datenresidenz des Workspace noch deaktiviert sie allein Work Cloud oder dots.

Umgebungsüberschreibungen passen unterstützte Einstellungen innerhalb einer Richtlinie an. Innerhalb einer bestimmten Richtlinie gilt folgende Rangfolge von der höchsten zur niedrigsten Priorität: betriebssystemspezifische Umgebungsüberschreibung → Umgebungsüberschreibung für alle Betriebssysteme → Global. Eine Richtlinie mit höherer Priorität hat weiterhin Vorrang vor einer Richtlinie mit niedrigerer Priorität, selbst wenn die Richtlinie mit niedrigerer Priorität spezifischer ist. Für einige Anforderungen gelten feldspezifische Zusammenführungsregeln. Prüfen Sie, welche Editoren und Felder für Überschreibungen in Ihrem Workspace verfügbar sind.

Wenn verwaltete Richtlinien und Remote-Hooks aktiviert sind, verwenden Work Cloud mit lokalem Zugriff und dots administrativ verwaltete Remote-MCP-Hooks auf dem Cloud-Orchestrator. Konfigurieren Sie mcp_tool-Handler in der globalen requirements.toml. Work Cloud ohne lokalen Zugriff und persönliche Konten verwenden diese Unternehmens-Hooks nicht. Befehls-/Shell-, Prompt- und Agent-Handler; Hooks aus lokaler Konfiguration, Plugins oder lokalen Verzeichnissen; umgebungsbezogene Hooks; sowie SessionEnd-MCP-Hooks werden bei der Cloud-Orchestrierung nicht unterstützt, selbst wenn Tools lokal ausgeführt werden. Wenn sowohl Orchestrierung als auch Ausführung lokal erfolgen, funktionieren bestehende unterstützte Hooks weiterhin in rein lokalen Work- und Codex-Threads. Administratoren können für diese Workflows weiterhin unterstützte verwaltete Hooks in Agent Security konfigurieren. Bevor Sie sich auf diese Hooks verlassen, testen Sie die Callback-Konnektivität, die erforderlichen Ereignisse und das Verhalten bei Fehlern. Eine explizite, unterstützte Ablehnung kann eine Aktion blockieren. Ein Fehler im PreToolUse-Callback, eine Zeitüberschreitung oder eine fehlerhaft formatierte Antwort kann jedoch zum Fehlschlagen des Hooks führen, ohne das Tool zu blockieren. MCP-Hooks stellen kein vollständiges Audit-Protokoll der Compliance API bereit. Weitere Informationen finden Sie in der Konfigurationsreferenz.

Speicherorte und Rangfolge

Für die lokale Ausführung werden Anforderungen in der folgenden Reihenfolge von niedrigerer zu höherer Priorität angewendet. Diese Reihenfolge gilt auch für lokale Schritte beim lokalen Computerzugriff mit Work Cloud:

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. Agent Security-Anforderungen, die im Cloud-Konfigurationspaket bereitgestellt werden.
3. Ältere managed_config.toml-Felder, die der lokale Client als Anforderungen neu interpretiert.
4. Verwaltete macOS-Einstellungen (MDM), die über com.openai.codex:requirements_toml_base64 bereitgestellt werden.

Ebenen mit höherer Priorität überschreiben gewöhnliche Skalar- und Listenwerte aus niedrigeren Ebenen. Tabellen werden nach Schlüssel zusammengeführt, während Anforderungen wie Regeln, Hooks und Dateisystembeschränkungen feldspezifisch kombiniert werden. Verwenden Sie die Referenz zu requirements.toml für das aktuelle Schema, statt anzunehmen, dass jedes Feld auf dieselbe Weise zusammengeführt wird.

Aus Gründen der Abwärtskompatibilität interpretieren unterstützte lokale Clients die älteren 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.

Rangfolge beim lokalen Computerzugriff mit Work Cloud

Unterscheiden Sie bei Work mit lokalem Zugriff und dots zwischen globalen Orchestrator-Richtlinien und Ausführungsrichtlinien. Die geltenden lokalen Anforderungen steuern den verbundenen Computer. Work-Cloud-Container und dots-Cloud-Computer verwenden ihre eigene Ausführungskonfiguration und ihre eigenen Anforderungen anstelle des verwalteten Umgebungspakets, das andere Ausführungsinstanzen verwenden.

Bei der lokalen Ausführung haben MDM und ältere Anforderungen für verwaltete Geräte Vorrang vor Agent Security. Die Systemanforderungsdatei des Geräts ist Agent Security nachgeordnet. Werten Sie innerhalb jeder Richtlinie zuerst betriebssystemspezifische Umgebungsüberschreibungen aus, dann betriebssystemübergreifende Umgebungsüberschreibungen und schließlich Global. Richtlinienübergreifend hat die Richtlinienpriorität Vorrang vor der Spezifität.

Anforderungen legen Beschränkungen fest, während Konfigurationsstandardwerte Ausgangswerte liefern. Für Work mit lokalem Zugriff und dots gilt die unterstützte Global-Richtlinie über den gemeinsamen Cloud-Orchestrator, wenn verwaltete Richtlinien aktiviert sind. Die geltenden lokalen Anforderungen aus requirements.toml regeln die Ausführung auf einem verbundenen Computer. Work-Cloud-Container und dots-Cloud-Computer verwenden ihre eigene Ausführungskonfiguration und eigene Anforderungen anstelle des verwalteten Umgebungspakets, das andere Ausführungsinstanztypen verwenden. Lokale Ausführungsbeschränkungen gelten nicht automatisch für diese Cloud-Computer. Überprüfen Sie die Berechtigungen für Cloud-Funktionen und testen Sie die lokale Ausführung und die Cloud-Ausführung getrennt.

Belassen Sie Orchestrator-Steuerungen, einschließlich Genehmigungen und Websuche, in Global. Verwenden Sie, sofern verfügbar, die speziellen Steuerungen für zulässige Genehmigungsrichtlinien und zulässige Websuchmodi sowie TOML für andere unterstützte Felder. Die Feldliste und den Ausführungsbereich finden Sie in der Konfigurationsreferenz.

Cloudverwaltete Anforderungen

Wenn sich ein Benutzer mit ChatGPT in einem unterstützten Tarif anmeldet, können unterstützte lokale Clients vom Administrator durchgesetzte Anforderungen für den Workspace empfangen. Dies ist ein Bereitstellungskanal für Richtlinien, die mit requirements.toml kompatibel sind. Er gewährt keinen Workspace-Zugriff und ersetzt nicht die rollenbasierte Zugriffskontrolle des Workspaces. Authentifizierungsanforderungen müssen lokal verwaltet werden.

Konfigurieren Sie gängige Anforderungen mit den Steuerungen für Agent Security. Für eine Richtlinie, die nur Genehmigungen auf Anfrage und schreibgeschützte Sandboxes oder Sandboxes mit Schreibzugriff auf den Workspace zulässt, verwenden Sie Genehmigungsrichtlinien und Sandbox-Modi unter Richtlinienleitplanken. Um auch vor der Ausführung eines unterstützten Shell-Einstiegspunkts eine Bestätigung anzufordern, verwenden Sie Als TOML bearbeiten, um die [rules]-Tabelle zu Global requirements.toml hinzuzufügen.

Die vollständige TOML-Entsprechung lautet:

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üfen Sie, ob jede verwaltete Clientversion die von Ihnen ausgewählten Schlüssel unterstützt. Weisen Sie die Richtlinie den vorgesehenen Benutzern oder Gruppen zu und überprüfen Sie, ob sie auf deren unterstützten Clients wirksam wird. Verwenden Sie die Konfigurationsreferenz für das aktuelle Schema und die Verwaltungsoberflä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 Anforderungsquellen aus, die unter Speicherorte und Rangfolge beschrieben sind. Verwenden Sie die aktuelle Verwaltungsoberfläche für die Erstellung und Zuweisung auf Workspace-Seite. Verlassen Sie sich 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 finden Sie unter Beispiel für requirements.toml und in der Referenz zu requirements.toml.

Wie lokale Clients cloudverwaltete Anforderungen anwenden

Das nachfolgend beschriebene lokale Lade- und Cache-Verhalten gilt für unterstützte lokale Clients. Es legt nicht fest, wann eine geänderte Cloud-Richtlinie in einer bereits laufenden Aufgabe wirksam wird, die lokalen Computerzugriff mit Work Cloud verwendet. Überprüfen Sie die wirksame Richtlinie, bevor Sie sich auf eine geänderte Beschränkung verlassen.

Wenn ein Benutzer einen unterstützten lokalen Client startet und sich mit ChatGPT in einem unterstützten Tarif anmeldet, prüft der Client zunächst, ob ein gültiger, zur Identität passender Cache-Eintrag vorhanden ist. Ist kein gültiger Eintrag verfügbar, ruft der Client das geltende Paket mit Wiederholungsversuchen ab 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, anstatt unbemerkt ohne die cloudverwaltete Anforderungsebene zu starten.

Nach der Cache-Auflösung führt der Client die Cloud-Anforderungen mit den anderen oben beschriebenen Anforderungsebenen zusammen. Eine Aktualisierung im Hintergrund aktualisiert das zwischengespeicherte Paket und stellt es für nachfolgende Konfigurationsladevorgänge bereit. Dies garantiert nicht, dass eine bereits laufende Aufgabe sofort eine geänderte Richtlinie verwendet. Einige Desktop-Einstellungen erfordern einen Neustart der App; folgen Sie allen Neustartaufforderungen und überprüfen Sie die wirksamen Einstellungen, bevor Sie sich auf die Änderung verlassen.

Verhalten für Administratoren und Mitarbeitende überprüfen

Benennen Sie für jede verwaltete Richtlinie eine verantwortliche Person, halten Sie fest, welche Benutzer oder Gruppen sie erhalten sollen, und dokumentieren Sie den geschäftlichen Grund für jede Beschränkung des Dateisystems, des Netzwerks, der Genehmigungen oder des Berechtigungsprofils.

Testen Sie einen zulässigen und einen blockierten Workflow mit einem Benutzer, der über die vorgesehenen Berechtigungen verfügt. Prüfen Sie die wirksamen Einstellungen im unterstützten Client. Eine Workspace-Rolle oder -Gruppe allein setzt keine lokale Laufzeitbeschränkung durch.

Verwenden Sie Richtlinien testen in Agent Security, um zu prüfen, welche Richtlinien auf eine Auswahl von Mitgliedern, Gruppen oder Rollen zutreffen. In einer bearbeitbaren Sitzung wird dabei der aktuelle Entwurf geprüft, ohne ihn zu speichern. Das Ergebnis zeigt die Richtlinienauswahl, nicht die endgültige zusammengeführte Konfiguration oder ob ein Client eine Beschränkung durchsetzt. Testen Sie nach dem Speichern die zulässigen und blockierten Workflows auf jedem relevanten Client und Ausführungspfad.

Geräteverwaltete Konfiguration bereitstellen

Verwenden Sie lokale Systemanforderungen oder MDM für Authentifizierungsbeschränkungen und geräteverwaltete Richtlinien. Der ältere managed_config.toml-Mechanismus hat beim Start eine andere Rangfolge als Standardwerte in Agent Security. Der MDM-Workflow deckt sowohl Anforderungen als auch ältere Standardwerte ab.

Authentifizierung lokal verwalten

Legen Sie allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store und chatgpt_base_url in der lokalen Systemdatei requirements.toml oder in den macOS-MDM-Anforderungen fest. Codex ignoriert diese vier Felder in cloudverwalteten Anforderungen. Lokale Authentifizierungsanforderungen gelten, bevor Anmeldedaten geladen werden und bevor Codex die Cloud-Richtlinie abruft.

Um die ChatGPT-Anmeldung bei einem genehmigten Workspace vorzuschreiben und Anmeldedaten im Anmeldedatenspeicher des Betriebssystems zu speichern, verwenden Sie:

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. Wird diese Einstellung weggelassen, 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-Beschränkung gilt auch für Codex-Zugriffstoken.

Die vom Benutzer konfigurierten Werte für forced_login_method und forced_chatgpt_workspace_id müssen den Anforderungen entsprechen. Wenn ein Benutzer einen Workspace auswählt, muss dieser auch in der verwalteten Zulassungsliste für Workspaces enthalten sein. Stimmen keine Workspaces überein, ist die ChatGPT-Anmeldung nicht verfügbar. Die API-Authentifizierung bleibt verfügbar, sofern sie zulässig ist. Wenn keine Anmeldemethode verfügbar ist, verweigert Codex den Start.

Informationen zu Speichermodi für Anmeldedaten und zur Konfiguration der Dienst-URL finden Sie in der Anforderungsreferenz .

Verwaltete Standardwerte (managed_config.toml)

Verwenden Sie Standardwerte in Agent Security für unterstützte cloudverwaltete Ausgangswerte. Dieser Abschnitt behandelt den älteren geräteverwalteten managed_config.toml-Mechanismus und seine abweichende Rangfolge beim Start. Durch das Bearbeiten von Standardwerte in Agent Security wird keine managed_config.toml-Datei auf den Geräten der Mitglieder bereitgestellt.

Verwaltete Standardwerte legen die Konfiguration fest, mit der ein unterstützter lokaler Client gestartet wird. Beim Start überschreiben sie die lokale config.toml des Benutzers und alle CLI-Überschreibungen für --config. Benutzer können diese Einstellungen während der aktuellen Ausführung weiterhin ändern; beim nächsten Start des Clients werden die Standardwerte erneut angewendet.

GPT-5.5 wird am 14. Oktober 2026 um 12:00 Uhr PDT (19:00 Uhr UTC) für Codex mit ChatGPT-Anmeldung eingestellt. Wenn ein verwalteter Standardwert, ein macOS-MDM-Profil oder eine gespeicherte Konfiguration für diese Benutzer gpt-5.5 fest vorgibt, ersetzen Sie es durch ein verfügbares Modell. Wählen Sie gpt-6.1-sol, sobald ein Administrator es für die betroffenen Benutzer aktiviert hat. Die OpenAI API und mit einem API key authentifizierte Codex-Sitzungen sind davon nicht betroffen. Siehe Modellverfügbarkeit im Workspace.

Folgen Sie bei Konfigurationen, die weiterhin gpt-5.4 oder gpt-5.4-mini fest vorgeben, den Hinweisen zur Migration von GPT-5.4.

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.

Für config.toml aus der Cloud gilt die normale Konfigurationsrangfolge, nicht die oben beschriebene ältere Reihenfolge. Für requirements.toml aus der Cloud gilt die Anforderungsrangfolge.

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.

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

• Verwenden Sie für die meisten Benutzer vorzugsweise 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 keine für Ihre Workflows erforderlichen Domains zulässt.
• Legen Sie OTel-Einstellungen (Exporter, Umgebung) über die verwaltete Konfiguration verbindlich fest, behalten Sie aber 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 der lokalen config.toml und der verwalteten Richtlinie, um Abweichungen zu erkennen; verwaltete Ebenen sollten Vorrang vor lokalen Flags und Dateien haben.

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 „verwalteten Einstellungen“ als TOML. Für verwaltete Standardwerte (config_toml_base64) haben verwaltete Einstellungen die höchste Priorität. Bei Anforderungen (requirements_toml_base64) richtet sich die Priorität nach der Rangfolge der Anforderungen. Dieselbe anforderungsseitige Tabelle [features] funktioniert auch in requirements_toml_base64; verwenden Sie dort ebenfalls kanonische Feature-Schlüssel.

Ablauf der MDM-Einrichtung

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.