Berechtigungen

Verwaltetes allowed_permission_profiles ist die Ausnahme: Dadurch verwendet Codex Berechtigungsprofile. Entfernen Sie ältere Einstellungen wie sandbox_mode und [sandbox_workspace_write], bevor Sie eine verwaltete Profil-Zulassungsliste bereitstellen. Für eine unternehmensweite Einführung mit gemischten Versionen können Sie die verwaltete Anforderung allowed_sandbox_modes vorübergehend als Kompatibilitätsbeschränkung beibehalten, bis auf jedem Client Codex 0.138.0 oder höher ausgeführt wird.

Mit Berechtigungsprofilen können Sie Grenzen nach dem Prinzip der minimalen Rechte auf lokale Befehle anwenden, die Codex in Ihrem Auftrag ausführt. Ein Profil ist eine benannte Richtlinie, die Dateisystemregeln, die festlegen, was Befehle lesen oder schreiben dürfen, mit Netzwerkregeln kombiniert, die festlegen, welche Ziele Befehle erreichen dürfen.

Verwenden Sie Profile, um Codex ausreichend Zugriff für den aktuellen Chat zu gewähren, ohne umfassenden Zugriff auf Ihren Computer oder Ihr Netzwerk einzuräumen. Ein schreibgeschütztes Profil kann Codex beispielsweise erlauben, ein Projekt zu untersuchen, ohne es zu bearbeiten, während ein schreibfähiges Profil Änderungen auf ausgewählte Workspace-Stammverzeichnisse beschränken kann.

Lokale Berechtigungsprofile werden unter macOS, Linux, WSL und nativem Windows unterstützt. Plattformspezifische Details und Einschränkungen finden Sie unter Geltungsbereich und Durchsetzung.

Die aktuellen Netzwerkeinstellungen für Codex Cloud finden Sie unter Verbindung zu Diensten herstellen. Informationen zu Codex Cloud (Legacy) finden Sie unter Internetzugriff.

Profil definieren und auswählen

Codex umfasst drei integrierte Berechtigungsprofile:

• :read-only beschränkt die lokale Befehlsausführung auf Lesezugriffe.
• :workspace erlaubt Schreibzugriffe innerhalb der aktiven Workspace-Stammverzeichnisse und temporären Systemverzeichnisse.
• :danger-full-access hebt lokale Sandbox-Beschränkungen auf und sollte nur verwendet werden, wenn dieser umfassende Zugriff beabsichtigt ist.

Erstellen Sie unter [permissions.<name>] ein benanntes Profil und legen Sie anschließend den Schlüssel default_permissions auf oberster Ebene auf diesen Profilnamen oder eines der oben genannten integrierten Profile fest. In diesem Beispiel ist project-edit ein benutzerdefinierter Profilname und kein integrierter Wert.

Unternehmensadministratoren können Profile definieren und über verwaltetes requirements.toml einschränken, welche Profile Benutzer auswählen dürfen. Sobald allowed_permission_profiles vorhanden ist, werden nicht aufgeführte Profile verweigert – einschließlich nicht aufgeführter integrierter Profile und Profile, die in zukünftigen Codex-Versionen hinzugefügt werden. Die empfohlene verwaltete Konfiguration finden Sie unter Verfügbare Berechtigungsprofile steuern.

Benutzerdefinierte Profile verwenden zwei zusammengehörige Konzepte:

• [permissions.<name>.workspace_roots] fügt konkrete Verzeichnisse hinzu, die für dieses Profil als Workspace-Stammverzeichnisse gelten sollen.
• [permissions.<name>.filesystem.":workspace_roots"] definiert die Dateisystemregeln, die Codex innerhalb jedes effektiven Workspace-Stammverzeichnisses anwendet: die Workspace-Stammverzeichnisse der Laufzeit der aktuellen Sitzung sowie die oben definierten Profil-Stammverzeichnisse.

