Agentenfreigaben und Sicherheit

Codex hilft dir, deinen Code und deine Daten zu schützen, und verringert das Risiko von Missbrauch.

Standardmäßig wird der Agent ohne Netzwerkzugriff ausgeführt. Lokal verwendet Codex eine vom Betriebssystem durchgesetzte Sandbox, die seinen Zugriff in der Regel auf den aktuellen Workspace beschränkt. Außerdem legt eine Genehmigungsrichtlinie fest, wann Codex anhalten und vor einer Aktion deine Genehmigung einholen muss.

Eine grundlegende Erklärung dazu, wie Sandboxing in der ChatGPT-Desktop-App, der Codex CLI und der IDE-Erweiterung funktioniert, findest du unter Sandboxing. Einen umfassenderen Überblick über die Sicherheit im Unternehmenseinsatz bietet das Whitepaper zur Sicherheit von Codex.

Von der eingestellten Genehmigungsrichtlinie untrusted migrieren

Codex und ChatGPT Work unterstützen approval_policy = "untrusted" nicht mehr. Die eingestellte Option kann den Start beider Clients verhindern. Entferne sie aus der Benutzer- oder Projektkonfiguration, aus Profildateien, Startskripten und verwalteten Standardeinstellungen. Für die interaktive Nutzung ohne Schreibzugriff:

sandbox_mode = "read-only"
approval_policy = "on-request"

Oder führe codex --sandbox read-only --ask-for-approval on-request aus.

Mit on-request können von der Sandbox zugelassene Befehle ohne Genehmigung ausgeführt werden, zugängliche Dateien lesen und den Netzwerkzugriff nutzen, sofern er aktiviert ist.

Um die strengere Genehmigungsregel für Befehle beizubehalten, verzichte auf eine explizite Angabe von approval_policy und füge einen Projekteintrag in deiner benutzerweiten Datei ~/.codex/config.toml hinzu:

[projects."/path/to/project"]
trust_level = "untrusted"

Befehle erfordern dann eine Genehmigung, sofern sie nicht durch eine Regel der Ausführungsrichtlinie zugelassen sind. Dadurch wird auch die projektlokale Konfiguration deaktiviert. Wenn du on-request explizit setzt, überschreibt dies die aus dem Projekt abgeleitete Richtlinie. Damit diese zulässig ist, muss die verwaltete Einstellung allowed_approval_policies den Wert untrusted enthalten.

Sandbox und Genehmigungen

Die Sicherheitskontrollen von Codex bestehen aus zwei Ebenen, die zusammenwirken:

• Sandbox-Modus: Was Codex technisch tun kann, wenn es vom Modell generierte Befehle ausführt, zum Beispiel, wo es schreiben darf und ob es auf das Netzwerk zugreifen kann.
• Genehmigungsrichtlinie: Wann Codex dich fragen muss, bevor es eine Aktion ausführt, zum Beispiel die Sandbox verlässt, das Netzwerk nutzt oder Befehle ausführt, die nicht zu einer als vertrauenswürdig eingestuften Auswahl gehören.

Codex verwendet unterschiedliche Sandbox-Modi, je nachdem, wo du es ausführst:

• Codex Cloud: Läuft in isolierten, von OpenAI verwalteten Containern und verhindert so den Zugriff auf dein Hostsystem oder nicht zugehörige Daten. Die Laufzeit umfasst zwei Phasen: Das Setup läuft vor der Agentenphase und kann auf das Netzwerk zugreifen, um angegebene Abhängigkeiten zu installieren. Die anschließende Agentenphase läuft standardmäßig offline, sofern du den Internetzugang für diese Umgebung nicht aktivierst. Für Cloud-Umgebungen konfigurierte Geheimnisse sind nur während des Setups verfügbar und werden vor Beginn der Agentenphase entfernt.
• Codex CLI / IDE-Erweiterung: Mechanismen auf Betriebssystemebene setzen die Sandbox-Richtlinien durch. Standardmäßig ist der Netzwerkzugriff deaktiviert und die Schreibberechtigungen sind auf den aktiven Workspace beschränkt. Du kannst die Sandbox, die Genehmigungsrichtlinie und die Netzwerkeinstellungen an deine Risikotoleranz anpassen.

