Agentengenehmigungen und Sicherheit

Codex trägt dazu bei, Ihren Code und Ihre Daten zu schützen und das Missbrauchsrisiko zu verringern.

Standardmäßig wird der Agent mit deaktiviertem Netzwerkzugriff ausgeführt. Lokal verwendet Codex eine vom Betriebssystem erzwungene Sandbox, die den Zugriff einschränkt (normalerweise auf den aktuellen Arbeitsbereich), sowie eine Genehmigungsrichtlinie, die festlegt, wann Codex vor einer Aktion anhalten und Sie um Zustimmung bitten muss.

Eine allgemeine Erklärung zur Funktionsweise des Sandboxings in der ChatGPT-Desktop-App, der Codex CLI und der IDE-Erweiterung finden Sie unter Sandboxing. Einen umfassenderen Überblick über die Sicherheit in Unternehmen finden Sie im Codex-Sicherheits-Whitepaper.

Sandbox und Genehmigungen

Die Sicherheitssteuerungen von Codex bestehen aus zwei zusammenwirkenden Ebenen:

• Sandbox-Modus: Was Codex technisch tun kann (beispielsweise, wo es schreiben und ob es auf das Netzwerk zugreifen kann), wenn es vom Modell generierte Befehle ausführt.
• Genehmigungsrichtlinie: Wann Codex Sie um Zustimmung bitten muss, bevor es eine Aktion ausführt (beispielsweise die Sandbox verlässt, das Netzwerk verwendet oder Befehle außerhalb einer vertrauenswürdigen Gruppe ausführt).

Codex verwendet je nach Ausführungsort unterschiedliche Sandbox-Modi:

• Codex Cloud: Wird in isolierten, von OpenAI verwalteten Containern ausgeführt, wodurch der Zugriff auf Ihr Hostsystem oder nicht zugehörige Daten verhindert wird. Verwendet ein zweiphasiges Laufzeitmodell: Die Einrichtung erfolgt vor der Agentenphase und kann auf das Netzwerk zugreifen, um angegebene Abhängigkeiten zu installieren. Anschließend wird die Agentenphase standardmäßig offline ausgeführt, sofern Sie für diese Umgebung keinen Internetzugriff aktivieren. Für Cloud-Umgebungen konfigurierte Geheimnisse sind nur während der Einrichtung verfügbar und werden vor Beginn der Agentenphase entfernt.
• Codex CLI / IDE-Erweiterung: Mechanismen auf Betriebssystemebene erzwingen die Sandbox-Richtlinien. Zu den Standardeinstellungen gehören kein Netzwerkzugriff und auf den aktiven Arbeitsbereich beschränkte Schreibberechtigungen. Sie können Sandbox, Genehmigungsrichtlinie und Netzwerkeinstellungen entsprechend Ihrer Risikotoleranz konfigurieren.

In der Voreinstellung Auto (beispielsweise --sandbox workspace-write --ask-for-approval on-request) kann Codex automatisch Dateien lesen, Änderungen vornehmen und Befehle im Arbeitsverzeichnis ausführen.

Codex bittet um Genehmigung, wenn Dateien außerhalb des Arbeitsbereichs bearbeitet oder Befehle ausgeführt werden sollen, die Netzwerkzugriff benötigen. Wenn Sie chatten oder planen möchten, ohne Änderungen vorzunehmen, wechseln Sie mit dem Befehl /permissions in den Modus read-only.

Codex kann auch eine Genehmigung für Toolaufrufe von Apps (Connectors) einholen, die auf Nebenwirkungen hinweisen, selbst wenn die Aktion kein Shell-Befehl und keine Dateiänderung ist. Destruktive App-/MCP-Toolaufrufe erfordern immer eine Genehmigung, wenn das Tool eine destruktive Annotation ausweist, selbst wenn es zugleich andere Hinweise ausweist (beispielsweise Hinweise auf einen schreibgeschützten Zugriff).

Netzwerkzugriff

