Codex-Sandbox: Modi, --yolo, Docker und Cloud

Eine Codex-Sandbox begrenzt, wohin Befehle schreiben können und ob sie auf das Netzwerk zugreifen dürfen. Beginnen Sie für lokale Arbeiten mit workspace-write. Verwenden Sie --yolo nur in einer externen Sandbox, da es sowohl die Sandbox von Codex als auch die Bestätigungsaufforderungen deaktiviert.

Wir haben Codex CLI 0.162.1 unter macOS und in Docker sowie eine Codex-Aufgabe in Lizard Sandboxes getestet. Dieser Leitfaden behandelt die Ergebnisse, die wichtigen Einstellungen und die Wahl eines Setups.

Die Beispiele nutzen die getesteten Versionen. Bei unserer Quellenprüfung am 21. Oktober 2026 war 0.163.0 die neueste stabile Version. Prüfen Sie Ihre installierte Version, bevor Sie Einstellungen aus einer anderen Version übernehmen. Siehe die Release-Liste.

Was schützt die integrierte Codex-Sandbox?

Codex wendet Betriebssystembeschränkungen auf gestartete Befehle an, darunter Test-Runner, Git und Paketmanager. Diese Grenzen regeln Schreibzugriffe und den Netzwerkzugriff. MCP-Server, Konnektoren und Browser-Tools nutzen eigene Kontrollen. Die Befehlssandbox schließt nicht jedes angeschlossene Tool ein. Siehe den Sandbox-Umfang und die Tool-Kontrollen von OpenAI.

Bei unseren workspace-write-Prüfungen unter macOS gelang das Schreiben im Projekt, das Schreiben im Home-Verzeichnis scheiterte und .git/ blieb schreibgeschützt. Schreibzugriffe auf /tmp und $TMPDIR funktionierten. Auch das Lesen von ~/.zshrc gelang: workspace-write beschränkt Lesezugriffe nicht auf Ihr Projekt.

Laut Dokumentation sind auch bestehende Verzeichnisse .codex, .agents und .aws innerhalb beschreibbarer Stammverzeichnisse geschützt. Der Schutz umfasst deren Inhalte. Der Schutz von .git umfasst auch ein verknüpftes gitdir. Wir haben .git geprüft; die Angaben zu den anderen geschützten Pfaden stammen aus der Dokumentation von OpenAI.

Codex-Sandbox-Modus aktivieren

Starten Sie in Ihrem Projekt eine interaktive Sitzung mit:

codex --sandbox workspace-write --ask-for-approval on-request

Das wählt Auto: Änderungen im Arbeitsbereich und Routinebefehle dürfen laufen; weitergehender Zugriff erfordert eine Bestätigung. Interaktives Codex empfiehlt Auto für Ordner unter Versionskontrolle und sonst den schreibgeschützten Modus. Es kann schreibgeschützt starten, bis Sie dem Ordner vertrauen. codex exec läuft dagegen standardmäßig schreibgeschützt. So erlauben Sie Änderungen:

codex exec --sandbox workspace-write "<task>"

Ersetzen Sie <task> durch Ihre Anfrage. Siehe die interaktiven Standardwerte und exec-Berechtigungen. Unser Leitfaden zu codex exec behandelt skriptgesteuerte Aufgaben.

Unter macOS nutzt Codex Seatbelt. Unter Linux und WSL2 nutzt es bubblewrap zur Dateisystemisolierung und seccomp zum Filtern von Systemaufrufen. bubblewrap wurde in 0.115.0 zum Standard. Installieren Sie es unter Debian oder Ubuntu:

sudo apt install bubblewrap

Ohne bwrap im PATH kann Codex sein mitgeliefertes Hilfsprogramm verwenden. Dieses benötigt unprivilegierte Benutzer-Namespaces. Ubuntu 24.04 benötigt eventuell auch das AppArmor-Profil bwrap-userns-restrict. Beachten Sie die Voraussetzungen.