Profile verwenden außerdem das normale Modell der Konfigurationsebenen. Ebenen mit höherer Priorität können Einträge unter demselben Profilnamen hinzufügen oder ersetzen, ohne das gesamte Profil erneut anzugeben.

Beispielsweise können eine Konfiguration auf Organisationsebene und eine Konfiguration auf Benutzerebene dasselbe Profil unabhängig voneinander erweitern:

# /etc/codex/config.toml
[permissions.server.workspace_roots]
"~/code/server" = true

# ~/.codex/config.toml
[permissions.server.workspace_roots]
"~/code/mobile-app" = true

Wenn server aktiv ist, sind beide Workspace-Stammverzeichnisse Bestandteil des effektiven Profils.

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
"objects.githubusercontent.com" = "allow"
"*.github.com" = "allow"
"tracking.example.com" = "deny"

Dieses Profil:

• Liest die minimalen Laufzeitpfade, die gängige Entwicklerwerkzeuge benötigen.
• Wendet dieselben Regeln für Workspace-Stammverzeichnisse auf die aktuelle Sitzung und die vom Profil definierten Stammverzeichnisse an.
• Beschränkt IDE-nahe Einstellungen wie .devcontainer/ unter jedem Stammverzeichnis auf Lesezugriffe.
• Verweigert übereinstimmende Umgebungsdateien mit einer Glob-Regel.
• Erlaubt Netzwerkzugriff ausschließlich über die konfigurierte Domänenrichtlinie.

Innerhalb eines aktiven Profils bleiben enger gefasste Verweigerungsregeln wirksam, selbst wenn ein weiter gefasster Pfad les- oder schreibbar ist. Ein Profil kann beispielsweise Workspace-Stammverzeichnisse schreibbar machen und zugleich einen übereinstimmenden .env-Pfad auf deny setzen.

Profil erweitern

Verwenden Sie extends, wenn ein Profil weitgehend einem integrierten oder einem anderen benannten Profil entspricht. Erweitern Sie vorzugsweise ein integriertes Profil, statt bei null anzufangen, damit die grundlegenden Schutzmaßnahmen erhalten bleiben. Wenn Sie beispielsweise :workspace erweitern, bleiben die Pfade .git, .agents, .codex und .aws im Stammverzeichnis des Arbeitsbereichs schreibgeschützt, sofern Sie diese Regeln nicht ausdrücklich überschreiben. Legen Sie das übergeordnete Profil einmal fest und ergänzen oder überschreiben Sie anschließend nur die abweichenden Regeln.

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
description = "Project editing with OpenAI API access."
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

Dieses Profil basiert auf :workspace, verweigert weiterhin übereinstimmende .env-Dateien und erlaubt Anfragen an api.openai.com. Ein Profil kann :read-only, :workspace oder ein anderes benanntes Profil erweitern. Es kann :danger-full-access nicht erweitern; Codex weist außerdem unbekannte übergeordnete Profile und Vererbungszyklen zurück.

Konfigurationsspezifikation

Dateisystemberechtigungen

Dateisystemeinträge verwenden read, write oder deny:

Spezifischere Einträge überschreiben weiter gefasste Einträge. Wenn zwei Einträge auf denselben Pfad abzielen, hat deny Vorrang vor write und write hat Vorrang vor read.

Dank dieser Rangfolge kann ein Profil zunächst einen weit gefassten Arbeitsbereich beschreiben und anschließend Dateien oder Verzeichnisse ausnehmen, die unlesbar bleiben sollen:

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

In diesem Beispiel bleibt das Workspace-Stammverzeichnis schreibbar, .devcontainer/ bleibt lesbar, ohne schreibbar zu werden, und übereinstimmende Umgebungsdateien bleiben für Sandbox-Befehle unzugänglich.

Ein spezifischerer Pfad kann außerdem einen engeren Teilbaum innerhalb einer weiter gefassten Verweigerung wieder öffnen:

[permissions.project-edit.filesystem]
"~/Documents" = "deny"
"~/Documents/codex" = "write"