Mit der Voreinstellung Auto (zum Beispiel --sandbox workspace-write --ask-for-approval on-request) kann Codex automatisch Dateien im Arbeitsverzeichnis lesen, bearbeiten und dort Befehle ausführen.

Codex fordert eine Genehmigung an, um Dateien außerhalb des Workspace zu bearbeiten oder Befehle auszuführen, die Netzwerkzugriff erfordern. Wenn du chatten oder planen möchtest, ohne Änderungen vorzunehmen, wechsle mit dem Befehl /permissions in den Modus read-only.

Codex kann auch für Tool-Aufrufe von Apps (Konnektoren) eine Genehmigung anfordern, wenn diese Nebenwirkungen ausweisen, selbst wenn die Aktion kein Shell-Befehl oder keine Dateiänderung ist. Destruktive App-/MCP-Tool-Aufrufe erfordern immer eine Genehmigung, wenn das Tool eine entsprechende Annotation ausweist. Eine Annotation für Lesezugriff hat jedoch Vorrang und bildet eine Ausnahme.

Sicherheitsüberwachung und pausierte Aufgaben

GPT-6 Astra umfasst eine Sicherheitsüberwachung in Codex und ChatGPT Work. Sie läuft asynchron und kann eine Aufgabe pausieren, wenn sie potenziell unsicheres Modellverhalten erkennt. Die Pause kann erst nach der Aktivität eintreten, die sie ausgelöst hat. Die Überwachung ersetzt weder Sandboxing noch Berechtigungen oder die Überprüfung des Ergebnisses.

Wenn eine Aufgabe pausiert wird, lies den Hinweis und prüfe die Ergebnisse, sofern sie verfügbar sind. Setze die Aufgabe erst fort, nachdem du geprüft hast, dass sie sicher fortgesetzt werden kann. Wenn der Hinweis besagt, dass die Aufgabe beendet wurde, oder keine Option zum Fortsetzen anbietet, kannst du sie über diese Oberfläche nicht fortsetzen.

Die Sicherheitsüberwachung bewertet das Modellverhalten während einer Aufgabe. Die automatische Überprüfung von Genehmigungsanfragen bewertet einzelne Aktionen, die bereits eine Genehmigung erfordern, bevor sie ausgeführt werden. Eine dabei genehmigte Aktion kann dennoch Teil einer Aufgabe sein, die von der Überwachung später pausiert wird.

Netzwerkzugriff Elevated Risk

Wie du in Codex Cloud den vollständigen Internetzugang oder eine Freigabeliste für Domains aktivierst, erfährst du unter Internetzugang für Agenten.

In der ChatGPT-Desktop-App, der Codex CLI und der IDE-Erweiterung bleibt der Netzwerkzugriff im standardmäßigen Sandbox-Modus workspace-write deaktiviert, sofern du ihn nicht in deiner Konfiguration aktivierst:

[sandbox_workspace_write]
network_access = true

Netzwerkisolierung

Der Netzwerkzugriff wird über Regeln für Zieladressen gesteuert. Sie gelten für Skripte, Programme und Unterprozesse, die von Befehlen gestartet werden. Wenn der Netzwerkzugriff für Befehle bereits aktiviert ist, aktiviere die Funktion network_proxy, um diesen Datenverkehr auf die von dir konfigurierte Netzwerkrichtlinie zu beschränken. Das Hinzufügen von Domainregeln allein aktiviert den Proxy nicht.

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

Verwende für eine einzelne CLI-Sitzung die boolesche Kurzform, wenn du die Funktion nur ein- oder ausschalten möchtest. Verwende die Tabellenform, wenn du auch Richtlinienoptionen festlegst:

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

Die Funktion ändert, wie aktivierter Netzwerkzugriff durchgesetzt wird. Sie gewährt selbst keinen Netzwerkzugriff. Verwende sandbox_workspace_write.network_access in der Konfiguration für workspace-write, um festzulegen, ob Befehle überhaupt Netzwerkzugriff haben:

• Netzwerk aus + network_proxy an: Das Netzwerk bleibt deaktiviert und die Funktion hat keine Wirkung.
• Netzwerk an + network_proxy aus: Das Netzwerk bleibt aktiviert, mit uneingeschränktem direktem Zugriff auf ausgehende Verbindungen.
• Netzwerk an + network_proxy an: Das Netzwerk bleibt aktiviert und der ausgehende Datenverkehr wird durch die konfigurierte Netzwerkrichtlinie beschränkt.

