Codex Cloud ist da: Wann sollten Agenten weiterhin lokal laufen?

Auf dem DevDay am 29. September erklärte OpenAI, Entwickler könnten „Codex überall dort ausführen, wo sie ihn brauchen: auf einem Computer, remote von einem Smartphone oder in der Cloud von jedem beliebigen Gerät aus.“ Der Satz im DevDay-Rückblick, der für Teams am wichtigsten ist, folgt direkt danach: Wiederverwendbare Entwicklungsumgebungen „sorgen für einen schnellen Start von Aufgaben und bieten Ihrem Team ein gemeinsames Setup mit freigegebenen Einstellungen und Berechtigungen.“ Codex Cloud ist für Plus, Pro, Business, Healthcare, Education und Enterprise verfügbar.

Für einzelne Entwickler mag damit eine Frage geklärt sein. Für ein Team, das bereits Claude Code auf einer Workstation, Codex auf einem Build-Server und Gemini auf dem Laptop eines Teammitglieds betreibt, kommt dadurch ein weiterer Ort hinzu. Aufgaben starten jetzt in der Cloud von OpenAI, auf eigener Hardware und vom Smartphone aus im Zug – und an jedem dieser Orte wird separat protokolliert, was gelaufen ist. Welcher Agent woran arbeitet, was bereits abgeschlossen ist und was auf ein Review wartet: Das bedeutet eine Anlaufstelle mehr, die man im Blick behalten muss. Die entscheidende Frage lautet daher nicht „Cloud oder lokal?“, sondern welche Arbeit wohin gehört – und wo die Dokumentation dieser Arbeit zusammenläuft.

TL;DR

Codex Cloud ist die bessere Wahl für Codex-Aufgaben, die schnell starten, bei zugeklapptem Laptop weiterlaufen oder mobil vom Smartphone aus angestoßen werden sollen – sowie für Teams, die ein einheitliches, freigegebenes Setup bevorzugen, statt dass jeder seinen eigenen Host einrichtet. Eigene Computer setzen sich durch, wenn ein Task Claude Code oder eine andere Non-Codex-Runtime benötigt, Hardware über die Standard-VM Ihres Tarifs hinaus erfordert oder Funktionen verlangt, die laut der Dokumentation von OpenAI derzeit in Cloud-Umgebungen nicht unterstützt werden: GitLab-Repositories, Browser-Nutzung oder private Dienste, die über SSH bzw. ein Datenbankprotokoll angebunden sind. Keine der beiden Optionen bestimmt, wer die Arbeit zugewiesen hat oder wer die Ergebnisse abnimmt. Das verbleibt beim Team – direkt an einem Task.

Was eine Codex-Cloud-Umgebung bietet

Eine Cloud-Umgebung ist laut OpenAIs Dokumentation „das wiederverwendbare Setup, das Tasks nutzen: Repositories, Abhängigkeiten, Tools und Zugriffseinstellungen.“ Sie wählen GitHub-Repositories aus, und Codex analysiert sie, installiert Abhängigkeiten und Werkzeuge, testet den Workflow und fragt nach allem, was sich nicht automatisch ableiten lässt. Sie prüfen den Setup-Bericht und veröffentlichen die Umgebung. Jeder neue Task startet anschließend auf Basis dieses veröffentlichten Dateisystems in einem eigenen, isolierten Workspace – und Aufgaben „können weiterarbeiten, während Ihr Computer im Ruhezustand ist.“

Das Sicherheitsmodell ist deutlich durchdachter als ein einfaches Setup-Skript mit einkopiertem Token. Umgebungsvariablen werden direkt an Programme weitergereicht. Netzwerk-Geheimnisse gelangen hingegen gar nicht erst in den Prozess: Programme erhalten lediglich einen Platzhalter, und ein Proxy ersetzt diesen nur bei autorisierten HTTPS-Zielen durch die tatsächlichen Zugangsdaten. Der Internetzugriff ist eine Option, die aktiviert und anschließend eingeschränkt werden kann – entweder über Voreinstellungen für Paketmanager oder über eine benutzerdefinierte Domainliste. Private Dienste lassen sich über ein VPN anbinden (derzeit wird Tailscale unterstützt), und Enterprise-Workspaces können OIDC-Verbindungen für kurzlebige Cloud-Credentials anfordern.