Natives Windows unterstützt MXC, die empfohlene Wahl auf unterstützten Windows 11-Builds: 24H2 Build 26100.9278 oder 25H2 Build 26200.9278 und neuer. Ältere Ausweichoptionen sind elevated und unelevated; WSL2 nutzt Linux-Sandboxing. Siehe die Windows-Anforderungen.

Netzwerk- und Schreibzugriff festlegen

Der Netzwerkzugriff ist in workspace-write zunächst aus. So aktivieren Sie ihn in Ihrer Codex-Konfiguration:

[sandbox_workspace_write]
network_access = true

Für einen einzelnen Lauf verwenden Sie -c sandbox_workspace_write.network_access=true. Unsere Netzwerkprüfung lieferte mit dieser Einstellung HTTP 200 statt eines DNS-Fehlers. Sie erlaubt ausgehenden Zugriff; Domainregeln benötigen den separaten Netzwerk-Proxy. Siehe die Netzwerkeinstellungen.

Diese Kontrollen betreffen das Netzwerk der Befehle. Modell- und Authentifizierungsanfragen von Codex nutzen einen eigenen Weg. Eine blockierte curl-Anfrage heißt daher nicht, dass die CLI ihr Modell nicht erreichen kann. Der Proxy filtert auch keine MCP-Verbindungen oder Browserdaten. Siehe Datenverkehr außerhalb des Befehls-Proxys.

Für einen weiteren beschreibbaren Ordner verwenden Sie --add-dir mit dem benötigten Pfad:

codex --add-dir <DIR>

Ersetzen Sie <DIR> durch diesen Ordner. OpenAI empfiehlt, ein Verzeichnis hinzuzufügen, wenn die Aufgabe nur das benötigt.

Grenze vor einem langen Lauf prüfen

Wir haben diese vier Prüfungen aus dem Projektordner ausgeführt:

codex sandbox -c sandbox_mode="workspace-write" -- sh -c 'touch ./inside && echo inside-ok || echo inside-blocked'
codex sandbox -c sandbox_mode="workspace-write" -- sh -c 'touch ~/codex-probe-outside && echo outside-ok || echo outside-blocked'
codex sandbox -c sandbox_mode="workspace-write" -- sh -c 'curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com || echo net-blocked'
codex sandbox -c sandbox_mode="workspace-write" -c sandbox_workspace_write.network_access=true -- sh -c 'curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com || echo net-blocked'

In dieser Reihenfolge erhielten wir inside-ok, outside-blocked, net-blocked (nach curl: (6) Could not resolve host: example.com) und 200.

Einige Dokumente zeigen codex sandbox macos|linux. Version 0.162.1 akzeptiert diese nicht als Betriebssystem-Unterbefehle: Der Host wählt das Backend. Nutzen Sie die obige Form ohne Unterbefehl. Der Quellcode der Version bestätigt das.

Prüfen Sie auch über das Shell-Tool des Agenten. Unser Aufruf auf Agentenebene war:

codex exec -s workspace-write -c approval_policy="never" \
  --ephemeral --json \
  "Run exactly these three shell commands, one at a time, with your shell tool, and report the exit code and output of each. Do not retry, do not use workarounds, do not ask for approval: 1) touch ./agent-inside  2) touch ~/codex-agent-probe  3) curl -sS -m 5 -o /dev/null -w '%{http_code}' https://example.com"

Die Anfrage ließ diese drei Befehle ausführen:

touch ./agent-inside
touch ~/codex-agent-probe
curl -sS -m 5 -o /dev/null -w '%{http_code}' https://example.com

In unserem Test lieferte das Schreiben im Projekt den Exit-Code 0. Das Schreiben im Home-Verzeichnis scheiterte mit Operation not permitted. curl lieferte den Exit-Code 6 und Could not resolve host. Im Home-Verzeichnis erschien keine Datei. Diese Befehle in einem separaten Terminal ohne Sandbox auszuführen, würde die Grenzen des Agenten nicht prüfen.