Die Proxy-Funktion gilt auch für Berechtigungsprofile. Die Einstellung network.enabled = true eines Profils gewährt Befehlen Netzwerkzugriff. Mit features.network_proxy = true wird dagegen die Durchsetzung der Domainregeln dieses Profils aktiviert:

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

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

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

Wenn du die Proxy-Funktion in diesem Beispiel weglässt, haben Befehle direkten Netzwerkzugriff und die Freigaberegel für api.openai.com schränkt ihre Zieladressen nicht ein.

Administrativ verwaltete Vorgaben für experimental_network sind unabhängig davon, ob die Funktion benutzerseitig aktiviert ist. Sie können Netzwerkzugriff innerhalb der Sandbox auch ohne features.network_proxy konfigurieren und starten. Sie aktivieren den Netzwerkzugriff jedoch nicht, wenn die aktive Sandbox ihn deaktiviert hält. Unter Verwaltete Konfiguration findest du das Format der administrativen Vorgaben in requirements.toml.

Netzwerkrichtlinie

Domainregeln basieren auf einer Freigabeliste:

• Explizit angegebene Hosts stimmen nur mit sich selbst überein.
• *.example.com erfasst Subdomains wie api.example.com, aber nicht example.com.
• **.example.com erfasst sowohl die Stammdomain als auch Subdomains.
• Eine globale Freigaberegel mit * erfasst jeden öffentlichen Host, der nicht gesperrt ist. Betrachte * als weitreichenden Netzwerkzugriff und verwende nach Möglichkeit enger gefasste Regeln.
• deny hat immer Vorrang vor allow, und das globale * ist nur für Freigaberegeln zulässig.

Lokale und private Zieladressen

Standardmäßig blockiert allow_local_binding = false Loopback-, Link-Local- und private Zieladressen:

• Gezielte Ausnahmen: Füge eine Freigaberegel für eine explizite lokale IP-Adresse oder für localhost hinzu, wenn ein Befehl ein einzelnes lokales Ziel benötigt.
• Umfassenderer Zugriff: Setze allow_local_binding = true nur dann, wenn du bewusst einen weitergehenden Zugriff auf lokale oder private Ziele ermöglichen möchtest.
• Platzhalter: Regeln mit Platzhaltern gelten nicht als explizite lokale Ausnahmen.
• Aufgelöste Adressen: Hostnamen, die in lokale oder private IP-Adressen aufgelöst werden, bleiben gesperrt, selbst wenn sie der Freigabeliste entsprechen.

Schutz vor DNS-Rebinding

Bevor Codex einen Hostnamen zulässt, führt es nach bestem Bemühen eine DNS-Prüfung und eine Klassifizierung der IP-Adressen durch:

• Schlägt die Namensauflösung fehl oder überschreitet sie das Zeitlimit, wird der Zugriff blockiert.
• Hostnamen, die in nicht öffentliche Adressen aufgelöst werden, werden blockiert.
• Die Prüfung verringert das Risiko von DNS-Rebinding, beseitigt es aber nicht vollständig. Um Rebinding vollständig zu verhindern, müssten die aufgelösten IP-Adressen bis zur Transportschicht verbindlich festgelegt werden.

Wenn bösartige DNS-Antworten zum Bedrohungsszenario gehören, setze zusätzlich auf einer tieferen Schicht Kontrollen für ausgehenden Datenverkehr durch.

Gefährliche Einstellungen

Zwei Einstellungen erweitern bewusst die Vertrauensgrenze:

• dangerously_allow_non_loopback_proxy = true kann Proxy-Listener auch außerhalb von Loopback erreichbar machen.
• dangerously_allow_all_unix_sockets = true umgeht die Positivliste für Unix-Sockets.

Verwende diese Einstellungen nur in streng kontrollierten Umgebungen. Wenn die Proxy-Weiterleitung für Unix-Sockets aktiviert ist, bleiben Listener ausschließlich an Loopback gebunden, selbst wenn eine Bindung an andere Adressen angefordert wurde. So wird der Netzwerkzugriff innerhalb der Sandbox nicht zu einer Brücke für den Fernzugriff auf lokale Daemons.

