2026: OpenAI-Codex-Sandbox sicher selbst bereitstellen?

Ein Codex-Auftrag soll auf einem entfernten Linux-System laufen, aber unklar ist, ob dabei auch Modell und Anwendung auf den eigenen Server wechseln.

Schnellste Lösung: Selbst gehostet wird die Ausführungsumgebung, nicht das OpenAI-Modell. Für die Agents API läuft der Agent-Harness bei OpenAI und der Executor in Ihrer Umgebung. Trennen Sie Umgebungen nach Nutzer oder Arbeitslast, verwenden Sie einen separaten, eingeschränkten Umgebungsschlüssel und halten Sie Anwendungsschlüssel außerhalb der Sandbox. Für eine dauerhaft laufende Codex-CLI-Sitzung gilt ein anderer Betriebsweg.

Dieser Leitfaden ist für Entwickler und kleine Teams gedacht, die Codex-Aufgaben auf einem entfernten Linux-System ausführen lassen möchten.
Er hilft dabei, die offizielle Architektur, die Grenzen der Umgebung und die Prüfungen vor dem Produktivbetrieb einzuordnen.
Auch technische Verantwortliche, die Laptop, Container und entfernten Server vergleichen, finden hier Kriterien für die Entscheidung.

Zuletzt aktualisiert am 02.11.2026; geprüft anhand der Dokumentation zur selbst gehosteten Umgebung, der Architekturbeschreibung der Agents API und der Codex-Sicherheitshinweise.

OpenAI-Codex-Sandbox und Modellbetrieb

„Selbst gehostet“ beschreibt in diesem Zusammenhang den Ort, an dem Befehle ausgeführt und Arbeitsdateien gelesen oder verändert werden. Es bedeutet nicht, dass das Modell, das Codex antreibt, auf die eigene Hardware verlagert wird. Die Unterscheidung ist kaufentscheidend: Wer eine Umgebung für kontrollierte Codeausführung sucht, kann einen entfernten Executor prüfen. Wer hingegen vollständige Kontrolle über Modellinferenz erwartet, benötigt eine andere Architektur.

Die offizielle Agents-API-Architektur trennt die Koordination durch den Agent-Harness von der Ausführung durch den Executor. Der Harness steuert den Ablauf; der Executor arbeitet innerhalb der von Ihnen bereitgestellten Umgebung. Bei der selbst gehosteten Variante bleibt diese Umgebung unter Ihrer Kontrolle, während die Verbindung zum Dienst über den dokumentierten Ablauf hergestellt wird. Die offizielle Architekturübersicht erläutert die Aufgabenverteilung.

Davon zu unterscheiden ist Codex CLI, das direkt auf einem entfernten Linux-System gestartet wird. Das kann für einen einzelnen Entwickler oder einen gezielten Administrationsablauf passen. Es ist aber nicht automatisch die Agents-API-Sandbox mit deren Executor-Anbindung, Lebenszyklus und Statusmeldungen. Werden diese Wege vermischt, entstehen schnell falsche Annahmen zu Anmeldung, Schlüsseln, Netzwerkregeln und Wiederanlauf.

Diese Gegenüberstellung ist eine Entscheidungshilfe, keine Aussage, dass sich die Betriebswege ohne Anpassungen austauschen lassen. Die Dokumentation der selbst gehosteten Umgebung beschreibt die unterstützte Anbindung des Executors. Verwenden Sie deren aktuelle Schritte, wenn Sie genau diesen Weg umsetzen.

Sicherheitsgrenzen vor der Bereitstellung

Die erste Sicherheitsentscheidung betrifft nicht den Servertyp, sondern die Frage, was der Agent in seiner Umgebung erreichen darf. Code, Abhängigkeiten, lokale Werkzeuge, MCP-Dienste, Geheimnisse und interne Ressourcen können unterschiedliche Vertrauensstufen haben. Wenn alle Aufträge dieselbe Umgebung und dieselben Berechtigungen verwenden, ist die technische Trennung schwächer, als es die Bezeichnung „Sandbox“ vermuten lässt.

Die offizielle Sicherheitsdokumentation weist darauf hin, dass Agenten in einer gemeinsam genutzten Ausführungsumgebung auf dieselben Dateien, Zugangsdaten und Ressourcen zugreifen können. Legen Sie deshalb eine Grenze nach Nutzer, Projekt oder Arbeitslast fest. Teilen mehrere Personen einen Executor, muss ausdrücklich geklärt sein, welche Dateien und Werkzeuge für alle sichtbar sein dürfen. Die Sicherheitsinformationen zu Umgebungen sollten vor der Entscheidung über gemeinsame Nutzung geprüft werden.