Informationen dazu, wie Sie für Codex Cloud vollständigen Internetzugriff oder eine Domain-Zulassungsliste aktivieren, finden Sie unter Internetzugriff für Agenten.

Bei der ChatGPT-Desktop-App, der Codex CLI oder der IDE-Erweiterung bleibt der Netzwerkzugriff im standardmäßigen Sandbox-Modus workspace-write deaktiviert, sofern Sie ihn nicht in Ihrer Konfiguration aktivieren:

[sandbox_workspace_write]
network_access = true

Netzwerkisolation

Der Netzwerkzugriff wird durch Zielregeln gesteuert, die für Skripte, Programme und von Befehlen gestartete Unterprozesse gelten. Wenn der Netzwerkzugriff für Befehle bereits aktiviert ist, aktivieren Sie die Funktion network_proxy, um diesen Datenverkehr auf die von Ihnen konfigurierte Netzwerkrichtlinie zu beschränken.

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

Verwenden Sie für eine einmalige CLI-Sitzung die boolesche Kurzform, wenn Sie nur die Umschaltung benötigen, und die Tabellenform, wenn Sie außerdem Richtlinienoptionen festlegen:

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 der aktivierte Netzwerkzugriff durchgesetzt wird; sie gewährt nicht von sich aus Netzwerkzugriff. Verwenden Sie sandbox_workspace_write.network_access mit der Konfiguration workspace-write, um festzulegen, ob Befehle überhaupt Netzwerkzugriff haben:

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

Von Administratoren verwaltete Anforderungen für experimental_network sind von der benutzerseitigen Funktionsumschaltung getrennt. Sie können Sandbox-Netzwerke ohne features.network_proxy konfigurieren und starten, aktivieren jedoch keinen Netzwerkzugriff, wenn die aktive Sandbox ihn deaktiviert lässt. Informationen zum administratorseitigen Format von requirements.toml finden Sie unter Verwaltete Konfiguration.

Netzwerkrichtlinie

Domainregeln folgen dem Prinzip „Zulassungsliste zuerst“:

• Exakte Hosts stimmen nur mit sich selbst überein.
• *.example.com stimmt mit Subdomains wie api.example.com überein, jedoch nicht mit example.com.
• **.example.com stimmt sowohl mit der Apex-Domain als auch mit Subdomains überein.
• Eine globale Zulassungsregel * stimmt mit jedem öffentlichen Host überein, der nicht abgelehnt wird. Behandeln Sie * als umfassenden Netzwerkzugriff und bevorzugen Sie nach Möglichkeit enger begrenzte Regeln.
• deny hat immer Vorrang vor allow, und das globale * ist nur für Zulassungsregeln gültig.

Lokale und private Ziele

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

• Spezifische Ausnahmen: Fügen Sie ein exaktes lokales IP-Literal oder eine Zulassungsregel localhost hinzu, wenn ein Befehl ein bestimmtes lokales Ziel benötigt.
• Umfassenderer Zugriff: Legen Sie allow_local_binding = true nur fest, wenn Sie bewusst einen breiteren lokalen/privaten Zugriff wünschen.
• Platzhalter: Platzhalterregeln gelten nicht als explizite lokale Ausnahmen.
• Aufgelöste Adressen: Hostnamen, die in lokale/private IP-Adressen aufgelöst werden, bleiben blockiert, selbst wenn sie mit der Zulassungsliste übereinstimmen.

Schutz vor DNS-Rebinding

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

• Fehlgeschlagene oder wegen Zeitüberschreitung abgebrochene Abfragen werden blockiert.
• Hostnamen, die in nicht öffentliche Adressen aufgelöst werden, werden blockiert.
• Die Prüfung verringert das Risiko von DNS-Rebinding, beseitigt es jedoch nicht. Um Rebinding vollständig zu verhindern, müssten die aufgelösten IP-Adressen in der Transportschicht festgeschrieben werden.

Wenn feindseliges DNS zu Ihrem Bedrohungsmodell gehört, erzwingen Sie ausgehende Zugriffskontrollen auch auf einer tieferen Ebene.