Auch das Starten von Aufgaben ist denkbar flexibel. Die Codex Cloud-Übersicht nennt das Web, die Desktop-App, mobile Endgeräte sowie das Codex-CLI. Enterprise-Workspaces mit Cloud-Delegation können Tasks sogar per @ChatGPT in Slack oder Microsoft Teams anstoßen. Eine Enterprise-Umgebung lässt sich für den gesamten Workspace freigeben, sodass neue Teammitglieder direkt mit dem freigegebenen Setup starten, anstatt alles neu zu konfigurieren. Bei der Arbeit mit Codex eliminiert das eine häufige Ursache für Konfigurationsabweichungen.

Auch im Produktportfolio von OpenAI ist der Ausführungsort kein starres Dogma, sondern eine Entscheidung pro Workload. Dots erhalten jeweils einen eigenen Cloud-Computer, und die Agents-API unterstützt sowohl von OpenAI gehostete als auch selbst gehostete Umgebungen – wie wir in Wer betreibt die Agents? bereits erläutert haben. Codex lässt sich nun ebenfalls an beiden Orten ausführen.

Was ein Sharkly Computer bietet

Ein Computer ist ein angebundenes Gerät, ein Server oder ein Container, auf dem ein Agent Aufgaben ausführen kann. Wie es in der Dokumentation zu Sharkly Computers heißt, stellt er „das Betriebssystem, Dateien, Zugangsdaten, den Netzwerkzugriff und die Tools bereit, die ein Agent benötigt.“ Ein schlanker lokaler Dienst registriert ihn, erkennt die dort installierten Runtimes, nimmt anstehende Ausführungen entgegen und streamt den Fortschritt zurück. Da der Dienst die Verbindung ausgehend aufbaut, sind in einer typischen Konfiguration keine eingehenden Ports erforderlich.

Für diesen Vergleich sind drei Eigenschaften ausschlaggebend. Erstens: Ein einzelner Computer kann mehrere Runtimes bereitstellen. Sharkly unterstützt Claude Code, Codex, Gemini, OpenCode, OpenClaw und Hermes; eine benutzerdefinierte ACP-Runtime deckt Werkzeuge ab, die der lokale Dienst nicht automatisch erkennt, und ein einzelner Computer kann mehrere Agents bedienen. Zweitens erfolgt die Isolation pro Task. Im Temporary-Modus erhält jeder Task ein eigenes, isoliertes Verzeichnis, und Repository-basierte Läufe können einen frischen Worktree nutzen – genau so vermeiden parallele Agents Merge-Konflikte. Im Specified-Modus greift ein Durchlauf nacheinander auf ein vorkonfiguriertes lokales Verzeichnis zu, in dem Abhängigkeiten, Caches und lokale Dienste bereits vorhanden sind. Drittens bleiben die Zugangsdaten unter Ihrer Kontrolle: Ein Agent verwaltet reguläre und geheime Umgebungsvariablen, jeder Durchlauf erhält nur die explizit freigegebenen Variablen und Credentials, und ein Computer mit persönlicher Sichtbarkeit bleibt ausschließlich für seinen Besitzer zugänglich.

Die Kehrseite der Medaille: Sie sind auch für den Host verantwortlich. Geht ein Computer offline, warten neue Durchläufe darauf, dass er sich wieder verbindet. Die Desktop-App kann zwar den Ruhezustand verhindern und unter macOS bei zugeklapptem Deckel weiterlaufen, sofern das System dies gestattet; lange, unbeaufsichtigte Ausführungen gehören jedoch auf einen Server unter Ihrer Kontrolle, wie wir in Coding-Agents remote ausführen dargelegt haben. An den Kosten ändert sich nichts: Computer und Runtimes belegen keine Seats in den Tarifen von Sharkly, Sharkly verkauft keine Tokens, und ein Codex-Agent nutzt einfach das ChatGPT-Abonnement oder den API-Key, mit dem sein Codex-CLI angemeldet ist.

Codex Cloud oder eigener Computer: eine Entscheidungstabelle

Alle nachfolgenden Angaben zu Codex Cloud stammen aus OpenAIs Dokumentation zu Cloud-Umgebungen mit Stand vom 30. September. Die Angaben zu Computern basieren auf der Dokumentation von Sharkly.

Betrachten Sie dies als Entscheidungshilfe: Nutzen Sie Codex Cloud, wenn es sich um reine Codex-Aufgaben handelt, die Abhängigkeiten öffentlich oder über freigegebenes HTTPS erreichbar sind und die Person, die den Task anstößt, nicht am Schreibtisch sitzt. Verwenden Sie eigene Computer, wenn eine Aufgabe eine bestimmte Runtime, spezielle Hardware oder ein Netzwerk erfordert, das Sie aus guten Gründen gewählt haben.