network_proxy ist standardmäßig deaktiviert. Wenn du die Funktion aktivierst, gilt Folgendes:

Datenverkehr außerhalb des Netzwerk-Proxys für Befehle

Der Netzwerk-Proxy filtert Skripte, Programme und untergeordnete Prozesse, die innerhalb der lokalen Sandbox für Befehle ausgeführt werden. Er filtert weder die Websuche noch Tool-Aufrufe von Apps oder Konnektoren, Verbindungen zu MCP-Servern, Browseraktivitäten, Computernutzung, Codex Cloud-Aufgaben oder Modell- und Authentifizierungsanfragen des Clients. Diese Bereiche verwenden separate Dienstverbindungen, Funktionseinstellungen, Workspace-Richtlinien oder Umgebungskontrollen.

Browser-Tools prüfen verwaltete Netzwerksperren und ausschließliche Positivlisten separat, bevor sie auf einen Origin zugreifen. Richtlinien für Browser-Origins können den Zugriff auf Websites, Uploads, Downloads und Entwicklertools weiter einschränken. Siehe verwaltete Browserkontrollen.

Kombiniere für verwaltete Konten die Netzwerkrichtlinie für Befehle mit Kontrollen wie allowed_web_search_modes, freigegebenen mcp_servers und Funktionsvorgaben für Apps, Plug-ins, Browser oder Computernutzung. Siehe Verwaltete Konfiguration.

Du kannst auch das Websuche-Tool steuern, ohne gestarteten Befehlen uneingeschränkten Netzwerkzugriff zu gewähren. Codex verwendet standardmäßig einen Websuche-Cache, um Ergebnisse abzurufen. Dieser Cache ist ein von OpenAI gepflegter Index von Webergebnissen. Im Cache-Modus werden daher bereits indexierte Ergebnisse zurückgegeben, statt Seiten live abzurufen. Das verringert das Risiko von Prompt Injection durch beliebige Live-Inhalte. Dennoch solltest du Webergebnisse weiterhin als nicht vertrauenswürdig behandeln. Wenn du --yolo oder eine andere Sandbox-Einstellung mit Vollzugriff verwendest, liefert die Websuche standardmäßig Live-Ergebnisse. Verwende --search oder lege web_search = "live" fest, um Live-Browsing zu erlauben. Setze die Einstellung auf "disabled", um das Tool zu deaktivieren:

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

Lege web_search = "indexed" fest, wenn der Suchindex den Zugriff auf das externe Web begrenzen soll. Sei vorsichtig, wenn du Netzwerkzugriff oder die Websuche in Codex aktivierst. Prompt Injection kann den Agenten dazu bringen, nicht vertrauenswürdige Anweisungen abzurufen und zu befolgen.

Standardeinstellungen und Empfehlungen

• Beim Start erkennt Codex, ob der Ordner unter Versionskontrolle steht, und empfiehlt:
  • Ordner unter Versionskontrolle: Auto (Workspace-Schreibzugriff + Genehmigungen auf Anfrage)
  • Ordner ohne Versionskontrolle: read-only
• Je nach Setup startet Codex möglicherweise auch im Modus read-only, bis du das Arbeitsverzeichnis ausdrücklich als vertrauenswürdig einstufst, etwa über eine Abfrage beim ersten Start oder über /permissions.
• Der Workspace umfasst das aktuelle Verzeichnis und temporäre Verzeichnisse wie /tmp. Mit dem Befehl /status siehst du, welche Verzeichnisse zum Workspace gehören.
• Führe codex aus, um die Standardeinstellungen zu übernehmen.
• Du kannst diese Einstellungen auch explizit festlegen:
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

Geschützte Pfade in Stammverzeichnissen mit Schreibzugriff

Auch bei der standardmäßigen Sandbox-Richtlinie workspace-write enthalten Stammverzeichnisse mit Schreibzugriff geschützte Pfade:

• <writable_root>/.git ist vor Schreibzugriff geschützt, unabhängig davon, ob es sich um ein Verzeichnis oder eine Datei handelt.
• Wenn <writable_root>/.git eine Verweisdatei (gitdir: ...) ist, ist auch der aufgelöste Pfad zum Git-Verzeichnis vor Schreibzugriff geschützt.
• <writable_root>/.agents ist vor Schreibzugriff geschützt, wenn es als Verzeichnis vorhanden ist.
• <writable_root>/.codex ist vor Schreibzugriff geschützt, wenn es als Verzeichnis vorhanden ist.
• Der Schutz gilt rekursiv. Damit ist auch alles unterhalb dieser Pfade vor Schreibzugriff geschützt.

Ohne Genehmigungsabfragen ausführen

Mit --ask-for-approval never oder der Kurzform -a never kannst du Genehmigungsabfragen deaktivieren.

Diese Option funktioniert mit allen --sandbox-Modi. Du bestimmst also weiterhin, wie autonom Codex arbeitet. Codex versucht, innerhalb der von dir gesetzten Grenzen das bestmögliche Ergebnis zu erzielen.

Wenn Codex ohne Genehmigungsabfragen Dateien lesen, Änderungen vornehmen und Befehle mit Netzwerkzugriff ausführen soll, verwende --sandbox danger-full-access oder das Flag --dangerously-bypass-approvals-and-sandbox. Wäge diesen Schritt sorgfältig ab.

Als Mittelweg kannst du mit approval_policy = { granular = { ... } } bestimmte Kategorien von Genehmigungsabfragen interaktiv belassen und andere automatisch ablehnen lassen. Die granulare Richtlinie umfasst Sandbox-Genehmigungen, Abfragen aufgrund von execpolicy-Regeln, MCP-Abfragen, request_permissions-Abfragen und Genehmigungen für Skill-Skripte.

Automatische Überprüfung von Genehmigungsanfragen

Standardmäßig werden Genehmigungsanfragen an dich weitergeleitet:

approvals_reviewer = "user"

Genehmigungsanfragen werden automatisch überprüft, wenn Genehmigungen interaktiv sind, etwa bei approval_policy = "on-request" oder einer granularen Genehmigungsrichtlinie. Lege approvals_reviewer = "auto_review" fest, um geeignete Genehmigungsanfragen durch einen Prüfagenten prüfen zu lassen, bevor Codex die angeforderte Aktion ausführt:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Informationen zum vollständigen Lebenszyklus des Prüfagenten, den Auslösebedingungen, der Rangfolge der Konfiguration und dem Verhalten bei Fehlern findest du unter Automatische Überprüfung.

Der Prüfagent bewertet nur Aktionen, die ohnehin eine Genehmigung erfordern, etwa das Verlassen der Sandbox, blockierte Netzwerkanfragen, request_permissions-Abfragen oder App- und MCP-Tool-Aufrufe mit Seiteneffekten. Aktionen innerhalb der Sandbox werden weiterhin ohne zusätzlichen Prüfschritt ausgeführt.

Die Prüfrichtlinie prüft auf Datenexfiltration, das Ausforschen von Zugangsdaten, dauerhafte Schwächungen der Sicherheit und destruktive Aktionen. Aktionen mit niedrigem und mittlerem Risiko können ausgeführt werden, wenn die Richtlinie sie erlaubt. Aktionen mit kritischem Risiko lehnt die Richtlinie ab. Aktionen mit hohem Risiko erfordern eine ausreichende Autorisierung durch die nutzende Person. Außerdem darf keine zutreffende Sperrregel vorliegen. Bei Fehlern beim Erstellen des Prompts, in der Prüfsitzung oder beim Parsen bleibt die Aktion gesperrt. Zeitüberschreitungen werden separat angezeigt, die Aktion wird aber auch dann nicht ausgeführt.

Die Standard-Prüfrichtlinie findest du im Open-Source-Repository von Codex. Unternehmen können den mandantenspezifischen Abschnitt über guardian_policy_config in den verwalteten Vorgaben ersetzen. Lokal hinterlegter Text in [auto_review].policy wird ebenfalls unterstützt, doch die verwalteten Vorgaben haben Vorrang. Details zum Setup findest du unter Verwaltete Konfiguration.

In der ChatGPT-Desktop-App erscheinen diese Überprüfungen als Einträge zur automatischen Überprüfung mit einem Status wie „Wird überprüft“, „Genehmigt“, „Abgelehnt“, „Abgebrochen“ oder „Zeitüberschreitung“. Sie können auch eine Risikostufe und eine Bewertung der Autorisierung durch die nutzende Person für die überprüfte Anfrage enthalten.