Sandbox-Modi und Bestätigungsrichtlinien

Der Sandbox-Modus legt die Grenzen für Befehle fest. Die Bestätigungsrichtlinie entscheidet, wann Codex fragen darf, ob es diese überschreiten kann.

In 0.162.1 akzeptiert das interaktive Bestätigungsflag on-request und never. Die erste Option fragt, wenn weitergehender Zugriff nötig ist. Die zweite verhindert Aufforderungen, behält aber die gewählten Sandbox-Grenzen bei. Die Konfiguration unterstützt auch eine Tabelle mit detaillierten Regeln. codex exec nutzt standardmäßig never und akzeptiert das interaktive Flag -a nicht. Siehe die Bestätigungsoptionen und den exec-Standardwert.

Ältere Beispiele erfordern Vorsicht: untrusted entfiel in 0.149.0, on-failure ist veraltet, und --full-auto entfiel für codex exec in 0.147.0. Unser Lauf mit 0.162.1 lehnte --full-auto ab. Nutzen Sie --sandbox workspace-write für exec-Aufgaben, die Änderungen erfordern.

Was bewirkt der Codex-Modus --yolo?

--yolo ist ein Alias für --dangerously-bypass-approvals-and-sandbox. Es deaktiviert beide Kontrollen und wirkt wie danger-full-access mit der Bestätigungsrichtlinie never. OpenAI empfiehlt, es nur in einer extern abgeschotteten Umgebung zu nutzen. Siehe die Warnung zum Flag.

Wir haben die Agentenprüfung wiederholt mit:

codex exec --yolo \
  --ephemeral --json \
  "Run exactly these two shell commands, one at a time, with your shell tool, and report the exit code and output of each. Do not retry and do not run anything else: 1) touch ~/codex-agent-probe  2) curl -sS -m 5 -o /dev/null -w '%{http_code}' https://example.com"

Die beiden Befehle waren der Schreibzugriff auf das Home-Verzeichnis und die curl-Anfrage von oben. Diesmal erschien die Datei in unserem Home-Verzeichnis, und die Anfrage lieferte HTTP 200. Danach haben wir die Prüfdatei entfernt. Der Codex-yolo-Modus gewährt Zugriff über das Projekt hinaus.

Lizard und Docker Sandboxes starten Codex beide mit dem langen Umgehungsflag in einer MicroVM. Das entspricht dem vorgesehenen Einsatz: Die VM stellt die äußere Grenze. Sie schützt Dateien innerhalb der VM nicht vor dem Agenten. Docker Sandboxes dokumentiert seinen Standardbefehl für Codex; den Befehl von Lizard haben wir während unseres Tests beobachtet.

Codex in Docker ausführen

Wir haben dieses Dockerfile getestet:

FROM node:22-bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends git python3 ca-certificates curl \
 && rm -rf /var/lib/apt/lists/*
RUN npm install -g @openai/codex@0.162.1
WORKDIR /workspace

Bauen Sie es als codex-sandbox-test. Unser Projekt lag im lokalen Ordner app. CODEX_DIR verwies auf einen separaten, vorhandenen Ordner mit einer Kopie unserer ChatGPT-Anmeldedaten. Wir führten aus:

docker run --rm \
  -v "$PWD/app:/workspace/app" \
  -v "$CODEX_DIR:/codex-home" \
  -e CODEX_HOME=/codex-home \
  -w /workspace/app \
  codex-sandbox-test codex exec -s workspace-write --ephemeral \
  "Run python3 -m unittest. Fix the failing test with the smallest reasonable change to the code under test, not the test. Run the tests again and report what changed."

In unserem Testbeispiel subtrahierte add(a, b) die Eingaben. Codex änderte return a - b in return a + b. Sein Testlauf und ein unabhängiger Testlauf auf dem Host waren erfolgreich. Der beschreibbare Projekt-Mount übertrug diese Änderungen auf den Host.

Die Linux-Sandbox funktionierte auch in diesem standardmäßigen Docker Desktop-Container ohne zusätzliche Berechtigungen oder ein installiertes bubblewrap-Paket. Das mitgelieferte Hilfsprogramm von Codex erlaubte Schreibzugriffe im Projekt, blockierte einen Schreibzugriff auf /root mit Read-only file system und blockierte den Netzwerkzugriff.

Dieses Ergebnis gilt nicht für jeden Host. OpenAI warnt, dass Docker-Einstellungen die Namespaces, setuid bubblewrap oder seccomp-Operationen blockieren können, die Codex benötigt. Falls die innere Sandbox nicht läuft, richten Sie den Container als Grenze ein und nutzen Sie dann:

codex --sandbox danger-full-access

Prüfen Sie zuerst Mounts, Berechtigungen und Netzwerkrichtlinien. Der Container-Leitfaden von OpenAI warnt, dass ein bösartiges Projekt alles aus einem Dev-Container nach außen senden kann, worauf es dort zugreifen kann, einschließlich Codex-Anmeldeinformationen.

Im Container authentifizieren

Für die Automatisierung liefert CODEX_API_KEY einen Schlüssel an nicht interaktive Codex-Prozesse. Beschränken Sie ihn auf den Lauf, der ihn braucht. So speichern Sie eine API-Schlüssel-Anmeldung aus einer vorhandenen Umgebungsvariable:

printenv OPENAI_API_KEY | codex login --with-api-key

Für die Anmeldung mit Gerätecode:

codex login --device-auth

Die Geräteanmeldung muss in Ihren Konto- oder Arbeitsbereichseinstellungen aktiviert sein. Eine weitere Option ist, auth.json von einer angemeldeten Maschine zu kopieren, wie in unserem Test. Behandeln Sie auth.json wie ein Passwort: Die Datei enthält Zugriffstoken. Eine Anmeldung über einen Schlüsselbund hinterlässt eventuell keine nutzbare Datei zum Kopieren. Siehe Authentifizierung und CODEX_API_KEY.

Docker-Container und Docker Sandboxes unterscheiden sich

Docker Sandboxes nutzt die separate CLI sbx:

sbx run codex ~/my-project

Jede Sandbox hat einen eigenen Linux-Kernel und eine eigene Docker Engine. Ein Host-Proxy hält die Modell-Anmeldeinformationen außerhalb der VM und fügt sie ausgehenden Anfragen hinzu. Netzwerkregeln verweigern Datenverkehr, sofern er nicht erlaubt ist. Beim ersten Start stehen die Voreinstellungen Open, Balanced und Locked Down bereit. Balanced erlaubt gängige Entwicklungsseiten; Locked Down benötigt eine ausdrückliche Regel für den Modellanbieter. Siehe Isolierung, Umgang mit Anmeldeinformationen und Voreinstellungen.

Die lokalen Anforderungen sind macOS Sonoma 14+ auf Apple silicon; Windows 11 auf Intel/AMD mit Windows Hypervisor Platform; oder Ubuntu 24.04+ auf x86-64/arm64 mit KVM und Mitgliedschaft in der Gruppe kvm. Docker Desktop ist nicht erforderlich. Lokale sbx-Sandboxes innerhalb einer VM benötigen verschachtelte Virtualisierung. Prüfen Sie die Installationsanleitung.

Wir haben Docker Sandboxes nicht getestet. Sein standardmäßiges Umgehungsflag lässt gemountete Projektdateien beschreibbar, einschließlich Git-Hooks. Prüfen Sie diese nach einem Lauf.

Wann eine Cloud-Sandbox hilft

Remote-Rechenleistung hilft, wenn eine Aufgabe nach dem Trennen Ihres Laptops weiterlaufen muss oder wenn mehrere Agenten separate Arbeitsbereiche benötigen. Teilen Sie nur den Code und die Anmeldeinformationen, die jede Aufgabe braucht.

Die aktuelle Dokumentation von Codex Cloud beschreibt eine VM pro Aufgabe. Ein Internetschalter auf Umgebungsebene bietet Paketmanager- und Domain-Allowlists oder uneingeschränkten Zugriff. Umgebungsvariablen gehen direkt an Programme. Netzwerkgeheimnisse nutzen Platzhalter, die ein Proxy für erlaubte HTTPS-Ziele auf Port 443 ersetzt. Cloud-Funktionen erfordern einen unterstützten ChatGPT-Plan: Plus, Pro, Business oder Enterprise. Die Authentifizierung per API-Schlüssel umfasst sie nicht. Wir haben Codex Cloud nicht getestet. Siehe Cloud-Umgebungen, Pläne und unseren Codex Cloud-Leitfaden.

Lizard Sandboxes führt Aufgaben in Firecracker-MicroVMs aus, jede mit eigenem Kernel. Wir verkaufen Lizard Sandboxes. Wir empfehlen sie, wenn Sie Remote-Arbeitsbereiche über eine CLI erstellen, ausführen und pausieren möchten. Beginnen Sie für lokale Arbeiten mit der integrierten Sandbox von Codex.

Codex in Lizard Sandboxes ausführen

Installieren Sie die Lizard CLI, melden Sie sich an und wählen Sie ein Projekt. Verbinden Sie ein ChatGPT-Abonnement:

lizard agents login chatgpt

Oder registrieren Sie einen OpenAI-API-Schlüssel:

lizard agents add openai

Prüfen Sie die Verbindung:

lizard agents status

Unser Test nutzte ein bereits verbundenes ChatGPT-Abonnement; wir haben die Anmeldung nicht wiederholt.

Projekt erstellen und kopieren

Ersetzen Sie den Projektplatzhalter:

lizard sandbox create --project YOUR_PROJECT_ID --template codex --size small --timeout 3600000 --json

Setzen Sie SB auf die zurückgegebene Sandbox-ID und BUNDLE_DIR auf einen vorhandenen lokalen temporären Ordner. Das Timeout gibt diesem Arbeitsbereich eine Stunde. Die Standardlebensdauer beträgt fünf Minuten; Befehle verlängern sie nicht.

Aus Ihrem lokalen Repository:

git bundle create "$BUNDLE_DIR/app.bundle" HEAD
lizard sandbox files put "$SB" "$BUNDLE_DIR/app.bundle" /workspace/app.bundle
lizard sandbox exec "$SB" -- git clone /workspace/app.bundle /workspace/app

Das Bundle enthält den committeten Verlauf samt aller committeten Geheimnisse und schließt nicht committete Dateien aus. Prüfen Sie, was Sie senden.

Aufgabe ausführen

lizard sandbox prompt "$SB" --agent codex --cwd /workspace/app "Run the tests. Fix one failing test with the smallest reasonable change. Report what changed and which tests passed."

Geben Sie --agent codex ausdrücklich an. Während unseres Laufs zeigte die Prozessliste:

codex exec --json --skip-git-repo-check --dangerously-bypass-approvals-and-sandbox -C /workspace/app "<prompt>"

Die eigene Sandbox und die Bestätigungen von Codex waren aus; die Firecracker-MicroVM stellte die Isolierung bereit. Code darin kann auf die Anmeldeinformationen zugreifen, die dem Prozess zur Verfügung stehen. Begrenzen Sie deren Rechte. Die VM verbirgt diese Anmeldeinformationen nicht vor dem Agenten.

Prüfen, herunterladen und pausieren

Prüfen Sie das Diff, führen Sie Ihre Projekttests erneut aus und speichern Sie die benötigten Dateien vor dem letzten Pausenbefehl:

lizard sandbox exec "$SB" -- git -C /workspace/app status --short
lizard sandbox exec "$SB" -- git -C /workspace/app diff
lizard sandbox files get "$SB" /workspace/app/calc.py ./calc.py.review
lizard sandbox pause "$SB"

Unser Testbeispiel nutzte calc.py. Wählen Sie beim Wiederholen Ihre geänderte Datei. Codex behob den Subtraktionsfehler, unser separater unittest-Lauf gab OK aus, und die heruntergeladene Datei stimmte überein. Wir bestätigten den Status paused.

Speichern Sie die Ergebnisse vor Ablauf. Eine erfolgreiche Pause stoppt die Berechnung der Rechenkosten; die Speicherkosten für Persistent Volumes bleiben separat. Nutzen Sie den Schnellstart und die Sandbox-CLI-Referenz für Details zum Lebenszyklus.

Was kostet der Cloud-Arbeitsbereich?

Die Rechenraten von Lizard am 21. Oktober 2026:

Die Abrechnung der Rechenleistung erfolgt pro Sekunde während des Betriebs, auch im Leerlauf. Eine erfolgreiche Pause stoppt die Rechenkosten; Speicher für Persistent Volumes wird separat berechnet.

Lizard Pro kostet $19 pro Monat, inklusive Steuern, mit $19 an Nutzung. Zusätzliche Nutzung ist pay as you go. Neue Konten erhalten eine siebentägige Testversion mit $5 an Nutzung; eine Karte ist erforderlich. Gebühren für ChatGPT oder die OpenAI-API fallen separat an. Prüfen Sie die Preise vor einem Lauf.

Häufige Einrichtungsprobleme

Was wir getestet haben

Am 21. Oktober 2026 haben wir Codex CLI 0.162.1 aus npm unter macOS 26.6.2, Apple silicon (arm64), in einem neuen Git-Repository unter dem Home-Verzeichnis getestet. Wir prüften Sandbox-Befehle und Shell-Aufrufe des Agenten mit ChatGPT-Anmeldung, einschließlich des Vergleichs mit umgangenen Einschränkungen.

Die Docker-Tests nutzten Docker Desktop, Docker Engine 28.1.1, arm64 und den LinuxKit-Kernel 6.10. Wir prüften die Sandbox-Grenzen und eine Python-Testkorrektur und führten den Test dann erneut auf dem Host aus.

Die Lizard-Tests nutzten Lizard CLI 4.0.65. Die Vorlage codex enthielt Codex CLI 0.159.2, Node.js 22.23.2, Python 3.11.2 und git 2.39.5. Wir prüften Bundle-Upload, Klonen, die Aufgabe, separate Tests, Diff-Prüfung, Download und Pause.

Wir haben Docker Sandboxes, Codex Cloud, natives Windows/WSL2, run_in_container.sh von OpenAI und die Registrierung eines neuen Kontos nicht getestet. Diese Prüfungen decken die erfassten Setups ab; sie stellen kein Sicherheitsaudit dar.

Welches Setup sollten Sie wählen?

Nutzen Sie workspace-write für lokale Arbeiten mit bekannten Dateien und Tools. Wählen Sie Docker für eine wiederholbare Laufzeitumgebung und prüfen Sie, ob die innere Sandbox von Codex dort funktioniert. Erwägen Sie Docker Sandboxes für lokale MicroVM-Isolierung und Anmeldeinformationen auf dem Host oder Codex Cloud für Aufgaben innerhalb von ChatGPT.

Wählen Sie Lizard Sandboxes, wenn Sie Remote-Arbeitsbereiche über Lizard CLI benötigen. Beginnen Sie mit einer kleinen Testkorrektur, prüfen Sie das Diff, laden Sie das Ergebnis herunter und pausieren Sie den Arbeitsbereich.