Gefährliche Einstellungen

Zwei Einstellungen erweitern bewusst die Vertrauensgrenze:

• dangerously_allow_non_loopback_proxy = true kann Proxy-Listener über Loopback hinaus verfügbar machen.
• dangerously_allow_all_unix_sockets = true umgeht die Zulassungsliste für Unix-Sockets.

Verwenden Sie diese Einstellungen nur in streng kontrollierten Umgebungen. Wenn Unix-Socket-Proxying aktiviert ist, bleiben Listener auf Loopback beschränkt, selbst wenn eine Bindung außerhalb von Loopback angefordert wurde, sodass das Sandbox-Netzwerk nicht zu einer Remote-Brücke zu lokalen Daemons wird.

network_proxy ist standardmäßig deaktiviert. Wenn Sie es aktivieren:

Sie können auch das Websuchtool steuern, ohne gestarteten Befehlen vollständigen Netzwerkzugriff zu gewähren. Codex verwendet standardmäßig einen Websuchcache, um auf Ergebnisse zuzugreifen. Der Cache ist ein von OpenAI gepflegter Index von Webergebnissen, sodass der Cachemodus vorab indexierte Ergebnisse zurückgibt, anstatt Live-Seiten abzurufen. Dadurch verringert sich die Anfälligkeit für Prompt-Injection durch beliebige Live-Inhalte, dennoch sollten Sie Webergebnisse weiterhin als nicht vertrauenswürdig behandeln. Wenn Sie --yolo oder eine andere Sandbox-Einstellung mit vollständigem Zugriff verwenden, liefert die Websuche standardmäßig Live-Ergebnisse. Verwenden Sie --search oder legen Sie web_search = "live" fest, um Live-Browsing zuzulassen, oder legen Sie den Wert auf "disabled" fest, um das Tool zu deaktivieren:

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

Legen Sie web_search = "indexed" fest, wenn der externe Webzugriff durch den Suchindex eingeschränkt werden soll. Seien Sie vorsichtig, wenn Sie Netzwerkzugriff oder die Websuche in Codex aktivieren. Prompt-Injection kann dazu führen, dass der Agent nicht vertrauenswürdige Anweisungen abruft und befolgt.

Standardeinstellungen und Empfehlungen

• Beim Start erkennt Codex, ob der Ordner versionsverwaltet ist, und empfiehlt:
  • Versionsverwaltete Ordner: Auto (Schreibzugriff auf den Arbeitsbereich + Genehmigungen auf Anfrage)
  • Nicht versionsverwaltete Ordner: read-only
• Abhängig von Ihrer Einrichtung kann Codex auch im Modus read-only starten, bis Sie dem Arbeitsverzeichnis ausdrücklich vertrauen (beispielsweise über eine Onboarding-Eingabeaufforderung oder /permissions).
• Der Arbeitsbereich umfasst das aktuelle Verzeichnis und temporäre Verzeichnisse wie /tmp. Verwenden Sie den Befehl /status, um zu sehen, welche Verzeichnisse zum Arbeitsbereich gehören.
• Führen Sie codex aus, um die Standardeinstellungen zu übernehmen.
• Sie können diese Werte ausdrücklich festlegen:
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

Geschützte Pfade in beschreibbaren Stammverzeichnissen

In der standardmäßigen Sandbox-Richtlinie workspace-write enthalten beschreibbare Stammverzeichnisse weiterhin geschützte Pfade:

• <writable_root>/.git ist schreibgeschü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 schreibgeschützt.
• <writable_root>/.agents ist schreibgeschützt, wenn es als Verzeichnis vorhanden ist.
• <writable_root>/.codex ist schreibgeschützt, wenn es als Verzeichnis vorhanden ist.
• Der Schutz gilt rekursiv, sodass alle Inhalte unter diesen Pfaden schreibgeschützt sind.

Ohne Genehmigungsaufforderungen ausführen