Die automatische Überprüfung verwendet zusätzliche Modellaufrufe und kann daher die Codex-Nutzung erhöhen. Admins können sie mit allowed_approvals_reviewers einschränken.

Gängige Kombinationen aus Sandbox und Genehmigungsrichtlinie

Verwende für nicht interaktive Ausführungen codex exec --sandbox workspace-write. Ältere Aufrufe mit codex exec --full-auto unterstützt Codex aus Kompatibilitätsgründen weiterhin, kennzeichnet sie jedoch als veraltet und gibt eine Warnung aus.

Konfiguration in config.toml

Weitere Informationen zur Konfiguration findest du unter Grundlagen der Konfiguration, Erweiterte Konfiguration und in der Konfigurationsreferenz.

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

# Optional: granular approval policy
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

Du kannst Voreinstellungen auch als Profildateien speichern und anschließend mit codex --profile profile-name auswählen:

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

Sandbox lokal testen

Mit diesen Befehlen der Codex CLI kannst du testen, was passiert, wenn ein Befehl in der Codex-Sandbox ausgeführt wird:

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

Der Befehl sandbox ist auch als codex debug verfügbar. Für die plattformspezifischen Hilfsbefehle gibt es ebenfalls Aliase, zum Beispiel codex sandbox seatbelt und codex sandbox landlock.

Sandbox auf Betriebssystemebene

Codex setzt die Sandbox je nach Betriebssystem unterschiedlich durch:

• macOS verwendet Seatbelt-Richtlinien und führt Befehle über sandbox-exec mit einem Profil (-p) aus, das dem von dir gewählten --sandbox-Modus entspricht. Wenn beim eingeschränkten Lesezugriff die Plattformstandards aktiviert sind, ergänzt Codex eine gezielt zusammengestellte macOS-Plattformrichtlinie, um die Kompatibilität mit gängigen Tools zu erhalten, statt den Zugriff auf /System pauschal zu erlauben.
• Linux verwendet standardmäßig bwrap zusammen mit seccomp.
• Unter Windows wird bei der Ausführung in Windows Subsystem for Linux 2 (WSL2) die Linux-Sandbox-Implementierung verwendet. WSL1 wurde bis einschließlich Codex 0.114 unterstützt. Ab 0.115 wurde die Linux-Sandbox auf bwrap umgestellt, sodass WSL1 nicht mehr unterstützt wird. Bei nativer Ausführung unter Windows verwendet Codex eine Implementierung der Windows-Sandbox.

Die Codex IDE-Erweiterung unterstützt unter Windows WSL2 direkt. Lege in deinen VS Code-Einstellungen Folgendes fest, damit der Agent innerhalb von WSL2 bleibt, sobald es verfügbar ist:

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Damit verwendet die IDE-Erweiterung für Befehle, Genehmigungen und Dateisystemzugriffe die Regeln der Linux-Sandbox, auch wenn das Host-Betriebssystem Windows ist. Weitere Informationen findest du in der WSL-Anleitung.

Wenn du Codex nativ unter Windows ausführst, konfiguriere den nativen Sandbox-Modus in config.toml:

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

Details findest du in der Setup-Anleitung für Windows.

Wenn du Linux in einer containerisierten Umgebung wie Docker ausführst, funktioniert die Sandbox möglicherweise nicht, wenn die Host- oder Containerkonfiguration die von Codex benötigten Namespace-Operationen, die Ausführung von bwrap mit setuid oder seccomp-Operationen blockiert.

Konfiguriere in diesem Fall deinen Docker-Container so, dass er die benötigte Isolation bietet. Führe anschließend codex mit --sandbox danger-full-access (oder dem Flag --dangerously-bypass-approvals-and-sandbox) innerhalb des Containers aus.

Codex in Dev Containers ausführen

Wenn dein Host die Linux-Sandbox nicht direkt ausführen kann oder deine Organisation bereits standardmäßig containerisiert entwickelt, führe Codex mit Dev Containers aus und nutze Docker für die äußere Isolation. Das funktioniert mit Visual Studio Code Dev Containers und kompatiblen Tools.