Unterstützte Pfadformen:

Unter nativem Windows können Home-relative Pfade auch umgekehrte Schrägstriche verwenden, beispielsweise ~\work.

Verwenden Sie :root nur, wenn ein Profil bewusst eine umfassende Leseabdeckung benötigt:

[permissions.audit.filesystem]
":root" = "read"

Verwenden Sie verschachtelte Einträge unter :workspace_roots, um den Zugriff auf relative Unterpfade des Workspace-Stammverzeichnisses zu begrenzen:

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"          # each workspace root
"docs" = "read"        # each workspace-root docs directory
"generated" = "deny"   # each workspace-root generated directory

Verschachtelte Unterpfade müssen innerhalb ihres Workspace-Stammverzeichnisses verbleiben. Übergeordnete Traversierung wie ../other-repo wird zurückgewiesen.

Lesezugriffe mit exakten Pfaden oder Globs verweigern

Verwenden Sie deny für Dateien oder Teilbäume, die Codex nicht lesen soll, selbst wenn eine weiter gefasste Profilregel den Zugriff in der Nähe gewährt. Exakte Pfade eignen sich gut für stabile Speicherorte wie ~/.ssh. Glob-Muster eignen sich besser, wenn ein Profil eine Gruppe vertraulicher Dateien abdecken muss, deren genaue Speicherorte sich je nach Repository unterscheiden.

Wenn sich ein Glob unter :workspace_roots befindet, interpretiert Codex ihn relativ zu jedem effektiven Workspace-Stammverzeichnis. Beispiel:

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Diese Regel verweigert Lesezugriffe auf übereinstimmende .env-Dateien, die unter jedem Laufzeit- oder vom Profil definierten Workspace-Stammverzeichnis gefunden werden. Verwenden Sie sie, wenn Sie normale Workspace-Schreibzugriffe beibehalten und zugleich Umgebungsdateien, generierte Geheimnisse oder ähnliche Dateien mit Zugangsdaten unlesbar halten möchten.

Unter Linux, WSL und nativem Windows mit MXC oder elevated werden Dateien, die Globs für verweigerte Lesezugriffe entsprechen, beim Start jedes Sandbox-Prozesses ermittelt. Später erstellte passende Dateien werden nicht zur Sperrliste dieses Prozesses hinzugefügt und bleiben lesbar, wenn seine übrigen Berechtigungen den Zugriff erlauben. Beispielsweise kann eine lange laufende Shell, ein Skript, ein Watcher oder ein Entwicklungsserver eine passende .env-Datei lesen, die nach seinem Start erstellt wurde.

Diese Momentaufnahme gilt für die gesamte Lebensdauer des Sandbox-Prozesses, nicht für die gesamte Codex- Sitzung. Wenn Sie über Codex einen neuen Sandbox-Prozess starten, werden die passenden Dateien erneut ermittelt; die weitere Nutzung eines bereits laufenden Prozesses aktualisiert dessen Sperrliste nicht. Verlassen Sie sich nicht darauf, dass ein Glob neu erstellte Dateien in diesem laufenden Prozess blockiert. Informationen zu Windows-spezifischen Einschränkungen finden Sie unter Windows-MXC-Kompatibilität .

deny-Glob-Muster werden als Regeln zur Leseverweigerung unterstützt. read- oder write-Globs sind bei der Sandbox-Ausführung unter Linux, WSL und nativem Windows weniger portabel. Bevorzugen Sie daher nach Möglichkeit exakte Pfade oder Teilbaumregeln wie "docs/**" = "read".

Unter Linux, WSL und nativem Windows kann ein unbegrenztes **-Muster zur Leseverweigerung vor dem Sandbox-Start eine begrenzte Vorab-Erweiterung benötigen. Legen Sie glob_scan_max_depth fest, wenn Sie ein unbegrenztes Muster wie "**/*.env" = "deny" verwenden:

[permissions.project-edit.filesystem]
glob_scan_max_depth = 3

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