Eine Sandbox verringert nicht automatisch jedes Risiko. Sie kann beispielsweise verhindern, dass ein Prozess beliebig in das Host-Dateisystem schreibt, schützt aber nicht vor einer bewusst zu großzügigen Freigabe des Arbeitsbereichs oder einem erreichbaren internen Dienst. Ebenso ist ein Container nicht gleichbedeutend mit einer vollständigen Sicherheitsgrenze. Prüfen Sie daher jede Berechtigung entlang des konkreten Zugriffswegs: Was kann der Executor lesen, verändern, starten und über das Netzwerk erreichen?

Auch der Datenschutz hängt von der Konfiguration ab. Wenn Unternehmensquellcode oder interne Dokumente in den Arbeitsbereich gelangen, sollten Zweck, Zugriff, Aufbewahrung und Protokollierung dokumentiert sein. Die Anbindung einer selbst verwalteten Umgebung macht die Verarbeitung nicht automatisch DSGVO-konform. Verantwortliche sollten festhalten, welche Daten in die Umgebung gelangen und wer Störungen oder Sicherheitsvorfälle bearbeitet.

Ausführungsumgebung passend auswählen

Die offizielle Dokumentation nennt Laptop, Container und entfernte Sandbox als mögliche Umgebungen. Welcher Ort passt, hängt von den benötigten Abhängigkeiten, der gewünschten Verfügbarkeit und der Vertrauensgrenze ab. Ein Laptop kann einen ersten Funktionstest vereinfachen, ist aber an lokale Verfügbarkeit und Benutzerkontext gebunden. Ein Container erlaubt es, Laufzeitumgebung und Abhängigkeiten gezielter zu definieren. Ein entfernter Linux-Server eignet sich, wenn ein Team die Umgebung dauerhaft betreiben und administrieren muss.

Die Entscheidung sollte nicht allein nach der vermeintlichen Isolation fallen. Ein Container kann einen Arbeitsbereich sauberer abgrenzen, aber ein privilegierter Container, ein weitreichend eingebundenes Host-Verzeichnis oder übergebene Geheimnisse können diese Grenze wieder schwächen. Umgekehrt ist ein entfernter Server nicht automatisch unsicher: Entscheidend ist, wie Betriebssystemkonto, Dateirechte, Netzwerk und Executor-Schlüssel eingerichtet und überwacht werden.

Für die Dimensionierung gibt es keine belastbare pauschale Mindestkonfiguration, die für jedes Repository und jede Abhängigkeit gilt. Messen Sie Ihre tatsächliche Arbeitslast: Größe und Anzahl der Repositories, Umfang der Abhängigkeitsinstallation, parallele Aufträge, temporärer Speicherbedarf und Protokollaufkommen. Ein Build kann CPU und Speicher deutlich anders beanspruchen als eine kurze Quelltextänderung. Wenn mehrere Aufträge gleichzeitig laufen sollen, müssen deren Ressourcen- und Zugriffskonflikte separat bewertet werden.

Codex exec-server beziehungsweise der Executor sollte in einer Umgebung laufen, deren Abhängigkeiten nachvollziehbar sind. Halten Sie Installationsanweisungen und Konfiguration reproduzierbar. Legen Sie fest, welche Pakete zur Laufzeit installiert werden dürfen und ob eine Aufgabe das Betriebssystem verändern darf. Unkontrollierte Paketinstallationen erschweren sowohl die Fehleranalyse als auch die Prüfung auf bekannte Schwachstellen.

Vorbereitung und Start des Executors

Bevor Sie die Verbindung aktivieren, gleichen Sie die geplante Umgebung mit der aktuellen offiziellen Dokumentation ab. Schnittstellen, Konfigurationsparameter, Installationsverfahren und Versionsanforderungen können sich ändern. Deshalb sollte ein Beispiel aus einer älteren Anleitung nicht ungeprüft als dauerhafte Produktionskonfiguration übernommen werden.

1. Betriebsweg festlegen. Entscheiden Sie schriftlich, ob die Agents-API-Umgebung mit Executor oder eine separat betriebene Codex-CLI-Sitzung benötigt wird. Die Begriffe „remote“ und „self-hosted“ allein reichen nicht, um den Ablauf festzulegen.