Verwende das Beispiel für einen sicheren Codex-Devcontainer als Referenzimplementierung. Das Beispiel installiert Codex, gängige Entwicklungstools, bubblewrap und Firewall-basierte Kontrollen für ausgehende Verbindungen.

Die Referenzimplementierung umfasst:

• ein Basis-Image mit Ubuntu 24.04, auf dem Codex und gängige Entwicklungstools installiert sind;
• ein Firewall-Profil mit einer Positivliste für ausgehende Verbindungen;
• VS Code-Einstellungen und Empfehlungen für Erweiterungen, um den Workspace in einem Container erneut zu öffnen;
• persistente Mounts für den Befehlsverlauf und die Codex-Konfiguration;
• bubblewrap, damit Codex weiterhin seine Linux-Sandbox verwenden kann, wenn der Container die erforderlichen Linux-Capabilities gewährt.

So probierst du es aus:

1. Installiere Visual Studio Code und die Erweiterung Dev Containers.
2. Kopiere das .devcontainer-Setup aus dem Codex-Beispiel in dein Repository oder verwende direkt das Codex-Repository als Ausgangspunkt.
3. Führe in VS Code Dev Containers: Open Folder in Container... aus und wähle .devcontainer/devcontainer.secure.json aus.
4. Öffne nach dem Start des Containers ein Terminal und führe codex aus.

Du kannst den Container auch über die CLI starten:

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

Das Beispiel besteht aus drei Hauptbestandteilen:

• .devcontainer/devcontainer.secure.json steuert Containereinstellungen, Linux-Capabilities, Mounts, Umgebungsvariablen und VS Code-Erweiterungen.
• .devcontainer/Dockerfile.secure definiert das Ubuntu-basierte Image und die installierten Tools.
• .devcontainer/init-firewall.sh wendet die Netzwerkrichtlinie für ausgehende Verbindungen an.

Die Referenz-Firewall ist bewusst als Ausgangspunkt gedacht. Wenn deine Isolation von einer Positivliste für Domains abhängt, implementiere für deine Umgebung geeignete Schutzmaßnahmen gegen DNS-Rebinding und Risiken bei DNS-Aktualisierungen, etwa Aktualisierungen, die die TTL berücksichtigen, oder eine DNS-fähige Firewall.

Wähle innerhalb des Containers einen dieser Modi:

• Lass die Linux-Sandbox von Codex aktiviert, wenn das Dev-Container-Profil die Linux-Capabilities gewährt, die bwrap zum Erstellen der inneren Sandbox benötigt.
• Wenn der Container die vorgesehene Sicherheitsgrenze bildet, führe Codex innerhalb des Containers mit --sandbox danger-full-access aus, damit Codex nicht versucht, eine zweite Sandbox-Ebene zu erstellen.

Versionsverwaltung

Codex funktioniert am besten mit einem Arbeitsablauf, der Versionsverwaltung nutzt:

• Arbeite auf einem Feature-Branch und stelle vor dem Delegieren sicher, dass git status einen sauberen Arbeitsstand anzeigt. So lassen sich Codex-Patches leichter isolieren und rückgängig machen.
• Bevorzuge Arbeitsabläufe mit Patches (zum Beispiel git diff/git apply), statt versionierte Dateien direkt zu bearbeiten. Erstelle häufig Commits, damit du Änderungen in kleinen Schritten rückgängig machen kannst.
• Behandle Codex-Vorschläge wie jeden anderen PR: Führe gezielte Prüfungen durch, überprüfe Diffs und dokumentiere Entscheidungen in Commit-Nachrichten, damit sie bei Audits nachvollziehbar sind.

Monitoring und Telemetrie

Codex unterstützt optionales Monitoring über OpenTelemetry (OTel). Damit können Teams die Nutzung auditieren, Probleme untersuchen und Compliance-Anforderungen erfüllen, ohne die lokalen Sicherheitsstandards abzuschwächen. Telemetrie ist standardmäßig deaktiviert; aktiviere sie ausdrücklich in deiner Konfiguration.

Übersicht