Eine Zeile fehlt hier ganz bewusst: „Daten, die unser Netzwerk keinesfalls verlassen dürfen.“ Die Ausführung auf dem eigenen Computer sorgt zwar dafür, dass das Repository, die Caches und die Zugangsdaten auf von Ihnen kontrollierter Hardware verbleiben. Prompts werden damit jedoch nicht vom Modellanbieter ferngehalten – denn alles, was die Runtime an ihr Modell sendet, verlässt weiterhin das Netzwerk. OpenAI zieht bei den eigenen Produkten dieselbe Grenze: In der Dokumentation zur Agents-API heißt es, dass die Wahl einer selbst gehosteten Sandbox die Agents-API nicht automatisch für Zero Data Retention (ZDR) qualifiziert. Der Ausführungsort bestimmt, wo Code und Zugangsdaten liegen. Datenaufbewahrung ist eine separate Vereinbarung mit Ihrem Modellanbieter.

Erst bei gemischten Setups zahlt sich das Board aus

Die meisten Teams werden beide Ansätze kombinieren. Schnelle Codex-Fixes werden vom Smartphone aus in einer Cloud-Umgebung gestartet, während die Migration, die Zugriff auf die Staging-Datenbank benötigt, als Agent auf einem Computer im internen Netzwerk läuft. Das ist eine sinnvolle Aufteilung – sie führt jedoch zu zwei getrennten Aufgabenlisten.

Codex Cloud hält Tasks standardmäßig strikt voneinander getrennt: Der Zugriff auf ein gemeinsam genutztes Setup, so die Dokumentation, „gewährt keinen Zugriff auf die Tasks anderer Personen.“ Im Sinne des Datenschutzes ist das die richtige Grundeinstellung. Es bedeutet allerdings auch, dass zwar das Setup geteilt wird, nicht aber die Arbeit selbst. Die Frage „Woran arbeiten die Agents unseres Teams eigentlich gerade?“ – über Cloud-Tasks und Computer hinweg – muss daher an anderer Stelle beantwortet werden. Halten Sie die Routing-Regeln am besten schriftlich fest:

Where does this Task run?
1. Needs a non-Codex Runtime                          -> Agent on a Computer
2. Needs SSH, a database protocol, or private DNS     -> Computer inside that network
3. Needs GitLab, GitHub Enterprise Server, or browser use -> Computer
4. Codex work, allowlisted HTTPS, started away from a desk -> Codex cloud
5. Someone must accept the result                     -> a Task with an Assignee and a reviewer, wherever it ran

Regel fünf ist der Schlüssel, um diese Aufteilung beherrschbar zu machen. In Sharkly dient der Task als zentraler Datensatz: Fortschritt, Ausführungsprotokolle, Blocker und Ergebnisse laufen hier zusammen, und ein Durchlauf, der auf ein manuelles Review wartet, landet direkt im Posteingang der zuständigen Person. Ein Codex-Agent und ein Claude-Code-Agent auf demselben Computer berichten an dasselbe Board – jeweils basierend auf dem Modell, für das ihre Runtime konfiguriert ist. Bei Arbeiten, die in Codex Cloud ausgeführt wurden, stellt der Pull Request das Bindeglied dar: Wird die Task-ID im Branch-Namen oder PR-Titel hinterlegt, verknüpft Sharklys GitHub-Integration den PR automatisch mit dem Task, sodass die Abnahme weiterhin an einem einzigen Ort erfolgt. Unser Beitrag über Agent-Durchläufe, die länger als der Arbeitstag dauern, widmet sich ausführlich dem Review-Prozess bei langen, unbeaufsichtigten Läufen.

Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. An dieser Rollenverteilung ändert auch der Ausführungsort nichts.

Was das für Ihr Setup bedeutet

Codex Cloud ist eine hervorragende Antwort auf die Frage: „Wo sollte Codex laufen?“ Der Dienst wurde jedoch nicht dafür geschaffen, zu beantworten: „Woran arbeitet welcher unserer Agents über sämtliche Runtimes hinweg, und wer hat die Ergebnisse freigegeben?“ Behalten Sie eigene Computer für Aufgaben, die Ihre spezifischen Runtimes, Hardware oder Netzwerke erfordern, überlassen Sie Codex Cloud die Arbeiten, die vom Smartphone aus oder bei geschlossenem Laptop angestoßen werden – und führen Sie die Ergebnisse beider Welten an einem zentralen Ort zusammen.

Wenn Sie mehrere Coding-Agents flexibel parallel einsetzen möchten, statt sich auf ein einziges Ökosystem festzulegen, ist genau das die Herausforderung, für die Sharkly entwickelt wurde.