Sie können Genehmigungsaufforderungen mit --ask-for-approval never oder -a never (Kurzform) deaktivieren.

Diese Option funktioniert mit allen --sandbox-Modi, sodass Sie weiterhin den Grad der Autonomie von Codex steuern. Codex bemüht sich nach besten Kräften, innerhalb der von Ihnen festgelegten Einschränkungen zu arbeiten.

Wenn Codex ohne Genehmigungsaufforderungen Dateien lesen, Änderungen vornehmen und Befehle mit Netzwerkzugriff ausführen soll, verwenden Sie --sandbox danger-full-access (oder das Flag --dangerously-bypass-approvals-and-sandbox). Gehen Sie dabei mit Bedacht vor.

Als Mittelweg können Sie mit approval_policy = { granular = { ... } } bestimmte Kategorien von Genehmigungsaufforderungen interaktiv halten und andere automatisch ablehnen. Die granulare Richtlinie deckt Sandbox-Genehmigungen, Aufforderungen aufgrund von execpolicy-Regeln, MCP-Aufforderungen, request_permissions-Aufforderungen und Genehmigungen für Skill-Skripte ab.

Automatische Genehmigungsprüfungen

Standardmäßig werden Genehmigungsanfragen an Sie weitergeleitet:

approvals_reviewer = "user"

Automatische Genehmigungsprüfungen werden angewendet, wenn Genehmigungen interaktiv sind, etwa bei approval_policy = "on-request" oder einer granularen Genehmigungsrichtlinie. Legen Sie approvals_reviewer = "auto_review" fest, um geeignete Genehmigungsanfragen von einem Prüfagenten prüfen zu lassen, bevor Codex die Anfrage ausführt:

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

Den vollständigen Lebenszyklus der Prüfung, die Auslösebedingungen, die Rangfolge der Konfiguration und das Verhalten bei Fehlern finden Sie unter Automatische Prüfung.

Der Prüfagent bewertet ausschließlich Aktionen, die bereits eine Genehmigung erfordern, etwa Sandbox- Eskalationen, blockierte Netzwerkanfragen, request_permissions-Aufforderungen oder App- und MCP-Tool-Aufrufe mit Nebenwirkungen. Aktionen, die innerhalb der Sandbox bleiben, werden weiterhin ohne zusätzlichen Prüfschritt ausgeführt.

Die Richtlinie des Prüfagenten prüft auf Datenexfiltration, das Ausspähen von Anmeldedaten, dauerhafte Abschwächungen der Sicherheit und destruktive Aktionen. Aktionen mit niedrigem und mittlerem Risiko können ausgeführt werden, wenn die Richtlinie dies zulässt. Aktionen mit kritischem Risiko werden von der Richtlinie abgelehnt. Aktionen mit hohem Risiko erfordern eine ausreichende Benutzerautorisierung und dürfen keiner Ablehnungsregel entsprechen. Fehler bei der Prompt-Erstellung, in der Prüfsitzung oder bei der Auswertung führen zur Ablehnung. Zeitüberschreitungen werden gesondert ausgewiesen, die Aktion wird jedoch auch in diesem Fall nicht ausgeführt.

Die Standardrichtlinie des Prüfagenten befindet sich im Open-Source-Repository von Codex. Unternehmen können deren mandantenspezifischen Abschnitt in verwalteten Anforderungen durch guardian_policy_config ersetzen. Lokaler [auto_review].policy-Text wird ebenfalls unterstützt, verwaltete Anforderungen haben jedoch Vorrang. Einzelheiten zur Einrichtung finden Sie unter Verwaltete Konfiguration.

In der ChatGPT-Desktop-App erscheinen diese Prüfungen als automatische Prüfeinträge mit einem Status wie „Wird geprüft“, „Genehmigt“, „Abgelehnt“, „Abgebrochen“ oder „Zeitüberschreitung“. Sie können außerdem eine Risikostufe und eine Bewertung der Benutzerautorisierung für die geprüfte Anfrage enthalten.

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