2. Arbeitsbereich definieren. Legen Sie Repository, Arbeitsverzeichnis und erlaubte lokale Werkzeuge fest. Prüfen Sie, ob Konfigurationsdateien Zugangsdaten enthalten oder ob der Executor zusätzliche Verzeichnisse des Hosts sehen könnte.

3. Betriebskonto beschränken. Führen Sie den Executor nicht mit weitergehenden Rechten aus, als seine Aufgaben erfordern. Trennen Sie Systemverwaltung und Codeausführung. Prüfen Sie, ob temporäre Dateien, Protokolle und Artefakte in kontrollierten Verzeichnissen landen.

4. Schlüssel getrennt bereitstellen. Erzeugen und verwalten Sie den für die Umgebung vorgesehenen Schlüssel getrennt von Anwendungsschlüsseln. Speichern Sie ihn nicht im Repository, im Image oder in Ausgaben des Build-Prozesses. Die Konfigurationsdokumentation ist maßgeblich für die aktuell vorgesehenen Einstellungen; übernommene Parameternamen sollten dort gegengeprüft werden.

5. Netzwerkregeln ableiten. Richten Sie die Firewall anhand der in der aktuellen Dokumentation beschriebenen Ziele und des Verbindungsablaufs ein. Der dokumentierte Executor verbindet sich ausgehend über WebSocket. Daraus folgt nicht, dass pauschal ein eingehender Dienstport freigegeben werden muss. Unnötige ausgehende Ziele sollten ebenfalls ausgeschlossen werden.

6. Executor starten und Status prüfen. Folgen Sie dem offiziellen Startablauf und beobachten Sie die vorgesehenen Statusereignisse. Ein laufender Prozess allein zeigt noch nicht, dass Registrierung und Verbindung abgeschlossen sind. Bei Fehlern prüfen Sie zuerst Konfiguration, Schlüsselzuordnung, DNS- und ausgehende Netzwerkverbindung sowie die Executor-Protokolle.

Die Beschreibung des Umgebungslebenszyklus hilft dabei, Status und Übergänge einzuordnen. Für Konfigurationsdateien, zurückgegebene Dateien und erzeugte Artefakte sind außerdem die Hinweise zur Dateiverarbeitung relevant. Übernehmen Sie keine undokumentierten Variablennamen oder Befehlszeilenargumente aus Community-Beiträgen.

Abnahme mit einer begrenzten Testaufgabe

Die erste Ausführung sollte mit einem Test-Repository ohne vertrauliche Daten erfolgen. Prüfen Sie nicht nur, ob der Agent eine Datei ändern kann. Die Abnahme soll zeigen, welche Grenzen tatsächlich greifen und was bei einem Verbindungsabbruch passiert.

• [ ] Das Test-Repository enthält keine produktiven Schlüssel, Kundendaten oder privaten Konfigurationen.
• [ ] Der Executor kann nur auf den vorgesehenen Arbeitsbereich zugreifen.
• [ ] Ein Schreibtest verändert ausschließlich erwartete Dateien; temporäre Dateien werden an einem bekannten Ort abgelegt.
• [ ] Nicht freigegebene Netzwerkziele sind nicht erreichbar; dokumentierte Verbindungen funktionieren weiterhin.
• [ ] Ein ungefährlicher Befehlsaufruf lässt sich anhand des Status und der Protokolle nachvollziehen.
• [ ] Ein absichtlich beendeter Testprozess führt nicht zu einer unkontrollierten Wiederverwendung veralteter Zugangsdaten.
• [ ] Die Protokolle enthalten keine Schlüssel, vollständigen vertraulichen Inhalte oder unnötigen personenbezogenen Daten.
• [ ] Ein erzeugtes Artefakt wird nur über den vorgesehenen Weg zurückgegeben und anschließend aufbewahrt oder entfernt.

Erst nach dieser Prüfung sollte die Umgebung mit produktivem Quellcode verbunden werden. Bei einem Fehler halten Sie fest, ob er beim Start, bei der Registrierung, während des WebSocket-Verbindungsaufbaus, bei der Ausführung oder bei der Rückgabe von Dateien auftritt. Diese Einordnung verhindert, dass etwa ein Schlüsselproblem durch eine großzügigere Firewall-Regel „behoben“ wird.