glob_scan_max_depth muss mindestens 1 betragen. Höhere Werte führen vor dem Sandbox-Start zu tieferen Scans, was unter Linux, WSL und nativem Windows den Startaufwand erhöhen kann. Wenn Sie keine begrenzte Erweiterung verwenden möchten, geben Sie explizite Tiefen an, etwa *.env, */*.env und */*/*.env.

Fügen Sie dem Profil wiederverwendbare Workspace-Stammverzeichnisse hinzu, wenn dieselben Regeln für mehr als das Stammverzeichnis der aktuellen Sitzung gelten sollen:

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

Wenn dieses Profil aktiv ist, wendet Codex die Regeln aus :workspace_roots auf die Workspace-Stammverzeichnisse der Laufzeit der aktuellen Sitzung sowie auf jedes aktivierte, vom Profil definierte Workspace-Stammverzeichnis an.

Unter nativem Windows werden Laufwerkbuchstabenpfade wie D:\work und UNC-Pfade wie \\server\share als absolute Pfade unterstützt.

Netzwerkberechtigungen

Netzwerkzugriff und Netzwerkfilterung sind separate Einstellungen. Legen Sie permissions.<name>.network.enabled = true fest, um Befehlen den Netzwerkzugriff zu ermöglichen, und aktivieren Sie features.network_proxy, um die Domänenregeln des Profils durchzusetzen:

[features]
network_proxy = true

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"example.com" = "allow"      # exact host
"*.example.com" = "allow"    # subdomains only
"**.example.com" = "allow"   # apex and subdomains
"ads.example.com" = "deny"   # deny wins over allow

Das resultierende Verhalten hängt von beiden Einstellungen ab:

• Netzwerk aus: Befehle können unabhängig von der Proxy-Funktion nicht auf das Netzwerk zugreifen.
• Netzwerk ein, Proxy aus: Befehle haben direkten, uneingeschränkten Netzwerkzugriff. Domänenregeln im Berechtigungsprofil werden nicht durchgesetzt.
• Netzwerk ein, Proxy ein: Befehle verwenden den Proxy, der die Domänenregeln des Profils durchsetzt. Wenn der aktive Proxy keine zulässigen Domänen enthält, blockiert er externe Ziele.

Das Hinzufügen von [permissions.<name>.network.domains] oder das Festlegen von permissions.<name>.network.enabled = true aktiviert features.network_proxy nicht. Alternativ können Administratoren den Proxy mit [experimental_network] in requirements.toml aktivieren. Siehe Verwaltete Konfiguration.

Wenn der Netzwerk-Sandbox-Proxy aktiv ist, bindet er sich standardmäßig an lokale Listener:

[permissions.project-edit.network]
enabled = true
proxy_url = "http://127.0.0.1:3128"
enable_socks5 = true
socks_url = "http://127.0.0.1:8081"
enable_socks5_udp = true

Belassen Sie diese Listener-Einstellungen auf ihren Standardwerten, sofern Sie keine Integration mit einer bestimmten Laufzeit vornehmen. Die Netzwerkschlüssel unter dangerously_* sind Schlupflöcher für spezialisierte Umgebungen und sollten nicht für die gewöhnliche lokale Entwicklung verwendet werden.

Lokale und private Netzwerke

Wenn der Netzwerk-Proxy aktiv ist, wendet Codex standardmäßig einen Schutz für lokale/private Netzwerke an, um DNS-Rebinding und versehentliche Zugriffe auf lokale Dienste abzuwehren. Um ein lokales Literalziel bewusst zuzulassen, nehmen Sie den exakten Host oder das exakte IP-Literal in die Zulassungsliste auf:

[permissions.project-edit.network.domains]
"localhost" = "allow"
"127.0.0.1" = "allow"

Legen Sie allow_local_binding = true nur fest, wenn das Profil auf zugelassene Hostnamen zugreifen muss, die in lokale oder private Adressen aufgelöst werden:

[permissions.project-edit.network]
enabled = true
allow_local_binding = true

[permissions.project-edit.network.domains]
"localhost" = "allow"

Unix-Sockets

Unix-Socket-Proxying ist ein lokales Schlupfloch für Werkzeuge wie Docker. Verwenden Sie es sparsam:

[permissions.project-edit.network.unix_sockets]
"/var/run/docker.sock" = "allow"
"/tmp/old.sock" = "deny"

Verwenden Sie deny, um einen Socket-Pfad einschließlich eines geerbten Zulassungseintrags zurückzuweisen. Verweigerte Socket-Pfade werden aus der effektiven Zulassungsliste ausgelassen.

Wenn Unix-Sockets aktiviert sind, binden Sie Proxy-Listener weiterhin an Loopback-Adressen.

Von älteren Sandbox-Einstellungen migrieren

Berechtigungsprofile ersetzen die ältere Kombination aus sandbox_mode und sandbox_workspace_write, wenn Sie Dateisystem- und Netzwerkverhalten in einem wiederverwendbaren Profil beschreiben möchten. Verwenden Sie für eine Sitzung entweder das eine oder das andere System, nicht beide.

Empfohlene Ausgangspunkte:

• Verwenden Sie für einen schreibgeschützten Workflow das integrierte Profil :read-only oder definieren Sie ein benutzerdefiniertes Profil mit Lesezugriff nur dort, wo er benötigt wird.
• Verwenden Sie zum Bearbeiten des Workspace das integrierte Profil :workspace oder definieren Sie ein benutzerdefiniertes Profil, das über :workspace_roots schreibt und nur die zusätzlichen temporären oder Cache-Pfade hinzufügt, die der Workflow benötigt.
• Verwenden Sie für die uneingeschränkte lokale Ausführung :danger-full-access nur, wenn Sie bewusst das umfassendste lokale Zugriffsmodell wünschen.

Profile beschreiben die lokale Standardhaltung einer Sitzung. Von der Organisation verwaltete Anforderungen können weiterhin Einschränkungen hinzufügen, die durch die Benutzerkonfiguration nicht gelockert werden dürfen. Informationen zu durch Administratoren erzwungenen Dateisystem- und Netzwerkbeschränkungen finden Sie unter Verwaltete Konfiguration.

Geltungsbereich und Durchsetzung

Lokaler Computerzugriff mit Work Cloud und Umgebungsrichtlinien

Prüfen Sie die Richtlinie für jede Umgebung, in der lokaler Computerzugriff mit Work Cloud ausgeführt wird:

• Unternehmensvorgaben: Bei Work mit lokalem Zugriff und dots regelt die unterstützte Global-Richtlinie den gemeinsam genutzten Cloud-Orchestrator, wenn verwaltete Richtlinien aktiviert sind; für den verbundenen Computer gelten die jeweiligen Vorgaben für die lokale Ausführung.
• Cloud-Ausführung: Work-Cloud-Container verwenden bestehende Work Cloud-Richtlinien.
• Rangfolge lokaler Richtlinien: MDM und ältere Vorgaben für verwaltete Geräte haben Vorrang vor Agent Security. Die Systemvorgabendatei des Geräts ist Agent Security nachgeordnet.
• Richtlinienpriorität: Eine Richtlinie mit höherer Priorität hat Vorrang, selbst wenn eine nachrangige Richtlinie spezifischer ist. Innerhalb einer Richtlinie haben betriebssystemspezifische Umgebungsüberschreibungen Vorrang vor betriebssystemübergreifenden Umgebungsüberschreibungen, gefolgt von Global.

Für einige Vorgaben gelten feldspezifische Zusammenführungsregeln. Informationen zu unterstützten Feldern und Laufzeitbeschränkungen finden Sie unter Verwaltete Konfiguration und in der Konfigurationsreferenz. Gehen Sie nicht davon aus, dass Work Cloud die hier gezeigten Codex-Berechtigungsprofile unterstützt.

Berechtigungsprofile definieren die Grenzen für die lokale Befehlsausführung in der Sandbox. Verwenden Sie sie zusammen mit Genehmigungsrichtlinien und den separaten Steuerelementen für Websuche, Konnektoren, MCP server, den integrierten Browser, Computer Use und Codex cloud.

Was Profile steuern

• Lokale Befehlsausführung: Berechtigungsprofile steuern Sandbox-Befehle, die auf Ihrem Computer ausgeführt werden. Konnektoren, MCP server, Browser- oder Computer-Use-Oberflächen, Umgebungseinstellungen von Codex cloud und genehmigte Rechteausweitungen verwenden eigene Steuerelemente.
• Dateisystem-Schreibzugriffe: Ein schreibfähiges Profil kann dauerhafte Änderungen erstellen. Behandeln Sie Schreibzugriffe auf Skripte, Build-Schritte, Paketmanager-Hooks, Shell-Startdateien und gemeinsam genutzte Verzeichnisse als vertraulich, da spätere Werkzeuge oder Benutzer diese Dateien außerhalb des ursprünglichen Sandbox-Kontexts ausführen können.
• Ausgehende Ziele: Netzwerk-Domänenregeln begrenzen nur bei aktivem Netzwerk-Proxy, wohin der Befehlsverkehr aus der Sandbox gesendet werden kann. Sie bestimmen nicht, ob ein zulässiges Ziel vertrauenswürdig ist, und Platzhalter-Zulassungsregeln bleiben weit gefasst.
• Lokale Dienste: Ein aktiver Netzwerk-Proxy blockiert standardmäßig Ziele in lokalen und privaten Netzwerken. Die Zulassung von localhost, privaten IPs oder Unix-Sockets bzw. das Festlegen von allow_local_binding = true öffnet ausdrücklich den Zugriff auf lokale Dienste.

Was der Netzwerk-Proxy nicht steuert

Der Netzwerk-Proxy filtert nur Datenverkehr von lokalen Befehlen, die innerhalb der Sandbox ausgeführt werden. Er wendet die Domänen-Zulassungsliste des Profils nicht auf Folgendes an:

• Websuche: Das gehostete Suchtool verwendet eigene Zugriffseinstellungen. Verwenden Sie web_search und bei verwalteten Clients allowed_web_search_modes, um sie zu steuern. tools.web_search.allowed_domains filtert Suchergebnisse, nicht den Netzwerkzugriff von Befehlen.
• Apps und Konnektoren: Konnektorbasierte Tools verwenden eigene dienstseitige Verbindungen, Workspace-Berechtigungen und App- oder Tool-Einstellungen.
• MCP server: Lokale und entfernte MCP server verwenden eigene Prozesse oder Transportmechanismen. Steuern Sie sie über die Konfiguration mcp_servers und verwaltete Server-Freigabelisten.
• Browser und Computer Use: Browsernavigation und Computer-Use-Aktionen verwenden eigene Funktions- und Genehmigungssteuerungen.
• Codex-Dienstverkehr: Modell-, Authentifizierungs- und andere Dienstanfragen des Clients verwenden die separaten HTTP- und Systemproxy-Einstellungen des Clients.
• Codex Cloud: Diese Aufgaben verwenden die eigenen Netzwerkeinstellungen ihrer Umgebung. Codex Cloud (Legacy) verfügt über separate Einstellungen für den Internetzugriff.

Um diese Oberflächen einzuschränken, konfigurieren Sie jede Funktion direkt. Eine Netzwerk-Zulassungsliste für Befehle ist keine globale Netzwerkrichtlinie für jede Aktion, die Codex ausführen kann.

Funktionsweise der Durchsetzung

• Unter macOS verwendet Codex Seatbelt-Sandbox-Profile. Wenn die ausgewählte Richtlinie von der Plattform-Sandbox nicht durchgesetzt werden kann, verweigert Codex die Ausführung des Befehls, statt ihn stillschweigend außerhalb der Sandbox auszuführen.
• Unter Linux und WSL verwendet Codex bubblewrap und seccomp, um Dateisystembeschränkungen durchzusetzen. Die ältere Landlock-Option kann app-server-Unix-Sockets nicht isolieren und wird für Richtlinien mit Dateisystembeschränkungen abgelehnt. Deaktivieren Sie features.use_legacy_landlock beim Upgrade. Hosts, die die erforderlichen bubblewrap-Operationen blockieren, können diese Richtlinien nicht ausführen.
• Unter Windows verwendet MXC Prozessisolation für Dateisystem- und Netzwerkberechtigungen. Prüfen Sie die MXC-Kompatibilität, bevor Sie es aktivieren. Die Legacy-Ausweichlösung elevated verwendet dedizierte Sandbox-Benutzer mit eingeschränkten Rechten, Berechtigungsgrenzen im Dateisystem und Firewallregeln. unelevated ist eine Legacy-Ausweichlösung mit schwächerer Netzwerkisolation und kann nicht jede getrennte Lese-/Schreibausnahme durchsetzen, weshalb nicht unterstützte Richtlinien abgelehnt werden. Verwenden Sie WSL, wenn Sie das Linux-Sandbox-Modell benötigen.

Betriebshinweise

Wählen Sie das engste Profil, mit dem die Aufgabe noch abgeschlossen werden kann, insbesondere wenn Sie Schreibzugriffe oder ausgehenden Netzwerkzugriff gewähren. Stimmen Sie Genehmigungsrichtlinie, Umgang mit Geheimnissen und Zulassungsregeln auf diese Zugriffsebene ab.

Häufig verwendete Profile

Schreibgeschützt mit Netzwerk-Zulassungsliste

default_permissions = "readonly-net"

[features]
network_proxy = true

[permissions.readonly-net.filesystem]
":minimal" = "read"

[permissions.readonly-net.filesystem.":workspace_roots"]
"." = "read"

[permissions.readonly-net.network]
enabled = true

[permissions.readonly-net.network.domains]
"api.openai.com" = "allow"

Dateizugriff auf den Workspace beschränkt

Hier sehen Sie ein Beispiel für ein Berechtigungsprofil, das Ihre Workspace-Ordner für Codex schreibbar macht und zugleich Lesezugriffe auf den Rest des Dateisystems verweigert (mit begrenzten Ausnahmen, die durch :minimal bestimmt werden).

default_permissions = "workspace-only"

[permissions.workspace-only]
# By extending the :workspace profile, you get Codex's safeguards to ensure
# paths such as .git/, .agents/, .codex/, and .aws/ within a workspace root
# are read-only while the rest of the folder is writable.
extends = ":workspace"

[permissions.workspace-only.filesystem]
# By default, deny read access to all files on disk.
":root" = "deny"

# Though in practice, a software agent needs to be able to read folders that
# contain common tools, such as `/usr/bin`, to get work done, so grant access
# to a "minimal" set of files and folders, as determined by Codex.
":minimal" = "read"

# By extending the :workspace profile, :tmpdir and :slash_tmp are "write" by
# default, though you can deny access to them altogether, if desired.
":tmpdir" = "deny"
":slash_tmp" = "deny"

Workspace-Schreibzugriff ohne Netzwerk

default_permissions = "project-edit"

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"

[permissions.project-edit.network]
enabled = false

Workspace-Schreibzugriff mit Zugriff auf das öffentliche Web

default_permissions = "workspace-net"

[features]
network_proxy = true

[permissions.workspace-net.filesystem]
":minimal" = "read"

[permissions.workspace-net.filesystem.":workspace_roots"]
"." = "write"

[permissions.workspace-net.network]
enabled = true

[permissions.workspace-net.network.domains]
"*" = "allow"

Verwenden Sie die globale Zulassungsregel "*" nur, wenn Sie öffentlichen Netzwerkzugriff zulassen möchten. Verweigerungsregeln können eine weit gefasste Zulassungsliste einschränken.