Häufige Kombinationen von Sandbox und Genehmigungen

Verwenden Sie für nicht interaktive Ausführungen codex exec --sandbox workspace-write. Codex behält ältere Aufrufe mit codex exec --full-auto als veralteten Kompatibilitätspfad bei und gibt eine Warnung aus.

Mit --ask-for-approval untrusted führt Codex nur bekanntermaßen sichere Lesevorgänge automatisch aus. Befehle, die den Zustand verändern oder externe Ausführungspfade auslösen können (beispielsweise destruktive Git-Operationen oder Flags zum Überschreiben der Git-Ausgabe beziehungsweise -Konfiguration), erfordern eine Genehmigung.

Konfiguration in config.toml

Den umfassenderen Konfigurationsablauf finden Sie unter Konfigurationsgrundlagen, Erweiterte Konfiguration und in der Konfigurationsreferenz.

# Always ask for approval mode
approval_policy = "untrusted"
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
# } }

Sie können Voreinstellungen auch als Profildateien speichern und sie 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

Um zu sehen, was geschieht, wenn ein Befehl in der Codex-Sandbox ausgeführt wird, verwenden Sie diese Codex CLI-Befehle:

# 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, und die plattformspezifischen Hilfsprogramme besitzen Aliasse (beispielsweise 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 mithilfe von sandbox-exec mit einem Profil (-p) aus, das dem von Ihnen ausgewählten --sandbox-Modus entspricht. Wenn eingeschränkter Lesezugriff die Plattformstandards aktiviert, fügt Codex eine kuratierte macOS-Plattformrichtlinie hinzu (anstatt /System pauschal zuzulassen), um die Kompatibilität mit gängigen Tools zu gewährleisten.
• Linux verwendet standardmäßig bwrap zusammen mit seccomp.
• Windows verwendet die Linux-Sandbox-Implementierung, wenn es unter Windows Subsystem for Linux 2 (WSL2) ausgeführt wird. 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 Windows-Sandbox-Implementierung.

Wenn Sie die Codex IDE-Erweiterung unter Windows verwenden, unterstützt sie WSL2 direkt. Legen Sie in Ihren VS Code-Einstellungen Folgendes fest, damit der Agent nach Möglichkeit innerhalb von WSL2 bleibt:

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Dadurch übernimmt die IDE-Erweiterung die Linux-Sandbox-Semantik für Befehle, Genehmigungen und Dateisystemzugriffe, selbst wenn das Host-Betriebssystem Windows ist. Weitere Informationen finden Sie im WSL-Leitfaden.

Konfigurieren Sie bei nativer Ausführung unter Windows den nativen Sandbox-Modus in config.toml:

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

Einzelheiten finden Sie im Leitfaden zur Einrichtung unter Windows.

Wenn Sie Linux in einer containerisierten Umgebung wie Docker ausführen, funktioniert die Sandbox möglicherweise nicht, falls die Host- oder Containerkonfiguration den Namespace, setuid-bwrap- oder seccomp-Operationen blockiert, die Codex benötigt.

Konfigurieren Sie in diesem Fall Ihren Docker-Container so, dass er die erforderliche Isolation bereitstellt, und führen Sie 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 Ihr Host die Linux-Sandbox nicht direkt ausführen kann oder Ihre Organisation bereits auf containerisierte Entwicklung standardisiert ist, führen Sie Codex mit Dev Containers aus und lassen Sie Docker die äußere Isolationsgrenze bereitstellen. Dies funktioniert mit Visual Studio Code Dev Containers und kompatiblen Tools.

Verwenden Sie das Beispiel für einen sicheren Codex-Devcontainer als Referenzimplementierung. Das Beispiel installiert Codex, gängige Entwicklungswerkzeuge, bubblewrap und Firewall-basierte Kontrollen für ausgehenden Datenverkehr.

Die Referenzimplementierung umfasst:

• ein Ubuntu-24.04-Basis-Image, auf dem Codex und gängige Entwicklungswerkzeuge installiert sind;
• ein auf einer Zulassungsliste basierendes Firewall-Profil für ausgehende Zugriffe;
• VS Code-Einstellungen und Erweiterungsempfehlungen zum erneuten Öffnen des Workspace in einem Container;
• persistente Mounts für den Befehlsverlauf und die Codex-Konfiguration;
• bubblewrap, damit Codex weiterhin seine Linux-Sandbox verwenden kann, wenn der Container die erforderlichen Berechtigungen gewährt.

So probieren Sie es aus:

1. Installieren Sie Visual Studio Code und die Dev Containers-Erweiterung.
2. Kopieren Sie die beispielhafte .devcontainer-Konfiguration von Codex in Ihr Repository oder beginnen Sie direkt mit dem Codex-Repository.
3. Führen Sie in VS Code Dev Containers: Open Folder in Container... aus und wählen Sie .devcontainer/devcontainer.secure.json aus.
4. Öffnen Sie nach dem Start des Containers ein Terminal und führen Sie codex aus.

Sie können den Container auch über die CLI starten:

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

Das Beispiel besteht aus drei Hauptkomponenten:

• .devcontainer/devcontainer.secure.json steuert Container-Einstellungen, Berechtigungen, Mounts, Umgebungsvariablen und VS Code-Erweiterungen.
• .devcontainer/Dockerfile.secure definiert das Ubuntu-basierte Image und die installierten Werkzeuge.
• .devcontainer/init-firewall.sh wendet die Richtlinie für ausgehende Netzwerkverbindungen an.

Die Referenz-Firewall ist bewusst als Ausgangspunkt gedacht. Wenn Sie zur Isolation auf die Zulassungsliste für Domains angewiesen sind, implementieren Sie Schutzmaßnahmen gegen DNS-Rebinding und für die DNS-Aktualisierung, die zu Ihrer Umgebung passen, beispielsweise TTL-gesteuerte Aktualisierungen oder eine DNS-fähige Firewall.

Wählen Sie innerhalb des Containers einen dieser Modi:

• Lassen Sie die Linux-Sandbox von Codex aktiviert, wenn das Dev-Container-Profil die Berechtigungen gewährt, die bwrap zum Erstellen der inneren Sandbox benötigt.
• Wenn der Container als Ihre Sicherheitsgrenze vorgesehen ist, führen Sie Codex innerhalb des Containers mit --sandbox danger-full-access aus, damit Codex nicht versucht, eine zweite Sandbox-Ebene zu erstellen.

Versionskontrolle

Codex funktioniert am besten mit einem Versionskontroll-Workflow:

• Arbeiten Sie auf einem Feature-Branch und halten Sie git status sauber, bevor Sie Aufgaben delegieren. Dadurch lassen sich Codex-Patches leichter isolieren und rückgängig machen.
• Bevorzugen Sie Patch-basierte Workflows (beispielsweise git diff/git apply), anstatt nachverfolgte Dateien direkt zu bearbeiten. Committen Sie häufig, damit Sie Änderungen in kleinen Schritten zurücksetzen können.
• Behandeln Sie Vorschläge von Codex wie jeden anderen PR: Führen Sie gezielte Prüfungen aus, überprüfen Sie Diffs und dokumentieren Sie Entscheidungen zur Nachverfolgbarkeit in Commit-Nachrichten.

Überwachung und Telemetrie

Codex unterstützt eine optionale Überwachung über OpenTelemetry (OTel), damit Teams die Nutzung auditieren, Probleme untersuchen und Compliance-Anforderungen erfüllen können, ohne die lokalen Standardsicherheitseinstellungen abzuschwächen. Telemetrie ist standardmäßig deaktiviert; aktivieren Sie sie ausdrücklich in Ihrer Konfiguration.

Überblick