Die Sicherheitsprinzipien aus dem Codex-Leitfaden zum sicheren Betrieb ergänzen die technische Abnahme um die Frage, wann eine menschliche Freigabe erforderlich ist und wie Ausgaben geprüft werden. Eine erfolgreiche Statusmeldung ist kein Ersatz für eine Codeprüfung. Besonders bei Änderungen an Deployments, Zugriffsrechten, Datenbankmigrationen oder produktiven Konfigurationen sollte der Freigabeschritt unabhängig vom Executor festgelegt sein.

Wartung und laufender Betrieb

Eine dauerhaft erreichbare Umgebung braucht einen festen Wartungsrhythmus. Prüfen Sie regelmäßig, ob Betriebssystem, Executor, installierte Abhängigkeiten und Container-Basis noch dem vorgesehenen Stand entsprechen. Aktualisierungen sollten zuerst in einer nicht produktiven Umgebung getestet werden, insbesondere wenn sich Schnittstellen oder Ausführungsrechte ändern. Notieren Sie, welche Versionen tatsächlich eingesetzt werden, statt eine Version aus einem alten Beispiel als dauerhaft gültig anzunehmen.

Schlüsselrotation gehört ebenfalls in die Betriebsplanung. Bestimmen Sie, wer den Umgebungsschlüssel erneuern darf, wie ein Austausch erfolgt und wie alte Schlüssel ungültig gemacht werden. Wenn ein Schlüssel in einem Protokoll oder Repository gefunden wird, behandeln Sie ihn als kompromittiert. Eine bloße Löschung aus der sichtbaren Datei entfernt ihn nicht zwingend aus Historien oder Sicherungskopien.

Legen Sie außerdem Regeln für die Lebensdauer von Arbeitsumgebungen fest. Temporäre Umgebungen sollten nach Abschluss nicht unbegrenzt ausführbar bleiben. Dauerhafte Umgebungen benötigen dagegen klare Zuständigkeiten für Berechtigungen, Protokollzugriff, Speicherbelegung und Wiederherstellung. Prüfen Sie, welche Dateien als Aufgabeingabe erforderlich sind und welche Artefakte zurückgegeben oder verworfen werden sollen. Die offiziellen Hinweise zum Lebenszyklus und zu Dateien und Artefakten sollten bei Änderungen erneut herangezogen werden.

Für ein kleines Team ist die zentrale Frage nicht, ob ein eigener Server grundsätzlich geeignet ist, sondern ob jemand den laufenden Betrieb verantwortet. Ohne Zuständigkeit für Updates, Zugriffsprüfung, Schlüsselwechsel und Störungsanalyse wird eine entfernte Umgebung leicht zu einem dauerhaft erreichbaren, aber vernachlässigten System. Falls nur gelegentlich ein kurzer Auftrag ausgeführt wird, kann ein lokaler oder kurzlebiger Testaufbau weniger Verwaltungsaufwand verursachen. Für langfristige, kontrollierte Ausführung kann ein eigener Linux-Host sinnvoll sein, sofern die Sicherheits- und Wartungsaufgaben eingeplant sind.

Häufige Fragen zur entfernten Ausführung

Ist eine selbst gehostete Codex-Sandbox dasselbe wie Codex CLI auf einem entfernten Rechner?

Nein. Bei der selbst gehosteten Umgebung der Agents API läuft der Agent-Harness bei OpenAI und ein Executor in der von Ihnen kontrollierten Umgebung. Codex CLI auf einem entfernten Linux-Rechner ist dagegen ein eigener Betriebsweg. Prüfen Sie deshalb zuerst, ob die Anwendung die Agents-API-Umgebung oder lediglich eine dauerhaft verfügbare CLI-Sitzung benötigt.

Soll der Codex exec-server in einem Container oder direkt auf dem Server laufen?

Beides kann je nach Sicherheitsgrenze sinnvoll sein: Die offizielle Dokumentation nennt Container und entfernte Sandboxes ebenso wie einen Laptop als mögliche Umgebungen. Ein Container erleichtert die Trennung von Abhängigkeiten und Arbeitsbereich, ersetzt aber keine Kontrolle von Berechtigungen, Netzwerk und Geheimnissen. Entscheidend sind Vertrauensgrenze, Wiederherstellung und der Aufwand für Aktualisierungen.