• Codex deaktiviert den OTel-Export standardmäßig, damit lokale Ausführungen in sich geschlossen bleiben.
• Wenn der Export aktiviert ist, gibt Codex strukturierte Protokollereignisse zu Chats, API-Anfragen, SSE/WebSocket-Stream-Aktivitäten, Nutzereingaben (standardmäßig unkenntlich gemacht), Entscheidungen über Tool-Genehmigungen und Tool-Ergebnissen aus.
• Codex kennzeichnet exportierte Ereignisse mit service.name (Ursprung), der CLI-Version und einer Umgebungsbezeichnung, um den Datenverkehr von Entwicklung, Staging und Produktion zu unterscheiden.

OTel aktivieren (optional)

Füge deiner Codex-Konfiguration (normalerweise ~/.codex/config.toml) einen [otel]-Block hinzu. Wähle dabei einen Exporter und lege fest, ob der Prompt-Text protokolliert werden soll.

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• Mit exporter = "none" bleibt die Instrumentierung aktiv, es werden aber keine Daten gesendet.
• Um Ereignisse an deinen eigenen Collector zu senden, wähle eine der folgenden Optionen:

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

Codex bündelt Ereignisse und sendet die noch ausstehenden beim Beenden. Codex exportiert ausschließlich Telemetriedaten, die sein OTel-Modul erzeugt.

Ereigniskategorien

Typische Ereignistypen sind:

• codex.conversation_starts (Modell, Einstellungen zum Reasoning-Aufwand, Sandbox- und Genehmigungsrichtlinie)
• codex.api_request (Versuch, Status/Erfolg, Dauer und Fehlerdetails)
• codex.sse_event (Art des Stream-Ereignisses, Erfolg/Fehlschlag, Dauer sowie Token-Anzahlen bei response.completed)
• codex.websocket_request und codex.websocket_event (Anfragedauer sowie Art/Erfolg/Fehler pro Nachricht)
• codex.user_prompt (Länge; der Inhalt wird unkenntlich gemacht, sofern seine Protokollierung nicht ausdrücklich aktiviert wurde)
• codex.tool_decision (genehmigt/abgelehnt, Quelle: Konfiguration oder nutzende Person)
• codex.tool_result (Dauer, Erfolg, Ausgabeausschnitt)

Zu den zugehörigen OTel-Metriken (jeweils ein Zähler und ein Histogramm für die Dauer) gehören codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event und codex.tool.call (mit entsprechenden .duration_ms-Instrumenten).

Den vollständigen Ereigniskatalog und die Konfigurationsreferenz findest du in der Dokumentation zur Codex-Konfiguration auf GitHub.

Hinweise zu Sicherheit und Datenschutz

• Behalte log_user_prompt = false bei, sofern die Richtlinie das Speichern von Prompt-Inhalten nicht ausdrücklich erlaubt. Prompts können Quellcode und sensible Daten enthalten.
• Sende Telemetriedaten nur an Collectors, die du kontrollierst. Lege Aufbewahrungsfristen und Zugriffskontrollen entsprechend deinen Compliance-Anforderungen fest.
• Behandle Tool-Argumente und -Ausgaben als sensible Daten. Mache sensible Inhalte nach Möglichkeit im Collector oder SIEM unkenntlich.
• Prüfe die lokalen Einstellungen zur Datenaufbewahrung (zum Beispiel history.persistence / history.max_bytes), wenn Codex keine Sitzungsprotokolle unter CODEX_HOME speichern soll. Siehe Erweiterte Konfiguration und Konfigurationsreferenz.
• Wenn du die CLI mit deaktiviertem Netzwerkzugriff ausführst, kann der OTel-Export deinen Collector nicht erreichen. Erlaube für den Export im Modus workspace-write den Netzwerkzugriff auf den OTel-Endpunkt. Alternativ kannst du aus Codex Cloud exportieren, wenn die Domain des Collectors auf deiner Freigabeliste steht.
• Prüfe die Ereignisse regelmäßig auf Änderungen an Genehmigungen oder der Sandbox sowie auf unerwartete Tool-Ausführungen.

OTel ist optional und ergänzt die oben beschriebenen Schutzmechanismen durch Sandbox und Genehmigungen, ersetzt sie aber nicht.

Verwaltete Konfiguration

Admins in Unternehmen können unter Verwaltete Konfiguration die Codex-Sicherheitseinstellungen für ihren Workspace konfigurieren. Auf dieser Seite findest du Details zum Setup und zu den Richtlinien.