• Codex deaktiviert den OTel-Export standardmäßig, damit lokale Ausführungen in sich abgeschlossen bleiben.
• Wenn OTel aktiviert ist, gibt Codex strukturierte Protokollereignisse zu Chats, API-Anfragen, SSE-/WebSocket-Stream-Aktivitäten, Benutzer-Prompts (standardmäßig redigiert), Entscheidungen über Werkzeugfreigaben und Werkzeugergebnissen aus.
• Codex versieht exportierte Ereignisse mit service.name (Urheber), der CLI-Version und einer Umgebungskennzeichnung, um Dev-/Staging-/Prod-Datenverkehr voneinander zu trennen.

OTel aktivieren (Opt-in)

Fügen Sie Ihrer Codex-Konfiguration (üblicherweise ~/.codex/config.toml) einen [otel]-Block hinzu und wählen Sie einen Exporter sowie aus, ob 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

• exporter = "none" lässt die Instrumentierung aktiv, sendet jedoch keine Daten.
• Um Ereignisse an Ihren eigenen Collector zu senden, wählen Sie 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 fasst Ereignisse zu Batches zusammen und überträgt sie beim Beenden. Codex exportiert ausschließlich Telemetrie, die von seinem OTel-Modul erzeugt wurde.

Ereigniskategorien

Zu den repräsentativen Ereignistypen gehören:

• codex.conversation_starts (Modell, Reasoning-Einstellungen, Sandbox-/Freigaberichtlinie)
• 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 je Nachricht)
• codex.user_prompt (Länge; Inhalt redigiert, sofern er nicht ausdrücklich aktiviert wurde)
• codex.tool_decision (genehmigt/abgelehnt, Quelle: Konfiguration oder Benutzer)
• codex.tool_result (Dauer, Erfolg, Auszug der Ausgabe)

Zu den zugehörigen OTel-Metriken (jeweils Paare aus Zähler und Dauerhistogramm) gehören codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event und codex.tool.call (mit den entsprechenden .duration_ms-Instrumenten).

Den vollständigen Ereigniskatalog und die Konfigurationsreferenz finden Sie in der Codex-Konfigurationsdokumentation auf GitHub.

Hinweise zu Sicherheit und Datenschutz

• Behalten Sie log_user_prompt = false bei, sofern Ihre Richtlinie das Speichern von Prompt-Inhalten nicht ausdrücklich erlaubt. Prompts können Quellcode und sensible Daten enthalten.
• Leiten Sie Telemetriedaten ausschließlich an Collector weiter, die Sie kontrollieren; wenden Sie Aufbewahrungsfristen und Zugriffskontrollen an, die Ihren Compliance-Anforderungen entsprechen.
• Behandeln Sie Argumente und Ausgaben von Werkzeugen als sensibel. Bevorzugen Sie nach Möglichkeit eine Redigierung im Collector oder SIEM.
• Überprüfen Sie die Einstellungen zur lokalen Datenaufbewahrung (beispielsweise history.persistence / history.max_bytes), wenn Codex keine Sitzungstranskripte unter CODEX_HOME speichern soll. Weitere Informationen finden Sie unter Erweiterte Konfiguration und Konfigurationsreferenz.
• Wenn Sie die CLI mit deaktiviertem Netzwerkzugriff ausführen, kann der OTel-Export Ihren Collector nicht erreichen. Erlauben Sie für den Export im workspace-write-Modus den Netzwerkzugriff auf den OTel-Endpunkt oder exportieren Sie aus Codex cloud, wobei die Collector-Domain auf Ihrer Zulassungsliste stehen muss.
• Überprüfen Sie Ereignisse regelmäßig auf Änderungen an Freigaben oder der Sandbox sowie auf unerwartete Werkzeugausführungen.

OTel ist optional und soll die oben beschriebenen Sandbox- und Freigabeschutzmechanismen ergänzen, nicht ersetzen.

Verwaltete Konfiguration

Enterprise-Administratoren können die Sicherheitseinstellungen von Codex für ihren Workspace unter Verwaltete Konfiguration konfigurieren. Einzelheiten zur Einrichtung und zu den Richtlinien finden Sie auf dieser Seite.