Welche ausgehenden Verbindungen benötigt eine selbst gehostete Codex-Umgebung?

Richten Sie sich nach den aktuellen Verbindungszielen und dem WebSocket-Ablauf in der offiziellen Dokumentation für selbst gehostete Umgebungen. Der dokumentierte Verbindungsweg ist ausgehend; daraus folgt nicht automatisch, dass ein eingehender Port geöffnet werden muss. Übernehmen Sie keine Firewall-Regeln aus älteren Beispielen, ohne Ziele und Anforderungen erneut zu prüfen.

Wie trenne ich den Umgebungsschlüssel vom API-Schlüssel meiner Anwendung?

Verwenden Sie für den Executor einen eigens dafür vorgesehenen Umgebungsschlüssel und halten Sie Anwendungs-API-Schlüssel außerhalb der Sandbox. Legen Sie Geheimnisse weder in den Quellcode noch in das Container-Image oder ausführliche Protokolle. Beschränken Sie Zugriff und Lebensdauer, dokumentieren Sie die zuständige Person und planen Sie einen Austausch für den Fall eines Verdachts oder Teamwechsels.

Wenn der Executor nach bestandener Abnahme dauerhaft auf einem entfernten System laufen soll, vergleichen Sie vor der Entscheidung den tatsächlichen Ressourcenbedarf und die Betriebsaufgaben mit den verfügbaren Serveroptionen. Ein eigener AMD-Bare-Metal-Server ist vor allem dann eine Überlegung wert, wenn eine geteilte virtuelle Maschine bei Zugriffstrennung, dauerhaftem Betrieb oder kontrollierbaren Ressourcen nicht genügt. Er beseitigt jedoch weder die Pflicht zur Isolation noch garantiert er Codex-Kompatibilität oder bestimmte Ausführungsgeschwindigkeiten. Prüfen Sie die aktuellen Serverkonfigurationen und Mietbedingungen von NodeKVM sowie die verfügbaren Hilfsinformationen, bevor Sie den Executor produktiv einplanen.

Fragen

1. Q
   Ist eine selbst gehostete Codex-Sandbox dasselbe wie Codex CLI auf einem entfernten Rechner?

   Nein. Bei der selbst gehosteten Umgebung der Agents API läuft der Agent-Harness bei OpenAI und ein Executor in der von Ihnen kontrollierten Umgebung. Codex CLI auf einem entfernten Linux-Rechner ist dagegen ein eigener Betriebsweg. Prüfen Sie deshalb zuerst, ob die Anwendung die Agents-API-Umgebung oder lediglich eine dauerhaft verfügbare CLI-Sitzung benötigt.

2. Q
   Soll der Codex exec-server in einem Container oder direkt auf dem Server laufen?

   Beides kann je nach Sicherheitsgrenze sinnvoll sein: Die offizielle Dokumentation nennt Container und entfernte Sandboxes ebenso wie einen Laptop als mögliche Umgebungen. Ein Container erleichtert die Trennung von Abhängigkeiten und Arbeitsbereich, ersetzt aber keine Kontrolle von Berechtigungen, Netzwerk und Geheimnissen. Entscheidend sind Vertrauensgrenze, Wiederherstellung und der Aufwand für Aktualisierungen.

3. Q
   Welche ausgehenden Verbindungen benötigt eine selbst gehostete Codex-Umgebung?

   Richten Sie sich nach den aktuellen Verbindungszielen und dem WebSocket-Ablauf in der offiziellen Dokumentation für selbst gehostete Umgebungen. Der dokumentierte Verbindungsweg ist ausgehend; daraus folgt nicht automatisch, dass ein eingehender Port geöffnet werden muss. Übernehmen Sie keine Firewall-Regeln aus älteren Beispielen, ohne Ziele und Anforderungen erneut zu prüfen.

4. Q
   Wie trenne ich den Umgebungsschlüssel vom API-Schlüssel meiner Anwendung?

   Verwenden Sie für den Executor einen eigens dafür vorgesehenen Umgebungsschlüssel und halten Sie Anwendungs-API-Schlüssel außerhalb der Sandbox. Legen Sie Geheimnisse weder in den Quellcode noch in das Container-Image oder ausführliche Protokolle. Beschränken Sie Zugriff und Lebensdauer, dokumentieren Sie die zuständige Person und planen Sie einen Austausch für den Fall eines Verdachts oder Teamwechsels.